Re: RFC: Transparent Hugepage support

[Adam Litke <agl@us.ibm.com>]

On Wed, 2009-10-28 at 17:34 +0100, Andi Kleen wrote:
> On Wed, Oct 28, 2009 at 05:22:06PM +0100, Andrea Arcangeli wrote:
> > I want to keep it as transparent as possible and to defer adding user
> > visible interfaces (with the exception of MADV_HUGEPAGE equivalent to
> > MADV_MERGEABLE for the scan daemon) initially. Even MADV_HUGEPAGE
> > might not be necessary, even the disable/enable global flag may not be
> > necessary but that is the absolute minimum tuning that seems
> > useful and so there's not much risk to obsolete it.
> 
> I think you need some user visible interfaces to cleanly handle existing
> reservations on a process base at least, otherwise you'll completely break 
> their semantics.

But we already handle explicit hugepages (with page pools and strict
reservations) via hugetlbfs and libhugetlbfs.  It seems you're just
making an argument for keeping these around (which I certainly agree
with).

> sysctls that change existing semantics greatly are usually a bad idea
> because what should the user do if they have existing applications
> that rely on old semantics, but still want the new functionality?

If you want to reserve some huge pages for a specific, corner-case
application, allocate huge pages the way we do today and use
libhugetlbfs.  Meanwhile, the rest of the system can benefit from this
new interface.

-- 
Thanks,
Adam

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>