On Tue, Jul 14, 2020 at 10:06:32AM -0700, Shakeel Butt wrote: > On Tue, Jul 14, 2020 at 8:39 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > The way we do this right now is having the reclaimer daemon in a > > dedicated top-level cgroup with memory.min protection. > > > > This works well because we have a comprehensive cgroup setup anyway > > and need to protect this daemon (it's oomd - the proactive reclaimer, > > senpai, is a plugin) for other reasons as well. But it's probably a > > royal pain to use if you don't have all of that infrastructure. > > > > One possible idea to make this simpler would be to have a limit knob > > that has a psi/pressure blowout valve. This way you could specify your > > tolerances for paging and what constitutes "cold" memory, and the > > limit unsets itself when pressure moves into harmful territory. This > > would make it safe to use when the reclaimer becomes unresponsive or > > dies altogether, which makes it safe to use from within the > > cgroup. And being separate from max and high means we can delegate it. > > I like this idea and agree with having a separate interface from max > and high. Though why do we want to think of this interface as a limit > interface. Are there additional benefits or use-cases which can > benefit from this semantic? I'm not saying we have to. But one benefit of having a limit rather than a reclaim command knob is that you can prevent cache-polluting scans through file data from unnecessarily exploding the memory footprint of the cgroup. It may be useful to compile a list of applications and goals for such a knob, i.e. the reasons we want to do proactive reclaim in the first place.
