Re: OOM behavior in constrained memory situations

[Andrew Morton <akpm@osdl.org>]

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> On Mon, 6 Feb 2006, Andrew Morton wrote:
> 
> > Do we really want to kill the application?  A more convetional response
> > would be to return NULL from the page allocator and let that trickle back.
> 
> Ok. But ultimately that will lead to a application fault or the 
> termination of the application .

Yup.  The application gets to decide what to do if its stat() or read() or
whatever failed.

> > The hugepage thing is special, because it's a pagefault, not a syscall.
> 
> The same can happen if a pagefault occurs in the application but the page 
> allocator cannot satisfy the allocation. At that point we need to 
> determine if the allocation was restricted. If so then we are not really 
> in an OOM situation and the app could be terminated.
>

Not too sure what you mean here.

The current behaviour of a oom-in-pagefault is to kill the caller via
do_exit(SIGKILL).  (Perhaps hugetlbpages should be doing that too).

If the page allocator decides "hey, this was a restricted allocation
attempt and we cannot satisfy it" then it should return NULL and if it's a
pagefault the app will do the do_exit(SIGKILL).  If it's a syscall, that
syscall will return an error indication (and there's a decent chance that
the application will then misbehave, but that's life).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/