| Message ID | CANeMGR6CBxC8HtqbGamgpLGM+M1Ndng_WJ-RxFXXJnc9O3cVwQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Calculate VIRTQUEUE_NUM in "net/9p/trans_virtio.c" from stack size | expand |
--- net/9p/trans_virtio.c.orig 2024-10-25 10:25:09.390922517 +0800 +++ net/9p/trans_virtio.c 2024-10-25 16:48:40.451680192 +0800 @@ -31,11 +31,12 @@ #include <net/9p/transport.h> #include <linux/scatterlist.h> #include <linux/swap.h> +#include <linux/thread_info.h> #include <linux/virtio.h> #include <linux/virtio_9p.h> #include "trans_common.h" -#define VIRTQUEUE_NUM 128 +#define VIRTQUEUE_NUM (1 << (THREAD_SIZE_ORDER + PAGE_SHIFT - 6)) /* a single mutex to manage channel initialization and attachment */ static DEFINE_MUTEX(virtio_9p_lock);
For HPC applications the hard-coded VIRTQUEUE_NUM of 128 seems to limit the throughput of guest systems accessing cluster filesystems mounted on the host. Just increase VIRTQUEUE_NUM for kernels with a larger stack. Author: GUAN Xin <guanx.bac@gmail.com> Signed-off-by: GUAN Xin <guanx.bac@gmail.com> cc: Eric Van Hensbergen <ericvh@kernel.org> cc: v9fs@lists.linux.dev cc: netdev@vger.kernel.org cc: linux-fsdevel@vger.kernel.org