lkml.org 
[lkml]   [2013]   [Dec]   [11]   [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, 11 Dec 2013, Michal Hocko wrote:

> > Triggering a pointless notification with PF_EXITING is rare, yet one
> > pointless notification can be avoided with the patch.
>
> Sigh. Yes it will avoid one particular and rare race. There will still
> be notifications without oom kills.
>

Would you prefer doing the mem_cgroup_oom_notify() in two places instead:

- immediately before doing oom_kill_process() when it's guaranteed that
the kernel would have killed something, and

- when memory.oom_control == 1 in mem_cgroup_oom_synchronize()?

> Anyway.
> Does the reclaim make any sense for PF_EXITING tasks? Shouldn't we
> simply bypass charges of these tasks automatically. Those tasks will
> free some memory anyway so why to trigger reclaim and potentially OOM
> in the first place? Do we need to go via TIF_MEMDIE loop in the first
> place?
>

I don't see any reason to make an optimization there since they will get
TIF_MEMDIE set if reclaim has failed on one of their charges or if it
results in a system oom through the page allocator's oom killer. It would
be nice to ensure reclaim has had a chance to free memory in the presence
of any other potential parallel memory freeing.


\
 
 \ /
  Last update: 2013-12-12 00:01    [W:1.011 / U:1.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site