From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mel Gorman Subject: Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management. Date: Tue, 8 Sep 2009 21:04:51 +0100 Message-ID: <20090908200451.GA6481@csn.ul.ie> References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <20090908104409.GB28127@csn.ul.ie> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Rientjes Cc: Lee Schermerhorn , linux-mm@kvack.org, Andrew Morton , Nishanth Aravamudan , linux-numa@vger.kernel.org, Adam Litke , Andy Whitcroft , Eric Whitney , Randy Dunlap 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