Re: [PATCH RFC] mm, slab: warn when increasing refcount on large kmalloc page

[David Rientjes <rientjes@google.com>]

On Sat, 19 Apr 2025, David Rientjes wrote:

> > > Since slab pages are now frozen, increasing refcount on a page
> > > containing a kmalloc() allocation is not possible anymore. Large kmalloc
> > > pages should ideally behave the same, because the decision for which
> > > allocation size to use them is the slab allocator's implementation
> > > detail, and sizes passed to kmalloc() might depend on e.g. user input.
> > 
> > Agreed.
> > 
> > > Because of some unexpected fallout in the slab pages case (see commit
> > > b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"),
> > > let's take a more cautious approach and before making large kmalloc
> > > pages actually frozen, start warning about code that would try to
> > > increase refcount on them.
> > >
> > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > > ---
> > > I'd like to expose this via slab-next and see if there are any reports.
> > > If not for few weeks, maybe proceed immediately to freezing refcount and
> > > handling it in get_page/put_page exactly like folio_test_slab. Thoughts?
> > 
> > +1
> > 
> > Let's give testing a try.
> > 
> > ...at least it does not hit anything on my box.
> > 
> 
> Same, I ran this through a number of benchmarks on x86 and couldn't find 
> any occurrences of the warning.
> 

Btw, the benchmarks that I normally run regularly on SLUB are kernbench, 
multichase, hackbench, specjbb, will-it-scale, redis, unixbench, netperf 
TCP_RR and UDP_STREAM, on both x86 and arm64.  I haven't run on any other 
architectures recently, but perhaps others do.

Are there any other benchmarks that people normally run for slab allocator 
related changes?