Re: [PATCH RFC] sunrpc: hardcode pool_mode to pernode, remove other modes

[Chuck Lever]

On Thu, Apr 23, 2026, at 10:39 AM, Jeff Layton wrote:
> The SVC_POOL_AUTO/GLOBAL/PERCPU/PERNODE pool mode selection machinery
> was added when NUMA was new and the right default was unclear.  Today,
> pernode is the right choice everywhere:
>
> - On multi-NUMA hosts, it gives one pool per node with proper thread
>   affinity and NUMA-local memory allocation.
> - On single-node hosts, pernode degenerates to exactly one pool,
>   identical to the old "global" mode -- svc_pool_for_cpu() short-
>   circuits when sv_nrpools <= 1, no CPU affinity is set, and memory
>   is allocated from the single node.
>
> The percpu mode (one pool per CPU) created excessive pools relative to
> the number of threads most deployments run, and was only auto-selected
> in a narrow case (single node, >2 CPUs).
>
> Remove the SVC_POOL_* enum, mode selection heuristic,
> svc_pool_map_init_percpu(), and all mode-based switch statements.
> Simplify pool map functions to always use the pernode path.
>
> The module parameter and netlink interfaces are preserved for backward
> compatibility:
> - Writing "pernode" succeeds; any other value returns -EINVAL
> - Reading always returns "pernode"
> - Writing to the module parameter emits a deprecation notice
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> In hindsight, I wish I had proposed this before adding the pool-mode
> settings to the new nfsd netlink interfaces.
>
> If this is too radical as a single step, we just could switch the
> default to "pernode", add a warning and leave the interfaces alone for
> now. Or maybe do that and go ahead and remove the percpu setting?
>
> Thoughts?

Generally, I think the end goal of making "per-node" the default
and only setting is correct. My comments below are about how we
get there.

The main concern is not perturbing any configuration that today
happens to set the module parameter.

The proposed patch correctly preserves the shape of the user/kernel
interfaces (same module parameter name and perms, same netlink command
and attribute, same exported symbol names and signatures). The concern
is that the accepted input set has narrowed from four strings to one
and the setters reject the legacy three with -EINVAL. For the module
parameter that path runs at module load, so existing modprobe.d configs
written any time in the last ~19 years will cause load-time parameter
errors. Some might categorize that as a regression.
                                      
The commit message documents that non-"pernode" writes now return
-EINVAL. The historically correct approach for this kind of obsoleted
tuning knob is to accept-and-ignore the old values (plus the pr_notice)
rather than hard-fail.

Or, put another way, the proposed patch implements something slightly
different than true backwards compatibility. Userspace that previously
set pool_mode=global/percpu/auto now gets -EINVAL, which technically
speaking is a behavioral narrowing, not "backward compatibility."

I might go even further and suggest that perhaps for v7.2:

- Change the behavior of "auto" to be per-node
- Add a deprecation warning that is emitted when setting other modes,
  but don't warn when the value is specifically the only accepted one.

Then wait a few more cycles before removal of percpu and global.

Other notes:

o The existing pernode path assumes every online node has both CPUs and
  some memory. nr_online_nodes on some platforms (e.g., certain ARM64,
  CXL) counts memoryless or CPU-less nodes; for_each_node_with_cpus()
  vs. for_each_online_node() matters here. See
  svc_pool_map_init_pernode().

o Recommend review of some history on this topic:
  https://lore.kernel.org/linux-nfs/f027319a-378d-4b91-a418-c45218fb7a21@xxxxxxxxxx/


-- 
Chuck Lever