public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: ak@suse.de, bcasavan@sgi.com, anton@samba.org,
	linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: more numa maxnode confusions
Date: Mon, 13 Sep 2004 01:46:22 -0700	[thread overview]
Message-ID: <20040913014622.3addde90.pj@sgi.com> (raw)
In-Reply-To: <20040913001548.278bf672.akpm@osdl.org>

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@sgi.com> 1.650.933.1373

  parent reply	other threads:[~2004-09-13  8:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-13  3:02 more numa maxnode confusions Paul Jackson
2004-09-13  6:56 ` Andi Kleen
2004-09-13  7:08   ` Paul Jackson
2004-09-13  7:15   ` Andrew Morton
2004-09-13  7:23     ` Andi Kleen
2004-09-13  8:46     ` Paul Jackson [this message]
2004-09-13 12:58       ` [PATCH] undo " Paul Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040913014622.3addde90.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=bcasavan@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox