On Mon, Feb 03, 2020 at 04:21:36PM -0500, Johannes Weiner wrote: > On Thu, Jan 30, 2020 at 12:49:29PM +0100, Michal Hocko wrote: > > On Thu 19-12-19 15:07:16, Johannes Weiner wrote: > > > When memory.low is overcommitted - i.e. the children claim more > > > protection than their shared ancestor grants them - the allowance is > > > distributed in proportion to how much each sibling uses their own > > > declared protection: > > > > Has there ever been any actual explanation why do we care about > > overcommitted protection? I have got back to email threads when > > the effective hierarchical protection has been proposed. > > http://lkml.kernel.org/r/20180320223353.5673-1-guro@xxxxxx talks about > > some "leaf memory cgroups are more valuable than others" which sounds ok > > but it doesn't explain why children have to overcommit parent in the > > first place. Do we have any other documentation to explain the usecase? > > I don't think we properly documented it, no. Maybe Roman can elaborate > on that a bit more since he added it. There is simple no way to prevent it. Cgroup v2 UI allows to set any values, and they are never changed automatically on e.g. parent's value change. So the system has to perform reasonably for all possible configurations. Before introducing of effective protections it was way too defensive: it was super easy to disable the protection by exceeding the protection value on some level. So it wasn't possible to rely on it in production. So disabling the protection in case of over-commitment isn't a good option too. Thanks!
