Re: [linux-next:master] [mm, slab] 298cdbf5f7: will-it-scale.per_process_ops 6.3% regression

"Vlastimil Babka (SUSE)" <[email protected]> Fri, 22 May 2026 16:44:25 +0200
Newsgroups dev.linux.lists.oe-lkp,org.kvack.linux-mm
Message-ID <[email protected]>
On 5/18/26 04:12, Oliver Sang wrote:
> hi, Vlastimil Babka,
> 
> On Thu, May 14, 2026 at 06:02:59PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 5/14/26 18:00, Vlastimil Babka (SUSE) wrote:
>> > On 5/14/26 16:45, Vlastimil Babka (SUSE) wrote:
>> >> On 5/11/26 16:45, kernel test robot wrote:
>> >>> 
>> >>> 
>> >>> Hello,
>> >>> 
>> >>> kernel test robot noticed a 6.3% regression of will-it-scale.per_process_ops on:
>> >> 
>> >> Yay for an optimization that was supposed to have no tradeoffs :)
>> > 
>> > Does this help? I don't expect much, but perhaps...
>> 
>> And a separate measurement with this on top of the previous one, plase?
> 
> we applied previous one in [1] on top of 298cdbf5f7, then applied this one on
> top of [1], the git tree is as below:
> 
> * 487ba8f16af85 mm, slab: ADD_TO_TAIL in __refill_objects_node
> * 200ca7702bc5a mm, slab: simplify __refill_objects_node
> * 298cdbf5f7c9e mm, slab: add an optimistic __slab_try_return_freelist()
> * 1f7c8e1d52428 mm/slub: defer freelist construction until after bulk allocation from a new slab
> 
> in our tests, it seems 200ca7702bc5a have little impact as you expected.
> but 487ba8f16af85 not only recovered the performance regression, it now makes
> the results a little better than 1f7c8e1d52428.

Thanks a lot! I've reshuffled things a bit here, to put the changes that
were not impactful as a cleanup after fixed up version of the original patch.

https://lore.kernel.org/all/20260522-b4-refill-optimistic-return-v3-0-2ba78ec1c6ed@kernel.org/