Re: [patch 09/18] oom: select task from tasklist for mempolicy ooms

[David Rientjes <rientjes@google.com>]

On Tue, 8 Jun 2010, Andrew Morton wrote:

> > The oom killer presently kills current whenever there is no more memory
> > free or reclaimable on its mempolicy's nodes.  There is no guarantee that
> > current is a memory-hogging task or that killing it will free any
> > substantial amount of memory, however.
> 
> Well OK.  But we don't necesarily *want* to "free a substantial amount
> of memory".  We want to resolve the oom within `current'.  That's the
> sole responsibility of the oom-killer.  It doesn't have to free up
> large amounts of additional memory in the expectation that sometime in
> the future some other task will get an oom as well.  if the oom-killer
> is working well, we can defer those actions until the problem actually
> occurs.
> 

The oom killer has always attempted to kill a task that frees a large 
amount of memory: look at goal #2 in today's badness() heuristic (we 
recover a large amount of memory).  By doing this, we avoid endless loops 
where anything we fork or our bash shell is constantly being oom killed or 
a large number of tasks that only free minimal amounts of memory get 
killed.  The current behavior of killing current rarely works as a single 
remedy without being followed up by additional kills or user intervention.

> Plus: if `current' isn't using much memory then it's probably a
> short-lived or not-very-important process anyway.
> 

That potentially prevents anything bound to that mempolicy from ever 
getting forked.

> > In such situations, it is better to scan the tasklist for nodes that are
> > allowed to allocate on current's set of nodes and kill the task with the
> > highest badness() score.  This ensures that the most memory-hogging task,
> > or the one configured by the user with /proc/pid/oom_adj, is always
> > selected in such scenarios.
> 
> Well... *why* is it better?  Needs more justification/explanation IMO.
> 

This unifies mempolicy oom conditions with the same behavior of cpuset or 
memcg oom conditions: we want to utilize the badness() heuristic to kill 
the best candidate task and not nuke tons of processes for little benefit 
or, for instance, kill all other tasks sharing those same mempolicy nodes 
at the benefit of a memory hogger.  Userspace has the ability to influence 
this heuristic (and even more powerfully with my heuristic rewrite coming 
later in this series) so it can better tune how the kernel reacts to 
mempolicy ooms, which is a key objective of this work.  Simply killing 
current leaves no userspace intervention and can kill meaningful (and 
innocent) tasks which loses work for no reason.

> A long time ago Andrea changed the oom-killer so that it basically
> always killed `current', iirc.  I think that shipped in the Suse
> kernel.

You can do that for the entire oom killer by enabling 
/proc/sys/vm/oom_kill_allocating_task.  SGI wanted that to avoid these 
lengthy tasklist scans.

> Maybe it was only in the case where `current' got an oom when
> satisfying a pagefault, I forget the details.  But according to Andrea,
> this design provided a simple and practical solution to ooms.
> 

Right, VM_FAULT_OOM always killed current and that was recently changed to 
invoke the pagefault oom handler.  Nick has now converted the remaining 
architectures which were not using it to do so, so there is actually no 
difference for pagefaults anymore.  In an earlier revision of this 
rewrite, I wanted pagefault ooms to try killing current first if it were 
killable and then backup to the tasklist scan and heuristic use, but that 
was argued against for not conforming to other memory allocation failures.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>