[systemd-devel] Unable to check 'effective' cgroup limits
Michal Koutný
mkoutny at suse.com
Thu Jun 9 11:37:49 UTC 2022
Hello.
On Thu, Jun 09, 2022 at 11:40:02AM +0100, Lewis Gaul <lewis.gaul at gmail.com> wrote:
> [Disclaimer: cross posting from
> https://github.com/containers/podman/discussions/14538]
>
> Apologies that this is more of a Linux cgroup question than specific to
> systemd, but I was wondering if someone here might be able to enlighten
> me...
Yes, this is most suitable for cgroups at vger.kernel.org. (Feel free to
continue there.)
> Two questions:
>
> - Why on cgroups v1 do the cpuset controller's
> cpuset.effective_{cpus,mems} seem to simply not work?
It's how it eveolved and instead of changing the accustomed behavior,
there's whole different v2.
> Didn't expect this to fail - shouldn't it automatically impose a stricter
> limit on any child cgroups? Do I need to manually update all child cgroups
> first?
The v1 API simply doesn't implement the hierarchical configuration well
(such that ancestors can always override descendants).
> But can't relax the child's cgroup restriction (i.e. need awareness of CPU
> restrictions already imposed above - how are you supposed to check this in
> a private cgroup namespace?).
<joke>Binary^WExhaustive search?</joke>
> Memory/Hugetlb effective limits
> [...]
> There is a memory.limit_in_bytes file, but no
> memory.effective_limit_in_bytes to reflect parent cgroup restrictions.
>
> Similarly on cgroups v2:
> [...]
> I guess you could traverse up the cgroup hierarchy to find the smallest
> limit being imposed... But this isn't possible inside a private cgroup
> namespace. Is there any way to find the actual cgroup limit imposed?
I've been actually pondering with .effective analogues for limits on v2
for this reasons. Short answer is that's not implemented.
More generally -- why would you want to know the inherited limit?
(For regular memory, there's the idea, that you watch memory.pressure
and adjust your behavior based on that instead of adapting to residue
from memory.max.)
HTH,
Michal
More information about the systemd-devel
mailing list