Messages in this thread | | | Date | Wed, 13 Sep 2006 16:48:58 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [patch] slab: Do not use mempolicy for kmalloc_node |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |