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

[David Rientjes <rientjes@xxxxxxxxxx>]

On Tue, 8 Sep 2009, Mel Gorman wrote:

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

Imagine a cluster of machines that are all treated equally to serve a 
variety of different production jobs.  One of those production jobs 
requires a very high percentage of hugepages.  In fact, its performance 
gain is directly proportional to the number of hugepages allocated.

It is quite plausible for all machines to be booted with hugepages= to 
achieve the maximum number of hugepages that those machines may support.  
Depending on what jobs they will serve, however, those hugepages may 
immediately be freed (or a subset, depending on other smaller jobs that 
may want them.)  If the job scheduler is bound to a mempolicy which does 
not include all nodes with memory, those hugepages are now leaked.  That 
was not the behavior over the past three or four years until this 
patchset.

That example is not dealing in hypotheticals or assumptions on how people 
use hugepages, it's based on reality.  As I said previously, I don't 
necessarily have an objection to that if it can be shown that the 
advantages significantly outweigh the disadvantages.  I'm not sure I see 
the advantage in being implict vs. explicit, however.  Mempolicy 
allocation and freeing is now _implicit_ because its restricted to 
current's mempolicy when it wasn't before, yet node-targeted hugepage 
allocation and freeing is _explicit_ because it's a new interface and on 
the same granularity.
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html