Re: a case for a destructor for slub: mm_struct

[Mateusz Guzik <mjguzik@gmail.com>]

On Mon, Mar 17, 2025 at 10:02 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 3/17/25 06:42, Harry Yoo wrote:
> > On Fri, Mar 14, 2025 at 01:32:16PM +0100, Mateusz Guzik wrote:
> >> > You mean reclaiming per-cpu objects along withthe slab objects that uses them?
> >> > That sounds like a new slab shrinker for mm_struct?
> >> >
> >>
> >> at least the per-cpu thing, mm_struct itself optionally
> >
> > If we allow reclaiming per-cpu stuff only biut do not reclaim
> > the slab object that contains it...
> >
> > Does that mean the users of the cache need to check if the percpu
> > memory has been reclaimed and if so, should call init routines (e.g.,
> > mm_init())?
>
> That sounds like something we'd better avoid? Think it would need to imply
> some locking between the shrinker and slab allocator so it doesn't hand out
> a mm_struct where its percpu memory is reclaimed.
>
> I hope it's enough if we're able to shrink what slab allocator has cached in
> per-cpu (partial) slabs, there's already flushing of that from e.g. sysfs
> but can't recall if there's a shrinker. Of course there will always be free
> mm_struct objects in partially full slabs due to fragmentation, but I doubt
> we'd need to worry specifically about the percpu memory those "own".

My preference here is that a shrinker will just whack some mm_struct
objects like it would normally happen during memory reclaim.

However, should that be difficult to achieve, whacking just the
per-cpu areas is perfectly doable at an added cost at allocation time
-- you "claim" the obj with an atomic op. After that it is illegal to
whack percpu areas from under you and if they are already missing, you
just allocate them. Getting here is not ideal and preferably avoided
in favor of whacking the entire struct, but it can be done with minor
hacks.

-- 
Mateusz Guzik <mjguzik gmail.com>