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

On Fri, 2026-06-26 at 09:18 -0400, Chuck Lever wrote:
> On Thu, Jun 25, 2026, at 10:14 PM, NeilBrown wrote:
> > Regarding Chucks comments, I think a minimum of one thread per node,
> > rather than a minimum of one thread total, is the sensible approach.
> > Of course if there exist memory-only nodes, they wouldn't need a thread.
> 
> What happens when transport work is scheduled on a memory-only
> pool? Obviously there's no execution engine there, even if we
> do provide one or more threads.
> 

The hitch here is that we have traditionally allowed userland to
dictate how many threads each pool gets. You're allowed to send down an
array like this with (4 pools):

     0 128 0 0

That would give you exactly that layout (128 threads in pool 2 and none
elsewhere). I think we can continue to honor that by saying that if you
set a thread count of 0 in a pool then we should not spawn any threads
there.

Because of this, I favor a belt and bracers approach:

1/ when min-threads is set, assign at least one thread to each node
that has a cpu as a minimum, but only when we are auto-distributing
threads between nodes (the typical case). This allows us to preserve
the wishes of userland when it sends down a more complex pool array. We
should not override the user's wishes in that case.

2/ add in a fallback in the queueing path so that when there are no
threads in a node, we queue it to a populated one. We could even add a
pr_notice_once() that fires in that case to warn that the configuration
is sub-optimal. The cost is an extra check for sp_nrthreads == 0 when
enqueueing, but it should almost always come back false when things are
properly configured.

-- 
Jeff Layton <[email protected]>