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

[David Rientjes <rientjes@google.com>]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>