Re: [RFC PATCH 0/2] memcg_ext: dynamic memory.low and memory.min protection

[Tejun Heo <tj@kernel.org>]

Hello, Hui.

On Wed, Oct 28, 2026 at 10:27:33AM +0000, Hui Zhu wrote:
> memory.low is a request, and what reclaim honors is elow, which
> page_counter_calculate_protection() derives on each pass from the
> parent's elow, the siblings' requests and the tree's usage.  At the
> first level below the reclaim root that comes out equal to what was
> written, and there the knob is enough.  Deeper down it is capped by the
> parent's budget and shared out between siblings according to what they
> claimed and what they use, so what a cgroup wrote and what it ends up
> with can differ.  As far as I can tell none of that is visible from
> userspace: memory.low reads back the declared value, and I could not
> find anything that exports elow.
...
> So the derived value seems to be usable only where it is derived,
> inside the check, and that is where low_policy() sits: it is evaluated
> per pass and is handed that pass's own inputs - the memcg, the reclaim
> target, the elow just computed, the usage - instead of being state that
> is read at the check.

The visibility of effective values is a problem of wider scope, not an
argument for implementing bpf struct_ops. There were discussions in the
past on whether we could expose some meaningful effective value. They
didn't lead to anything conclusive, and we may yet find a way to expose
something more useful.

Also, the hook doesn't use elow to decide anything. mem_cgroup_below_low()
and below_min() return true as long as elow or emin covers the usage.
They ask the policies only once the usage exceeds it, and the only
answer a policy can give is BELOW, which makes reclaim skip the cgroup.
So, what the hook buys in the nested case isn't access to the per-pass
elow. It lets a cgroup escape the ceiling that its parent's protection
imposes on the subtree.

Some of that may be innate to nested protection semantics. One
shortcoming may be that there's no way for a parent to "passthrough" in
terms of protection, because there's no way for a parent to be neutral.
If its memory.low is too low, that's the ceiling for the whole
subhierarchy. If it's set high, the subtree gets the total protection
one way or another. There may be arguments for a different semantics
which changes the shape of the protection.

However, it doesn't make sense to let a BPF program escape the parent's
policy, and, again, none of this is an argument for adding bpf
struct_ops.

> The other half is what a policy can key on.  memory.low has one
> dimension, bytes.  A policy program is not limited to the ctx it is
> handed; it can also use state that other BPF programs keep, so
> protection can be a function of activity rather than of size - a
> workingset refault rate, for instance.  [1] reads those counters from
> BPF and acts on them; it drives reclaim rather than answering a
> protection hook, but the signal it reads is the one such a policy would
> want.  The limit is on the output rather than the input: the hook
> returns a boolean, so it cannot grant anything memory.low cannot.

These signals are all available to userspace. The workingset refault
counters are in memory.stat, PSI is in memory.pressure, and whatever
state other BPF programs keep sits in BPF maps which userspace can read.
So, the inputs aren't the difference. What's left is how quickly and how
often the protection gets adjusted.

That may be an argument, but nothing so far shows that struct_ops is
needed for it. Can you demonstrate a realistic and useful scenario which
can't be achieved from userspace but can be with struct_ops?

Thanks.

--
tejun