Re: [PATCH 1/4] mm/swap, memcg: Introduce infrastructure for cgroup-based swap priority

[YoungJun Park <youngjun.park@lge.com>]

> On Fri, Sep 5, 2025 at 4:45 PM Chris Li <chrisl@kernel.org> wrote:
> > >   - Mask computation: precompute at interface write-time vs runtime
> > >     recomputation. (TBD; preference?)
> >
> > Let's start with runtime. We can have a runtime and cached with
> > generation numbers on the toplevel. Any change will reset the top
> > level general number then the next lookup will drop the cache value
> > and re-evaluate.
>
> Scratch that cache value idea. I found the run time evaluation can be
> very simple and elegant.
> Each memcg just needs to store the tier onoff value for the local
> swap.tiers operation. Also a mask to indicate which of those tiers
> present.
> e.g. bits 0-1: default, on bit 0 and off bit 1
>        bits 2-3: zswap, on bit 2 and off bit3
>        bits 4-6: first custom tier
>        ...
>
> The evaluation of the current tier "memcg" to the parent with the
> default tier shortcut can be:
>
>         onoff = memcg->tiers_onoff;
>         mask = memcg->tiers_mask;
>
>         for (p = memcg->parent; p && !has_default(onoff); p = p->parent) {
>                 merge = mask | p->tiers_mask;
>                 new = merge ^ mask;
>                 onoff |= p->tiers_onoff & new;
>                 mask = merge;
>         }
>         if (onoff & DEFAULT_OFF) {
>                 // default off, look for the on tiers to turn on
>         } else {
>                 // default on, look for the off tiers to turn off
>         }
>
> It is an all bit operation that does not need caching at all. This can
> take advantage of the short cut of the default tier. If the default
> tier overwrite exists, no need to search the parent further.
>
> Chris
>

Hi Chris,

Thanks a lot for the clear code and explanation.

I’ll proceed with the runtime evaluation approach you suggested.  
I was initially leaning toward precomputing at write-time since (1) 
cgroup depth is might be deep, and (2) swap I/O paths are far more frequent than config
writes. Is your preference for runtime for implementation simpleness?
(Any other reasons I don't know?)

Thanks again

Best Regards
Youngjun Park