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

[Michal Hocko <mhocko@suse.com>]

On Tue 20-08-19 09:16:01, Yafang Shao wrote:
> On Tue, Aug 20, 2019 at 5:12 AM Roman Gushchin <guro@fb.com> wrote:
> >
> > On Sun, Aug 18, 2019 at 09:18:06PM -0400, Yafang Shao wrote:
> > > In the current memory.min design, the system is going to do OOM instead
> > > of reclaiming the reclaimable pages protected by memory.min if the
> > > system is lack of free memory. While under this condition, the OOM
> > > killer may kill the processes in the memcg protected by memory.min.
> > > This behavior is very weird.
> > > In order to make it more reasonable, I make some changes in the OOM
> > > killer. In this patch, the OOM killer will do two-round scan. It will
> > > skip the processes under memcg protection at the first scan, and if it
> > > can't kill any processes it will rescan all the processes.
> > >
> > > Regarding the overhead this change may takes, I don't think it will be a
> > > problem because this only happens under system  memory pressure and
> > > the OOM killer can't find any proper victims which are not under memcg
> > > protection.
> >
> > Hi Yafang!
> >
> > The idea makes sense at the first glance, but actually I'm worried
> > about mixing per-memcg and per-process characteristics.
> > Actually, it raises many questions:
> > 1) if we do respect memory.min, why not memory.low too?
> 
> memroy.low is different with memory.min, as the OOM killer will not be
> invoked when it is reached.

Responded in other email thread (please do not post two versions of the
patch on the same day because it makes conversation too scattered and
confusing).

Think of min limit protection as some sort of a more inteligent mlock.
It protects from the regular memory reclaim and it can lead to the OOM
situation (be it global or memcg) but by no means it doesn't prevent
from the system to kill the workload if there is a need. Those two
decisions are simply orthogonal IMHO. The later is a an emergency action
while the former is to help guanratee a runtime behavior of the workload.

To be completely fair, the OOM killer is a sort of the memory reclaim as
well so strictly speaking both mlock and memcg min protection could be
considered but from any practical aspect I can think of I simply do not
see a strong usecase that would justify a more complex oom behavior.
People will be simply confused that the selection is less deterministic
and therefore more confusing.
-- 
Michal Hocko
SUSE Labs