[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0805032227570.27385@twinlark.arctic.org>
Date: Sat, 3 May 2008 22:29:55 -0700 (PDT)
From: dean gaudet <dean@...tic.org>
To: Andi Kleen <andi@...stfloor.org>
cc: Mel Gorman <mel@....ul.ie>, wli@...omorphy.com, agl@...ibm.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Reserve huge pages for reliable MAP_PRIVATE hugetlbfs
mappings
On Wed, 23 Apr 2008, Andi Kleen wrote:
> Mel Gorman <mel@....ul.ie> writes:
>
> > MAP_SHARED mappings on hugetlbfs reserve huge pages at mmap() time. This is
> > so that all future faults will be guaranteed to succeed. Applications are not
> > expected to use mlock() as this can result in poor NUMA placement.
> >
> > MAP_PRIVATE mappings do not reserve pages. This can result in an application
> > being SIGKILLed later if a large page is not available at fault time. This
> > makes huge pages usage very ill-advised in some cases as the unexpected
> > application failure is intolerable. Forcing potential poor placement with
> > mlock() is not a great solution either.
> >
> > This patch reserves huge pages at mmap() time for MAP_PRIVATE mappings similar
> > to what happens for MAP_SHARED mappings.
>
> This will break all applications that mmap more hugetlbpages than they
> actually use. How do you know these don't exist?
such applications couldn't have existed before the change which added
HugePages_Rsvd... which i admit was sometime between 2.6.11 and 2.6.18 but
from my point of view the inability to actually allocate hugepages without
trapping SIGSEGV/etc was a terrible bug introduced when HugePages_Rsvd was
introduced.
-dean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists