Re: more numa maxnode confusions

[Paul Jackson]

Andrew asked:
> Revert what?

The immediate change Andi wants reverted only matters at present in
Linus' bk tree.  My main cpuset patch in your *-mm tree already does the
reversion in *-mm (unfortunately - collision details follow ...).

So I presume that Linus' will apply Andi's reversion patch of earlier this
evening to his bk tree.

But then when you pull in Linus's latest bk changes into your linus.patch,
this will collide with my main cpuset patch.

Both patches will be trying to add back in the same line:

	--maxnode;

to get_nodes() in mm/mempolicy.c.

My guess is that now that you and Linus know about this, you two can
handle the collision by hand - both new lines of code agree on what's to
be done: add the above line back in.

But if there is some other permutation of patches that I can send that
would be smoother, let me know.

The one alternative I can think of that would allow everyone to put this
back on autopilot and forget the details, would be to _remove_ the
following segment of my cpusets-big-numa-cpu-and-memory-placement.patch:

@@ -133,6 +134,7 @@ static int get_nodes(unsigned long *node
 	unsigned long nlongs;
 	unsigned long endmask;
 
+	--maxnode;
 	bitmap_zero(nodes, MAX_NUMNODES);
 	if (maxnode == 0 || !nmask)
 		return 0;

so that Andi's latest reversion path applied cleanly when it came back
at you from Linus' bk tree.  But I understand that usually you like to
layer new patches, not replace or edit existing ones.

Go ahead and remove the above segment, if that seems best to you.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
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/