Messages in this thread | | | Date | Mon, 6 Feb 2006 14:26:38 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |