summaryrefslogtreecommitdiffstats
path: root/include/acpi
diff options
context:
space:
mode:
authorDominique Martinet <dominique.martinet@cea.fr>2018-07-30 15:14:37 +0900
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-07-03 13:14:42 +0200
commitbe87f21e6b25e3b09eb913dd4f8e416a2a81a3a0 (patch)
treeaf51ecf8be4c2f0da99e04a12f44d5d31e7f22a7 /include/acpi
parent1555583b63b344c634bbaaf6d966923d3fe96d44 (diff)
downloadlinux-stable-be87f21e6b25e3b09eb913dd4f8e416a2a81a3a0.tar.gz
linux-stable-be87f21e6b25e3b09eb913dd4f8e416a2a81a3a0.tar.bz2
linux-stable-be87f21e6b25e3b09eb913dd4f8e416a2a81a3a0.zip
9p: add a per-client fcall kmem_cache
[ Upstream commit 91a76be37ff89795526c452a6799576b03bec501 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'include/acpi')
0 files changed, 0 insertions, 0 deletions