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

Mel Gorman
2009-09-08T20:04:51Z

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