lkml.org 
[lkml]   [2014]   [Jan]   [9]   [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
Andrew requested I reply to this email, so it's old, but here it is.


On Mon, 9 Dec 2013, Johannes Weiner wrote:

> We check for fatal signals during the repeated charge attempts and
> reclaim. Should we be checking for PF_EXITING too?
>

Michal has proposed that patch and I question whether we should be doing
that because if significant memory allocation can be done in the exit()
path after PF_EXITING either now or in the future, then it does not allow
memory to be set aside for system oom handlers given the suggested memcg
configuration from Tejun that limits the amount of "user" memory to a
top-level memcg limit that can be overcommitted below it and bypasses
these charges to root that would disallow the userspace oom handlers from
getting memory that they have been reserved. In other words, if a 64GB
machine has top-level memcgs "user" with limit of 62GB and "oom" with
limit of 2GB for system oom handlers, that 2GB cannot be guaranteed with
all of these bypasses (uncharged memory, such as unaccounted kernel
memory, memory reserves).

> You even re-inforced this motivation by suggesting the separate memcg
> margin check right before the OOM kill, so don't blame us for
> misunderstanding the exact placement of this check as your main
> argument when you repeated it over and over.
>

We've talked about a lot of stuff in these threads, yes.

> All I object to is that the OOM killer is riddled with last-second
> checks of whether the OOM situation is still existant. We establish
> that the context is OOM and once we are certain we are executing,
> period.
>

This patch moves a check from being "last second" to actually before the
oom killer is called at all, you should be pleased.

> Not catching PF_EXITING in the long window between the first reclaim
> and going OOM is a separate issue and I can see that this should be
> fixed but it should be checked before we start invoking OOM.
>

Doesn't seem like an issue with this patch.


\
 
 \ /
  Last update: 2014-01-10 02:01    [W:0.278 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site