Re: [RFC PATCH] slub: spill refill leftover objects into percpu sheaves

[Hao Li <hao.li@linux.dev>]

On Wed, Apr 15, 2026 at 01:55:54PM -0700, Vinicius Costa Gomes wrote:
> I was also looking at these regressions, but I went from a different
> direction, and ended up with 3 patches:
> 
> 1. the regressions showed a lot of increase in the cache misses,
>    which gave me the idea that a cache would help (and it seemed to help)
> 
> 2. Allowing smaller refills (but potentially more frequent);
> 
> 3. A cute (but with small impact) use of prefetch();
> 
> The numbers are here (the commentary from the bot are very hit or miss,
> so don't pay too much attention to them):
> 
> https://github.com/vcgomes/linux/commit/c898c39ee8def5252942281353eda6acdd83d4ea
> 
> I am re-running the tests against a more recent tree, but if you
> want to take a look:
> 
> https://github.com/vcgomes/linux/tree/mm-sheaves-regression-timerfd
> 
> Also, if you feel it's useful, I can send a RFC.
> 

Hi Vinicius,

I tested the three patches in your GitHub repository. Under a 96-process stress
workload, mmap2 achieved about a 3% performance improvement.

For the slub stats, I observed some differences. Here are the results:

(baseline vs 3 patches)
alloc_fastpath +4.6%
alloc_slowpath +0% (and no slowpath in both test)
free_fastpath +0%
free_slowpath +189%
alloc_slab +247%
free_slab +247%
barn_get +8%
barn_put +8%
barn_get_fail +16%
barn_put_fail +0%
free_add_partial -37%
free_remove_partial +247%
sheaf_refill +3.88%

I notice one thing that seems consistent with my approach is the churn in
alloc_slab and free_slab. My impression is that this may be a common issue with
solutions designed at the per-CPU level...

-- 
Thanks,
Hao