lkml.org 
[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 6 Feb 2006 14:26:38 -0800
FromAndrew Morton <>
SubjectRe: OOM behavior in constrained memory situations
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/

\
 
 \ /
  Last update: 2006-02-06 23:27    [from the cache]
©2003-2010