linux-kernel - Re: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Nov 2013 16:22:18 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Johannes Weiner <hannes@...xchg.org>
cc:	Michal Hocko <mhocko@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	cgroups@...r.kernel.org
Subject: Re: [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/