lkml.org 
[lkml]   [2013]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves
On Wed, 27 Nov 2013, Johannes Weiner wrote:

> The long-standing, user-visible definition of the current line agrees
> with me. You can't just redefine this, period.
>
> I tried to explain to you how insane the motivation for this patch is,
> but it does not look like you are reading what I write. But you don't
> get to change user-visible behavior just like that anyway, much less
> so without a sane reason, so this was a complete waste of time :-(
>

If you would like to leave this to Andrew's decision, that's fine.
Michal has already agreed with my patch and has acked it in -mm.

If userspace is going to handle oom conditions, which is possible today
and will be extended in the future, then it should only wakeup as a last
resort when there is no possibility of future memory freeing. It would be
stupid to have userspace wakeup to handle the oom condition and then
require it determine if the kernel simply needed to give it access to
memory reserves for the allocating task to exit and free memory so it
doesn't actually need to do anything.

Section 10 of Documentation/cgroups/memory.txt defines the necessary
actions for processes waiting on this notification to make forward
progress, it doesn't expect a process is already going to exit and free
memory on its own. Waking up in such a condition would be absolutely
ludicrous.

Furthermore, if you're looking for notification simply when the memcg oom
limit has been reached, you can use memory thresholds. If you're looking
for notification simply when reclaim is suffering severe pressure, you can
use VMPRESSURE_CRITICAL.

I've been patient in this thread, but at this point I think everything has
been said and it's pointless to continue going in circles. Thanks for
your time.


\
 
 \ /
  Last update: 2013-11-28 04:41    [W:0.204 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site