diff options
author | Benjamin Coddington <bcodding@redhat.com> | 2025-06-09 13:21:56 -0400 |
---|---|---|
committer | Chuck Lever <chuck.lever@oracle.com> | 2025-06-12 20:37:33 -0400 |
commit | 8b3ac9fabaa825b7bae850ee7b4580c5cba32699 (patch) | |
tree | 8ff916fe5e034d74a104fb95e9485d4a5d10d43a /tools/perf/scripts/python/exported-sql-viewer.py | |
parent | 32ce6b3a83b71d8abf0c0837dc78775f16c9902f (diff) |
SUNRPC: Cleanup/fix initial rq_pages allocation
While investigating some reports of memory-constrained NUMA machines
failing to mount v3 and v4.0 nfs mounts, we found that svc_init_buffer()
was not attempting to retry allocations from the bulk page allocator.
Typically, this results in a single page allocation being returned and
the mount attempt fails with -ENOMEM. A retry would have allowed the mount
to succeed.
Additionally, it seems that the bulk allocation in svc_init_buffer() is
redundant because svc_alloc_arg() will perform the required allocation and
does the correct thing to retry the allocations.
The call to allocate memory in svc_alloc_arg() drops the preferred node
argument, but I expect we'll still allocate on the preferred node because
the allocation call happens within the svc thread context, which chooses
the node with memory closest to the current thread's execution.
This patch cleans out the bulk allocation in svc_init_buffer() to allow
svc_alloc_arg() to handle the allocation/retry logic for rq_pages.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Fixes: ed603bcf4fea ("sunrpc: Replace the rq_pages array with dynamically-allocated memory")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions