lkml.org 
[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: OOM behavior in constrained memory situations
    Date
    On Monday 06 February 2006 23:16, Christoph Lameter wrote:
    > On Mon, 6 Feb 2006, Andi Kleen wrote:
    >
    > > At least remnants from my old 80% hack to avoid this (huge_page_needed)
    > > seem to be still there in mainline:
    > >
    > > fs/hugetlbfs/inode.c:hugetlbfs_file_mmap
    > >
    > > bytes = huge_pages_needed(mapping, vma);
    > > if (!is_hugepage_mem_enough(bytes))
    > > return -ENOMEM;
    > >
    > >
    > > So something must be broken if this doesn't work. Or did you allocate
    > > the pages in some other way?
    >
    > huge pages are now allocated in the huge fault handler. If it would be
    > returning an OOM then the OOM killer may be activated.

    Sorry Christoph - somehow I have the feeling we're miscommunicating already
    all day.

    Of course they are allocated in the huge fault handler. But the point
    of that check is to check first if there are enough pages free and
    fail the allocation early, just to catch the easy mistakes (has
    races, that is why I called it a 80% solution) Just like
    Linux mmap traditionally worked and still does if you don't enable
    the strict overcommit checking.

    -Andi
    -
    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:28    [W:4.408 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site