Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

From: Steven Rostedt <rostedt@goodmis.org>
To: Joel Fernandes <joelaf@google.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Zhaoyang Huang <huangzhaoyang@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN
Date: Tue, 10 Apr 2018 15:05:12 -0400	[thread overview]
Message-ID: <20180410150512.189f849c@gandalf.local.home> (raw)
In-Reply-To: <CAJWu+ooC4hCK31srhBFoAf=qwfFFOyTGsjRRJ9PdxaVsb6waQQ@mail.gmail.com>

On Tue, 10 Apr 2018 11:39:24 -0700
Joel Fernandes <joelaf@google.com> wrote:

> Yes I agree. So lets just do that and no other patches additional
> patches are needed then. Let me know if there's anything else I
> missed?

Yeah, I think there's really no other issue. I'm not going to apply
more patches.

> 
> Also I got a bit confused, I reread all the threads. Zhaoyang's
> current issue is that the OOM hint *IS* working which is what
> triggered your patch to toggle the behavior through an option. Where
> was in this message we are discussing that the OOM hint doesn't always
> work which is not Zhaoyang's current issue. Let me know if I missed
> something? Sorry if I did.

Right, it's that if someone does extend the ring buffer page size while
the system is about to go into OOM, it may be triggered to get killed
even though it's not the culprit of the memory problems. But again,
this is really pushing what happens in the real world. That's the
problem with stress test cases. What happens when it triggers something
that will never actually happen in normal environments, and the fix
just complicates everything for really no benefit.

-- Steve