Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.

David Rientjes
2009-09-09T20:44:28Z

On Wed, 9 Sep 2009, Mel Gorman wrote:

> And to beat a dead horse, it does make sense that an application
> allocating hugepages obey memory policies. It does with dynamic hugepage
> resizing for example. It should have been done years ago and
> unfortunately wasn't but it's not the first time that the behaviour of
> hugepages differed from the core VM.
>

I agree completely, I'm certainly not defending the current implementation
as a sound design and I too would have preferred that it have done the
same as Lee's patchset from the very beginning. The issue I'm raising is
that while we both agree the current behavior is suboptimal and confusing,
it is the long-standing kernel behavior. There are applications out there
that are written to allocate and free hugepages and now changing the pool
from which they can allocate or free to could be problematic.

I'm personally fine with the breakage since I'm aware of this discussion
and can easily fix it in userspace. I'm more concerned about others
leaking hugepages or having their boot scripts break because they are
allocating far fewer hugepages than before. The documentation
(Documentation/vm/hugetlbpage.txt) has always said
/proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that
it's changed, I think it should be done explicitly with a new flag than
implicitly.

Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES,
and only using the new behavior when this is set would be inconsistent or
inadvisible? Since this is a new behavior that will differ from the
long-standing default, it seems like it warrants a new mempolicy flag to
avoid all userspace breakage and make hugepage allocation and freeing with
an underlying mempolicy explicit.

This would address your audience that have been (privately) emailing you
while confused about why the hugepages being allocated from a global
tunable wouldn't be confined to their mempolicy.

--
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: email@kvack.org