All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Brent Casavant <bcasavan@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] get_nodes mask miscalculation
Date: 10 Aug 2004 17:34:56 +0200
Date: Tue, 10 Aug 2004 17:34:56 +0200	[thread overview]
Message-ID: <20040810153456.GA20269@muc.de> (raw)
In-Reply-To: <Pine.SGI.4.58.0408100936220.23966@kzerza.americas.sgi.com>

On Tue, Aug 10, 2004 at 09:54:08AM -0500, Brent Casavant wrote:
> On Tue, 10 Aug 2004, Andi Kleen wrote:
> 
> > The idea behind this is was to make it behave like select.
> > And select passes highest valid value + 1.
> 
> Not that my opinion is worth much, but this seems a very peculiar
> interface to mimic.

It is the only system call I am aware of that passes a variable
length bitmap.  Do you know of any others? 

> > nodemask."
> 
> Actually, I worked from the following description:
> 
> mbind(3)
> 	. . .
> 	nodemask is a bit field of nodes that contains up to
> 	maxnode bits.
> 	. . .
> 
> This very clearly indicates that I should pass the number of bits
> in the nodemask field, not the number of bits plus one.

I really need to rewrite the mbind manpage - it was a quick
hack job and has several other errors.

> > Problem is that you'll break all existing libnuma binaries
> > which pass NUMA_MAX_NODES + 1. In your scheme the kernel
> > will access one bit beyond the bitmap that got passed,
> > and depending on its random value you may get a failure or not.
> 
> Well, again, not that my opinion carries much weight (nor really should
> it), but this whole off-by-one (or two) interface seems unnecessarily
> confusing.  Is there no way we can get this fixed?  The temporary pain

Sure, new system call slots would do with a small compat wrapper
for the old calls. I'm just not sure it is worth it. I personally
don't find it that confusing, but I'm probably not a good benchmark
for this. 

> of breaking the relatively new libnuma seems worth the price of getting
> this forever cleaned up.

I don't think breaking existing binaries is a good idea. Linux
has higher standards. 

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@muc.de>
To: Brent Casavant <bcasavan@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] get_nodes mask miscalculation
Date: 10 Aug 2004 17:34:56 +0200
Date: Tue, 10 Aug 2004 17:34:56 +0200	[thread overview]
Message-ID: <20040810153456.GA20269@muc.de> (raw)
In-Reply-To: <Pine.SGI.4.58.0408100936220.23966@kzerza.americas.sgi.com>

On Tue, Aug 10, 2004 at 09:54:08AM -0500, Brent Casavant wrote:
> On Tue, 10 Aug 2004, Andi Kleen wrote:
> 
> > The idea behind this is was to make it behave like select.
> > And select passes highest valid value + 1.
> 
> Not that my opinion is worth much, but this seems a very peculiar
> interface to mimic.

It is the only system call I am aware of that passes a variable
length bitmap.  Do you know of any others? 

> > nodemask."
> 
> Actually, I worked from the following description:
> 
> mbind(3)
> 	. . .
> 	nodemask is a bit field of nodes that contains up to
> 	maxnode bits.
> 	. . .
> 
> This very clearly indicates that I should pass the number of bits
> in the nodemask field, not the number of bits plus one.

I really need to rewrite the mbind manpage - it was a quick
hack job and has several other errors.

> > Problem is that you'll break all existing libnuma binaries
> > which pass NUMA_MAX_NODES + 1. In your scheme the kernel
> > will access one bit beyond the bitmap that got passed,
> > and depending on its random value you may get a failure or not.
> 
> Well, again, not that my opinion carries much weight (nor really should
> it), but this whole off-by-one (or two) interface seems unnecessarily
> confusing.  Is there no way we can get this fixed?  The temporary pain

Sure, new system call slots would do with a small compat wrapper
for the old calls. I'm just not sure it is worth it. I personally
don't find it that confusing, but I'm probably not a good benchmark
for this. 

> of breaking the relatively new libnuma seems worth the price of getting
> this forever cleaned up.

I don't think breaking existing binaries is a good idea. Linux
has higher standards. 

-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-08-10 15:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2rr7U-5xT-11@gated-at.bofh.it>
2004-08-10  1:44 ` [PATCH] get_nodes mask miscalculation Andi Kleen
2004-08-10  1:44   ` Andi Kleen
2004-08-10  5:25   ` Paul Jackson
2004-08-10  5:25     ` Paul Jackson
2004-08-10 10:45     ` Andi Kleen
2004-08-10 10:45       ` Andi Kleen
2004-08-17  3:43       ` Paul Jackson
2004-08-17  3:43         ` Paul Jackson
2004-08-10 14:54   ` Brent Casavant
2004-08-10 14:54     ` Brent Casavant
2004-08-10 15:34     ` Andi Kleen [this message]
2004-08-10 15:34       ` Andi Kleen
2004-08-09 22:39 Brent Casavant
2004-08-09 22:39 ` Brent Casavant

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=20040810153456.GA20269@muc.de \
    --to=ak@muc.de \
    --cc=bcasavan@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.