On Mon, 5 Apr 2010 15:40:27 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Mon, 5 Apr 2010, Andrew Morton wrote: > > > > > It's pointless to try to kill current if select_bad_process() did not > > > > find an eligible task to kill in mem_cgroup_out_of_memory() since it's > > > > guaranteed that current is a member of the memcg that is oom and it is, > > > > by definition, unkillable. > > > > > > > > Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> > > > > --- > > > > mm/oom_kill.c | 5 +---- > > > > 1 files changed, 1 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > > > --- a/mm/oom_kill.c > > > > +++ b/mm/oom_kill.c > > > > @@ -500,12 +500,9 @@ void mem_cgroup_out_of_memory(struct mem_cgroup *mem, gfp_t gfp_mask) > > > > read_lock(&tasklist_lock); > > > > retry: > > > > p = select_bad_process(&points, limit, mem, CONSTRAINT_NONE, NULL); > > > > - if (PTR_ERR(p) == -1UL) > > > > + if (!p || PTR_ERR(p) == -1UL) > > > > goto out; > > > > > > > > - if (!p) > > > > - p = current; > > > > - > > > > if (oom_kill_process(p, gfp_mask, 0, points, limit, mem, > > > > "Memory cgroup out of memory")) > > > > goto retry; > > > > > > > > > > Are there any objections to merging this? It's pretty straight-forward > > > given the fact that oom_kill_process() would fail if select_bad_process() > > > returns NULL even if p is set to current since it was not found to be > > > eligible during the tasklist scan. > > > > I've lost the plot on the oom-killer patches. Half the things I'm > > seeing don't even apply. > > > > This patch applies cleanly on mmotm-2010-03-24-14-48 and I don't see > anything that has been added since then that touches > mem_cgroup_out_of_memory(). I'm working on another mmotm at present. > > Perhaps I should drop the lot and we start again. We still haven't > > resolved the procfs back-compat issue, either. > > I haven't seen any outstanding compatibility issues raised. The only > thing that isn't backwards compatible is consolidating > /proc/sys/vm/oom_kill_allocating_task and /proc/sys/vm/oom_dump_tasks into > /proc/sys/vm/oom_kill_quick. We can do that because we've enabled > oom_dump_tasks by default so that systems that use both of these tunables > need to now disable oom_dump_tasks to avoid the costly tasklist scan. This can break stuff, as I've already described - if a startup tool is correctly checking its syscall return values and a /procfs file vanishes, the app may bail out and not work. Others had other objections, iirc. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>