lkml.org 
[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode
On Wed, 17 Feb 2010, KAMEZAWA Hiroyuki wrote:

> > The hugetlb case seems to be the only misuse of VM_FAULT_OOM where it
> > doesn't mean we simply don't have the memory to handle the page fault,
> > i.e. your earlier "memory is exhausted" definition. That was handled well
> > before calling out_of_memory() by simply killing current since we know it
> > is faulting hugetlb pages and its resource is limited.
> >
> > We could pass the vma to pagefault_out_of_memory() and simply kill current
> > if its killable and is_vm_hugetlb_page(vma).
> >
>
> No. hugepage is not only case.
> You may not read but we annoyed i915's driver bug recently and it was clearly
> misuse of VM_FAULT_OOM. Then, we got many reports of OOM killer in these months.
> (thanks to Kosaki about this.)
>

That's been fixed, right?

> quick glance around core codes...
> - HUGEPAGE at el. should return some VM_FAULT_NO_RESOUECE rather than VM_FAULT_OOM.

We can detect this with is_vm_hugetlb_page() if we pass the vma into
pagefault_out_of_memory() without adding another VM_FAULT flag.

> - filemap.c's VM_FAULT_OOM shoudn't call page_fault_oom_kill because it has already
> called oom_killer if it can.

See below.

> - about relayfs, is VM_FAULT_OOM should be BUG_ON()...

That looks appropriate at first glance.

> - filemap_xip.c return VM_FAULT_OOM....but it doesn't seem to be OOM..
> just like VM_FAULT_NO_VALID_PAGE_FOUND. (But I'm not familiar with this area.)
> - fs/buffer.c 's VM_FAULT_OOM is returned oom-killer is called.
> - shmem.c's VM_FAULT_OOM is retuned oom-killer is called.
>

The filemap, shmem, and block_prepare_write() cases will call the oom
killer but, depending on the gfp mask, they will retry their allocations
after the oom killer is called so we should never return VM_FAULT_OOM
because they return -ENOMEM. They fail from either small objsize slab
allocations or with orders less than PAGE_ALLOC_COSTLY_ORDER which by
default continues to retry even if direct reclaim fails. If we're
returning with VM_FAULT_OOM from these handlers, it should only be because
of GFP_NOFS | __GFP_NORETRY or current has been oom killed and still can't
find memory (so we don't care if the oom killer is called again since it
won't kill anything else).

So like I said, I don't really see a need where VM_FAULT_NO_RESOURCE would
be helpful in any case other than hugetlb which we can already detect by
passing the vma into the pagefault oom handler.


\
 
 \ /
  Last update: 2010-02-17 10:13    [W:0.065 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site