Messages in this thread | | | Date | Tue, 11 Aug 2020 20:32:25 +0200 | From | Michal Koutný <> | Subject | Re: [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 <guro@fb.com> 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 used?
> 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.
Thanks, Michal [unhandled content-type:application/pgp-signature] | |