[lkml]   [2020]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 4/5] mm: memcg: charge memcg percpu memory to the parent cgroup
On Tue, Aug 11, 2020 at 09:55:27AM -0700, Roman Gushchin <> wrote:
> As I said, there are 2 problems with charging systemd (or a similar daemon):
> 1) It often belongs to the root cgroup.
This doesn't hold for systemd (if we agree that systemd is the most
common case).

> 2) OOMing or failing some random memory allocations is a bad way
> to "communicate" a memory shortage to the daemon.
> What we really want is to prevent creating a huge number of cgroups
There's cgroup.max.descendants for that...

> (including dying cgroups) in some specific sub-tree(s).
...oh, so is this limiting the number of cgroups or limiting resources

> OOMing the daemon or returning -ENOMEM to some random syscalls
> will not help us to reach the goal and likely will bring a bad
> experience to a user.
If we reach the situation when memory for cgroup operations is tight,
it'll disappoint the user either way.
My premise is that a running workload is more valuable than the
accompanying manager.

> In a generic case I don't see how we can charge the cgroup which
> creates cgroups without solving these problems first.
In my understanding, "onbehalveness" is a concept useful for various
kernel threads doing deferred work. Here it's promoted to user processes
managing cgroups.

> And if there is a very special case where we have to limit it,
> we can just add an additional layer:
> ` root or delegated root
> ` manager-parent-cgroup-with-a-limit
> ` manager-cgroup (systemd, docker, ...)
> ` [aggregation group(s)]
> ` job-group-1
> ` ...
> ` job-group-n
If the charge goes to the parent of created cgroup (job-cgroup-i here),
then the layer adds nothing. Am I missing something?

> I'd definitely charge the parent cgroup in all similar cases.
(This would mandate the controllers on the unified hierarchy, which is
fine IMO.) Then the order of enabling controllers on a subtree (e.g.
cpu,memory vs memory,cpu) by the manager would yield different charging.
This seems wrong^W confusing to me.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2020-08-11 20:33    [W:0.149 / U:0.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site