On Wed, Mar 18, 2026 at 10:51:15AM -0700, Breno Leitao wrote:

On Tue, Mar 17, 2026 at 09:58:54AM -0400, Chuck Lever wrote:

quoted

On 3/17/26 7:32 AM, Breno Leitao wrote:

quoted

quoted

- How was the default shard size of 8 picked? There's a tradeoff
between the number of kworkers created and locality. Can you also
report the number of kworkers for each configuration? And is there
data on different shard sizes? It'd be useful to see how the numbers
change across e.g. 4, 8, 16, 32.

The choice of 8 as the default shard size was somewhat arbitrary – it was
selected primarily to generate initial data points.

Perhaps instead of basing the sharding on a particular number of CPUs
per shard, why not cap the total number of shards? IIUC that is the main
concern about ballooning the number of kworker threads.

That's a great suggestion. I'll send a v2 that implements this approach,
where the parameter specifies the number of shards rather than the number
of CPUs per shard.

Woudl it make sense tho? If feels really odd to define the maximum number of
shards when contention is primarily a function of the number of CPUs banging
on the same CPU. Why would 32 cpu and 512 cpu systems have the same number
of shards?

Thanks.

-- 
tejun