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
