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:0.083 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site