On Tue, Apr 23, 2019 at 10:04:19AM -0700, Shakeel Butt wrote: > On Tue, Apr 23, 2019 at 9:08 AM Rik van Riel <riel@xxxxxxxxxxx> wrote: > > On Tue, 2019-04-23 at 08:30 -0700, Shakeel Butt wrote: > > This sounds similar to a project Johannes has > > been working on, except he is not tracking which > > memory is idle at all, but only the pressure on > > each cgroup, through the PSI interface: > > > > https://facebookmicrosites.github.io/psi/docs/overview > > > > I think both techniques are orthogonal and can be used concurrently. > This technique proactively reclaims memory and hopes that we don't go > to direct reclaim but in the worst case if we trigger direct reclaim > then we can use PSI to early detect when to give up on reclaim and > trigger oom-kill. > > Another thing I want to point out is our usage model: this proactive > memory reclaim is transparent to the jobs. The admin (infrastructure > owner) is using proactive reclaim to create more schedulable memory > transparently to the job owners. That's our motivation too. We want a more accurate sense of actually "required" RAM for each job, as determined by the job's latency expectations, the access frequency curve, and IO latency (or compression and CPU latency - whatever is used for secondary storage). The latter two change dynamically based on memory and IO access patterns, but psi factors that in. It's supposed to be transparent to the job owners and not impact their performance. It's supposed to help them understand their own memory requirements and the utilization of their resource allotment. Having a better sense of utilization also helps fleet capacity planning.
