Hello.
On Sat, Aug 17, 2024 at 02:00:15PM GMT, Jan Kratochvil <jkratochvil@xxxxxxxx> wrote:
> Yes, it would be better to subtract the used memory from ancestor (and thus
> even current) cgroups.
Then it becomes a more dynamic characterstics and it leads to
calculations of available memory. I share a link [1] for completeness
and to prevent repeated discussions (that past one ended up with no
memory.stat:avail).
> The original use case of this feature is for cloud nodes running a
> single Java JVM where the sibling cgroups are not an issue.
IIUC, it's a tree like this:
O
/ | \
A B C // B:memory.max < O:memory.max
|
...
|
W // workload
This picture made me realize that memory controller may not be even
enabled all the way down from B to W, i.e. W would have no
memory.max.effective, IOW memory.* attribute would not be the right
place for such an value. That would even apply in the apparently
purposeful case if there was a cgroup NS boundary between B and W.
(At least in the proposed implementation, memory.* file would have to be
decoupled from memory controller, similarly to e.g. cpu.stat:usage_usec.)
Jan, do I get the tree shape right? Are B and W in different cgroup
namespaces?
Thanks,
Michal
[1] https://lore.kernel.org/all/alpine.DEB.2.23.453.2007142018150.2667860@xxxxxxxxxxxxxxxxxxxxxxxxx/
Attachment:
signature.asc
Description: PGP signature
