Re: [patch] slab: Do not use mempolicy for kmalloc_node

[Christoph Lameter]

On Wed, 13 Sep 2006, Ravikiran G Thirumalai wrote:

> > We only do this under certain conditions. The main purpose of this 
> > function is to allocate an object without having specified a node.
> 
> Yes, the conditions being cpuset constraints or a mempolicy being in place.
> Again, since objects can be allocated off other nodes under certain
> conditions, I thought it was good to document it...

This is only true for the CONFIG_NUMA case.

> This is the case when we are requesting an object from a non existent
> node/invalid node.  So we have 2 choices, either to spread the allocations 
> as per the cpuset constraints (the same treatment as kmalloc), or to 
> allocate from the requesting node, either ways we are not strictly 
> confirming to the user's choice of node (which we cannot).  I cannot see 
> major advantage or disadvantage either ways, so I chose to keep the policy
> in current mainline code -- spread according to the policy set.

The two cases were your patch still applied memory policies were:

1. nodeid = -1. This is one particular case that we wanted to fix because
   it means use numa_node_id().

2. The case where the nodelist does not yet exist.

AFAIK this situation only occurs on boot strap when we are actually 
attempting to allocate from a different node than what we are running on. 
Falling back to the local node is the right thing to do because we have 
that already working. A process that is running on a node must always have 
the nodelists for all caches allocated. The cpuup callbacks take care of that.

kmalloc_node needs work like page_alloc_node. page_alloc_node() never 
consults memory policies and thus one would not expect kmalloc_node to do 
so either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/