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

[Mel Gorman <mel@csn.ul.ie>]

On Tue, Sep 08, 2009 at 12:51:48PM -0700, David Rientjes wrote:
> 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.
> 

I'm not seeing how it would be considered symmetric to compare allocation
at a boot-time parameter with freeing happening at run-time within a mempolicy.
It's more plausible to me that such a scenario will having the freeing
thread either with no policy or the ability to run with no policy
applied.

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

I don't think we're going to agree on this one. I find it very unlikely
that the process doing the allocation and freeing is going to have
different memory policies.

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

It wouldn't have to be rewritten. At very worst, rearranged at startup
to have the same policy when allocating and freeing.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab