Re: [LSF/MM/BPF Topic] Performance improvement for Memory Cgroups

[Vlastimil Babka <vbabka@suse.cz>]

On 3/20/25 07:22, Harry Yoo wrote:
> On Tue, Mar 18, 2025 at 11:19:42PM -0700, Shakeel Butt wrote:
> 
> For slab memory, I have an idea:
> 
> Deferring the uncharging of slab objects on free until the CPU slab and
> per-CPU partial slabs are moved to the per-node partial slab list
> might be beneficial.
> 
> Something like:
> 
>     0. SLUB allocator defers uncharging objects if the slab the freed
>        objects belong to is the CPU slab or in the percpu partial slab
>        list.
> 
>     1. memcg_slab_post_alloc_hook() does:
>        1.1 Skips charging, if the object is already charged to the same
>            memcg and has not been uncharged yet.
>        1.2 Uncharges the object if it is charged to a different memcg
>            and then charges it to current memcg.
>        1.3 Charges the object if it's not currently not charged to any memcg.
> 
>     2. deactivate_slab() and __put_partials() uncharges free objects
>        that were not uncharged yet before moving them to the per-node
>        partial slab list.
> 
> Unless 1) we have tasks belonging to many different memcgs on each CPU
> (I'm not an expert on the scheduler's interaction with cgroups, though),
> or 2) load balancing migrates tasks between CPUs too frequently,
> 
> many allocations should hit case 1.1 (Oh, it's already charged to the same
> memcg so skip charging) in the hot path, right?
> 
> Some experiments are needed to determine whether this idea is actually
> beneficial.
> 
> Or has a similar approach been tried before?

I don't think so, it would have to be tried and measured. As I hinted in my
sheaves slot, I doubt the step 0. above happens often enough.

In step 2. you would have to walk the slabs' freelists to check if anything
is charged, right?