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/