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

David Rientjes
2009-09-08T20:18:01Z

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, 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: email@kvack.org