public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Paul Jackson <pj@sgi.com>,
	ak@muc.de, Andrew Morton <akpm@osdl.org>,
	Linux Arch list <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] Fix argument checking in sched_setaffinity
Date: Tue, 7 Sep 2004 16:49:36 +0200	[thread overview]
Message-ID: <20040907144936.GD20981@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0409070736100.2299@ppc970.osdl.org>

On Tue, Sep 07, 2004 at 07:40:53AM -0700, Linus Torvalds wrote:
> >     No doubt Andi will veto this for mbind/mempolicy, because it breaks
> >     libnuma's he has in the field - a reasonable concern. 
> 
> Now, it will _only_ break systems that are _both_ 64-bit _and_ big-endian. 
> Little-endian or 32-bit boxes will never care.
> 
> There aren't that many of those machines. I've got one right here (ppc64), 
> but that particular one is guaranteed not to break if only because it's 
> running a 32-bit user space.

ppc64 libnuma is not deployed - the current numactl releases
still don't have the system call numbers and nobody told me 
about hacking them in.

So for me breaking ppc64 would be no problem.

> 
> So it's ppc64, sparc64, s390x and sh64. I suspect the breakage is 
> basically zero, since not only aren't there _that_ many machines out 
> there, the percentage of them that use setaffinity or mbind is likely not 
> that high either.

For mbind() breaking existing ppc64 users is unlikely I agree.

For setaffinity I am not so sure. The system call is around
for a long time and has been used in standard utilities
in distributions also for quite some time.

Also it is commonly used in real time applications. 

So in short I think changing mbind to u32 would be fine,
but I wouldn't do it for sched_setaffinity() 

-Andi

  parent reply	other threads:[~2004-09-07 14:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040831183655.58d784a3.pj@sgi.com>
     [not found] ` <20040904133701.GE33964@muc.de>
     [not found]   ` <20040904171417.67649169.pj@sgi.com>
     [not found]     ` <Pine.LNX.4.58.0409041717230.4735@ppc970.osdl.org>
     [not found]       ` <20040904180548.2dcdd488.pj@sgi.com>
     [not found]         ` <Pine.LNX.4.58.0409041827280.2331@ppc970.osdl.org>
     [not found]           ` <20040904204850.48b7cfbd.pj@sgi.com>
     [not found]             ` <Pine.LNX.4.58.0409042055460.2331@ppc970.osdl.org>
     [not found]               ` <20040904211749.3f713a8a.pj@sgi.com>
     [not found]                 ` <20040904215205.0a067ab8.pj@sgi.com>
     [not found]                   ` <20040906182330.GA79122@muc.de>
     [not found]                     ` <Pine.LNX.4.58.0409061147220.28608@ppc970.osdl.org>
     [not found]                       ` <20040906141142.663941fb.pj@sgi.com>
2004-09-07 14:40                         ` [PATCH] Fix argument checking in sched_setaffinity Linus Torvalds
2004-09-07 14:48                           ` Geert Uytterhoeven
2004-09-07 14:49                           ` Andi Kleen [this message]
2004-09-07 21:44                             ` Ralf Baechle
2004-09-07 22:55                               ` Paul Jackson
2004-09-08  6:58                                 ` Andi Kleen
2004-09-08  7:26                                   ` Paul Jackson
2004-09-08  0:26                             ` Anton Blanchard
2004-09-07 14:50                           ` Matthew Wilcox
2004-09-08  0:24                           ` Anton Blanchard
2004-09-08  0:33                             ` [PATCH] [ppc64] compat_get_bitmap/compat_put_bitmap Anton Blanchard
2004-09-08  0:40                               ` [PATCH] [ppc64] Fix compat cpu affinity on big endian 64bit Anton Blanchard
2004-09-08  0:43                                 ` [PATCH] [ppc64] Fix compat NUMA API " Anton Blanchard
2004-09-08  5:22                                 ` [PATCH] [ppc64] Fix compat cpu affinity " Andrew Morton
2004-09-08  5:34                                   ` Anton Blanchard
2004-09-08  5:43                                     ` Andrew Morton

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=20040907144936.GD20981@wotan.suse.de \
    --to=ak@suse.de \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=pj@sgi.com \
    --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