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

[David Rientjes <rientjes@google.com>]

On Tue, 8 Sep 2009, Mel Gorman wrote:

> > Yes, but the caveat I'm pointing out (and is really clearly described in 
> > your documentation changes here) is that existing applications, shell 
> > scripts, job schedulers, whatever, which currently free all system 
> > hugepages (or do so at a consistent interval down to the surplus 
> > value to reclaim memory) will now leak disjoint pages since the freeing is 
> > now governed by its mempolicy. 
> 
> While this is a possibility, it makes little sense to assume that behaviour. To
> be really bitten by the change, the policy used to allocate huge pages needs
> to be different than the policy used to free them. This would be a bit
> screwy as it would imply the job scheduler allocated pages that would
> then be unusable by the job if policies were being obeyed which makes
> very little sense.
> 

Au contraire, the hugepages= kernel parameter is not restricted to any 
mempolicy.

> > If the benefits of doing this 
> > significantly outweigh that potential for userspace breakage, I have no 
> > objection to it.  I just can't say for certain that it is.
> > 
> 
> An application depending on memory policies to be ignored is pretty broken
> to begin with.
> 

Theoretically, yes, but not in practice.  /proc/sys/vm/nr_hugepages has 
always allocated and freed with disregard to current's mempolicy prior to 
this patchset and it wouldn't be "broken" for an application to assume 
that it will continue to do so.  More broken is assuming that such an 
application should have been written to change its mempolicy to include 
all nodes that have hugepages prior to freeing because someday the kernel 
would change to do mempolicy-restricted hugepage freeing.

--
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>