summaryrefslogtreecommitdiffstats
path: root/net/9p/Kconfig
diff options
context:
space:
mode:
authorDominique Martinet <dominique.martinet@cea.fr>2018-07-30 15:14:37 +0900
committerDominique Martinet <dominique.martinet@cea.fr>2018-09-08 01:39:47 +0900
commit91a76be37ff89795526c452a6799576b03bec501 (patch)
treedc45cdba9b9b8e1b5fa3451024968e137fb23d16 /net/9p/Kconfig
parent523adb6cc10b48655c0abe556505240741425b49 (diff)
downloadlinux-91a76be37ff89795526c452a6799576b03bec501.tar.bz2
9p: add a per-client fcall kmem_cache
Having a specific cache for the fcall allocations helps speed up end-to-end latency. The caches will automatically be merged if there are multiple caches of items with the same size so we do not need to try to share a cache between different clients of the same size. Since the msize is negotiated with the server, only allocate the cache after that negotiation has happened - previous allocations or allocations of different sizes (e.g. zero-copy fcall) are made with kmalloc directly. Some figures on two beefy VMs with Connect-IB (sriov) / trans=rdma, with ior running 32 processes in parallel doing small 32 bytes IOs: - no alloc (4.18-rc7 request cache): 65.4k req/s - non-power of two alloc, no patch: 61.6k req/s - power of two alloc, no patch: 62.2k req/s - non-power of two alloc, with patch: 64.7k req/s - power of two alloc, with patch: 65.1k req/s Link: http://lkml.kernel.org/r/1532943263-24378-2-git-send-email-asmadeus@codewreck.org Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr> Acked-by: Jun Piao <piaojun@huawei.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Greg Kurz <groug@kaod.org>
Diffstat (limited to 'net/9p/Kconfig')
0 files changed, 0 insertions, 0 deletions