lkml.org 
[lkml]   [2020]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] memcg: introduce per-memcg reclaim interface
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@dhcp22.suse.cz. 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

\
 
 \ /
  Last update: 2020-09-29 17:05    [W:0.203 / U:1.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site