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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 4/16/26 07:49, Hao Li wrote:
> On Wed, Apr 15, 2026 at 01:55:54PM -0700, Vinicius Costa Gomes wrote:
> 
> Great!
> Thanks for sharing those infos!
> 
>> 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.
> 
> 
> I also tried stashing leftover objects into the PCS before, but at the time I
> observed that this could quickly drain the node partial list, which then led to
> slab alloc/free churn, and the end result was a performance regression. So I
> gave up this direction :/
> 
> I took a quick look at the code and performance report in your GitHub repo, and
> the performance gains you showed there are really interesting to me!
> I'm going to try testing it on my own machine as well.
> 
> Also, the idea of a warm_slab looks very interesting. I had previously thought
> about something along similar lines, except that I was considering stashing
> leftover untouched slabs at the per-CPU level. But that would effectively bring
> back the old stale CPU partial list in another form, so I ended up dropping
> that direction. But you direction is really interesting!

I wonder about the conditions when the warm_slab freelist is actually warm.
If we have leftover objects on the slab's freelist after a refill, we didn't
walk that part of the freelist to make it cache-hot. So why is draining that
stashed slab beneficial? Is the benefit rather because of caching more
objects percpu again, and avoiding the partial list and list_lock?

The freelist could be warm in the case the slab was just allocated, but that
should be a minority cases compared to taken from partial list?

> I'd be very happy to see a new approach come out of this. If it's convenient
> for you, I'd love to see an RFC. Thanks!
>