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