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>, Brent Casavant <bcasavan@sgi.com>,
	Andi Kleen <ak@suse.de>
Cc: Anton Blanchard <anton@samba.org>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: more numa maxnode confusions
Date: Sun, 12 Sep 2004 20:02:53 -0700	[thread overview]
Message-ID: <20040912200253.3d7a6ff5.pj@sgi.com> (raw)

I believe that a merge error on my part is contributing further to the
confusions over the meaning of the 'maxnode' parameter to the numa
mbind/set_mempolicy/get_mempolicy calls.  The question is whether
maxnode should be passed in as the number of bits, or one more than the
number of bits (64 or 65 if MAX_NUMNODES is 64, for example).

I will call these two choices the N64 and N65 choices.

As best as I can reconstruct the events, the following has happened over
the last month:

 1) In the beginning, Andi designed this numa interface to be N65.

 2) About Aug 9, Brent Casavant sent in a patch changing the set (not get)
    side calls, sys_mbind and sys_set_mempolicy, to N64.  This patch
    removed the following line from the implementation of get_nodes() in
    mm/mempolicy.c:

	--maxnode;

 3) Due presumably to a merge confusion on my part, my subsequent
    cpuset patch (the original, largest one now dated Sept 2)
    put this line back in, making the interface N65 again.

So currently, a quick reading of the code (could easily be wrong) tells
me that the compat interfaces and the 'get' side (get_mempolicy) are
always N65, but that the native 'set' side is N64 without my cpuset
patch (but with Brent's patch), but N65 with my cpuset patch, which adds
back in the "--maxnode" line to get_nodes().

Currently, by my reading, Linus' bk tree has the mixed N64/N65
interfaces, since it has Brent's patch, but not my cpuset patch.
Andrew's *-mm tree has the pure N65 interface, due to my cpuset patch
reversing Brent's patch.

My guess is that Andi wants this all N65, and that he didn't agree to
Brent's patch.  If Andi understands different, that's fine -- I'm not
trying to reopen that battle.

Andi:

 0) Are my above statements anywhere close to correct?

 1) Should the "--maxnode" be re-inserted in get_nodes()?

 2) Should it be re-inserted by a separate patch from you,
    rather than as a hidden side affect of my cpuset patch?
    I will gladly remove that line from my cpuset patch, in
    favor of a one-liner from you that re-inserts that line.

Brent:

 1) Would you agree to having your partial N64 patch reversed,
    if my efforts to channel Andi's thoughts have succeeded,
    and he wants the "--maxnode" in the code?

Andrew:

 1) Once it's settled on where we (Andi, mostly) wants to go,
    how do you want the patch(es)?  It seems silly for me to
    send in a patch that undoes the re-insertion, just so Andi
    can send in another patch that redoes it.  I will gladly do
    pretty much anything you and Andi agree to here, but you may
    have to spell it out to me in small, simple words ;).

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

             reply	other threads:[~2004-09-13  3:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-13  3:02 Paul Jackson [this message]
2004-09-13  6:56 ` more numa maxnode confusions 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
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=20040912200253.3d7a6ff5.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