From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: realloc function Date: Wed, 5 Jan 2011 20:25:32 +0100 Message-ID: <20110105192532.GD25713@one.firstfloor.org> References: <4D20B7E6.9020207@cslab.ece.ntua.gr> <4D22461A.4050206@cslab.ece.ntua.gr> <4D246000.8010404@cslab.ece.ntua.gr> <4D24879B.8060205@cslab.ece.ntua.gr> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <4D24879B.8060205@cslab.ece.ntua.gr> Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Vasileios Karakasis Cc: Andi Kleen , linux-numa@vger.kernel.org, 'Kornilios Kourtis' On Wed, Jan 05, 2011 at 05:00:43PM +0200, Vasileios Karakasis wrote: > Peeking inside the mremap() source, I can see that the kernel already > does this, i.e., mremap() preserves the policy of the original vm area. That is true. > > The problem is when the user has not specified a binding for the > original mapping (default policy), in which case copying explicitly the > policy from the old to the new pages won't work either; the new pages > will still have MPOL_DEFAULT. So realloc() cannot guarantee that the new It would be possible to do get_mempolicy MPOL_F_ADDR if policy == MPOL_DEFAULT: get_mempolicy MPOL_F_NODE|MPOL_F_ADDR, &node mbind MPOL_PREFERRED, node But then you end up with preferred instead of default. It should be usually the same, but may not in some corner cases. I guess you're right and that case is too obscure to care about. I guess your original patch without anything was good enough. It may be worth it to add some comments on this rationale though. > pages will be allocated on the same node as the preceding alloc(), > unless there is a way to obtain the actual node that the pages of the > original allocation were allocated on. In my opinion, this isn't a real > problem, because even the simple numa_alloc() using the default policy, > cannot guarantee that the pages will be allocated on the node of the > calling cpu: what if the task is migrated to a different cpu on a > different node, while touching (i.e., allocating) the pages with the > police_memory_int()? process policy and MPOL_DEFAULT are always just heuristics; such races can always occur. They usually should not because the scheduler does not migrate too frequently. -Andi