Re: realloc function

[Andi Kleen <andi@firstfloor.org>]

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