On Mon 28-09-20 17:02:16, Johannes Weiner wrote: [...] > My take is that a proactive reclaim feature, whose goal is never to > thrash or punish but to keep the LRUs warm and the workingset trimmed, > would ideally have: > > - a pressure or size target specified by userspace but with > enforcement driven inside the kernel from the allocation path > > - the enforcement work NOT be done synchronously by the workload > (something I'd argue we want for *all* memory limits) > > - the enforcement work ACCOUNTED to the cgroup, though, since it's the > cgroup's memory allocations causing the work (again something I'd > argue we want in general) > > - a delegatable knob that is independent of setting the maximum size > of a container, as that expresses a different type of policy > > - if size target, self-limiting (ha) enforcement on a pressure > threshold or stop enforcement when the userspace component dies > > Thoughts? Agreed with above points. What do you think about http://lkml.kernel.org/r/20200922190859.GH12990@xxxxxxxxxxxxxx. I assume that you do not want to override memory.high to implement this because that tends to be tricky from the configuration POV as you mentioned above. But a new limit (memory.middle for a lack of a better name) to define the background reclaim sounds like a good fit with above points. -- Michal Hocko SUSE Labs
