Re: [PATCH v2] mm, memcg: skip killing processes under memcg protection at first scan

Michal Hocko
2019-08-21T08:05:22Z

On Wed 21-08-19 15:26:56, Yafang Shao wrote:
> On Wed, Aug 21, 2019 at 2:44 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Wed 21-08-19 09:00:39, Yafang Shao wrote:
> > [...]
> > > More possible OOMs is also a strong side effect (and it prevent us
> > > from using it).
> >
> > So why don't you use low limit if the guarantee side of min limit is too
> > strong for you?
>
> Well, I don't know what the best-practice of memory.min is.

It is really a workload reclaim protection. Say you have a memory
consumer which performance characteristics would be noticeably disrupted
by any memory reclaim which then would lead to SLA disruption. This is a
strong requirement/QoS feature and as such comes with its demand on
configuration.

> In our plan, we want to use it to protect the top priority containers
> (e.g. set the memory.min same with memory limit), which may latency
> sensive. Using memory.min may sometimes decrease the refault.
> If we set it too low, it may useless, becasue what memory.min is
> protecting is not specified. And if there're some busrt anon memory
> allocate in this memcg, the memory.min may can't protect any file
> memory.

I am still not seeing why you are considering guarantee (memory.min)
rather than best practice (memory.low) here?
--
Michal Hocko
SUSE Labs