Paul, responding (incorrectly) to David: > > So, for example, if the task is bound by mems 1-3, and it asks for > > MPOL_INTERLEAVE over 2-4, then initially the mempolicy is only effected > > over node 3 and if it's later expanded to mems 1-8, then the mempolicy is > > effected over nodes 3-5, right? > > > > And if the mems change to 3-8, the mempolicy is remapped to 5-7 even > > though 3-5 (which it already was interleaving over) is still accessible? > > Yes and yes, for this cpuset relative numbering mode.
Paul, correcting himself ... No and yes. The manner in which too many nodes (as requested in a RELATIVE mask) are folded into too small a cpuset is not actually that critical, so long as it doesn't come up empty. However, what I'll be recommending, in a follow-up patch, will be folding the larger set into the smaller one modulo the size of the smaller one. In your example above, the requested policy asked for nodes 2-4, so that means it is trying to lay out a memory policy with at least five (0-4) nodes in consideration. But the cpuset is only allowing three (1-3) nodes at the moment. So for each requested node, we take its number modulo three to see which of the available nodes to include in the interleave. Given N: how many nodes are allowed by the tasks cpuset (3, here) n m := (n % N) r := m-th set node in allowed requested mod 3 result (in set 1, 2, 3 allowed) 2 2 3 3 0 1 4 1 2 Hence your first example would result in an interleave over physical nodes 1, 2, and 3 (the last column above.) ... not just over 3. I intend to post patches you can use to lib/bitmap.c and the related cpumask and nodemask apparatus that compute the above for you. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/