On Thu 13-02-20 08:53:48, Tejun Heo wrote: > Hello, Michal. > > On Thu, Feb 13, 2020 at 08:40:49AM +0100, Michal Hocko wrote: > > So how are we going to deal with hierarchies where the actual workload > > of interest is a leaf deeper in the hierarchy and the upper levels of > > the hierarchy are shared between unrelated workloads? Look at how > > systemd organizes system into cgroups for example (slices vs. scopes) > > and say you want to add a protection to a single user or a service. > > The above scenario where descendants of a cgroup behave unrelated to > each other sound plausible in theory but doesn't really work in > practice because memory management is closely tied with IO and all IO > control mechanisms are strictly hierarchical and arbitrate > level-by-level. > > A workload's memory footprint can't be protected without protecting > its IOs and a descendant cgroup's IOs can't be protected without > protecting its ancestors, so implementing that in memory controller in > isolation, while doable, won't serve many practical purposes. It just > ends up creating cgroups which are punished on memory while greedly > burning up IOs. > > The same pattern for CPU control, so for any practical configuration, > the hierarchy layout has to follow the resource distribution hierarchy > of the system - it's what the whole thing is for after all. The > existing memory.min/low semantics is mostly from failing to recognize > them being closely intertwined with IO and resembling weight based > control mechanisms, and rather blindly copying memory.high/max > behaviors, for which, btw, individual configurations may make sense. Well, I would tend to agree but I can see an existing cgroup hierarchy imposed by systemd and that is more about "logical" organization of processes based on their purpose than anything resembling resources. So what can we do about that to make it all work? -- Michal Hocko SUSE Labs
