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 patch is drawing the line at "the kernel can no longer do anything to
> > free memory", and that's the line where userspace should be notified or a
> > process killed by the kernel.
> >
> > Giving current access to memory reserves in the oom killer is an
> > optimization so that all reclaim is exhausted prior to declaring
> > that they are necessary, the kernel still has the ability to allow
> > that process to exit and free memory.
>
> "they" are necessary?
>

Memory reserves.

> > This is the same as the oom notifiers within the kernel that free
> > memory from s390 and powerpc archs: the kernel still has the ability
> > to free memory.
>
> They're not the same at all. One is the kernel freeing memory, the
> other is a random coincidence.
>

Current is on the way to memory freeing because it has a pending SIGKILL
or is already exiting, it simply needs access to memory reserves to do so.
This was originally introduced to prevent the oom killer from having to
scan the set of eligible processes and silently giving it access to memory
reserves; we didn't want to emit all of the messages to the kernel log
because scripts (and admins) were looking at the kernel log and seeing
that the oom killer killed something when it really came from a different
source or was already exiting.

We have a differing opinion on what to consider the point of oom (the
"notification line that has to be drawn"). My position is to notify
userspace when the kernel has exhausted its capability to free memory
without killing something. In the case of current exiting or having a
pending SIGKILL, memory is going to be freed, the oom killer simply needs
to preempt the tasklist scan. The situation is going to be remedied. I
defined the notification with this patch to only happen when the kernel
can't free any memory without a kill so that userspace may do so itself.
Michal concurred with that position.

So I'll repeat: if you are interested in situations when the limit is
reached, use memory thresholds, if you are interested in situations where
reclaim is struggling to free memory, use VMPRESSURE_CRITICAL.


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