public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: pj@sgi.com, mikpe@csd.uu.se, nickpiggin@yahoo.com.au,
	rusty@rustcorp.com.au, linux-kernel@vger.kernel.org, ak@muc.de,
	ashok.raj@intel.com, hch@infradead.org, jbarnes@sgi.com,
	joe.korty@ccur.com, manfred@colorfullife.com,
	colpatch@us.ibm.com, Simon.Derr@bull.net
Subject: Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation
Date: Fri, 4 Jun 2004 11:38:15 -0700	[thread overview]
Message-ID: <20040604183815.GI21007@holomorphy.com> (raw)
In-Reply-To: <20040604112730.534cca55.akpm@osdl.org>

William Lee Irwin III <wli@holomorphy.com> wrote:
>> _SC_NPROCESSOR_CONF is
>>  unimplementable. NR_CPUS serves as an upper bound on the number of cpus
>>  that may at some time be simultaneously present in the future.

On Fri, Jun 04, 2004 at 11:27:30AM -0700, Andrew Morton wrote:
> NR_CPUS is arguably the correct thing when it comes to copying per-cpu info
> to and from userspace.
> Sometimes userspace wants to know NR_CPUS.  Sometimes it wants to know the
> index of the max possible CPU.  Sometimes, perhaps the index of the max
> online CPU.  Sometimes the max index of the CPUs upon which this task is
> eligible to run.  Sometimes (lame) userspace may want to know, at compile
> time, the maximum number of CPUs which a Linux kernel will ever support.
> It's not completely trivial.
> Which of the above is _SC_NPROCESSOR_CONF supposed to return?

_SC_NPROCESSORS_CONF looks like a glibc extension, and if so it's
somewhat arbitrary. It's not documented in the manpage or the header's
comments. I presumed it was the largest number of cpus that could be
simultaneously online in the running kernel instance (which is NR_CPUS
in current kernels). If it's a standard it's likely to be very poorly-
defined. These things differ as the implementations start varying e.g.
for very sparse cpuid spaces, but not anything we handle now.

I'd have to write more stuff to try to find the rest of these things.
I'm not sure all of them are implementable.

And the luserspace code needs the following atop all that:

--- nr_cpus.c.orig2	2004-06-04 11:23:28.130800560 -0700
+++ nr_cpus.c	2004-06-04 11:27:12.785647832 -0700
@@ -10,28 +10,35 @@
 
 int main(void)
 {
+	int cpus = detect_nr_cpus();
 	printf("%d\n", detect_nr_cpus());
-	return 0;
+	return cpus <= 0;
 }
 
 static int detect_nr_cpus(void)
 {
 	unsigned long *cpus = malloc(sizeof(long));
 	size_t upper, middle, lower = sizeof(long);
+	int ret = -ENOMEM;
 
+	if (!cpus)
+		return -ENOMEM;
 	for (upper = lower; getaffinity(0, upper, cpus) < 0; upper *= 2) {
 		if (!realloc(cpus, 2*upper))
-			return -ENOMEM;
+			goto out;
 	}
 	while (lower < upper - 1) {
 		middle = (lower + upper)/2;
 		if (!realloc(cpus, middle))
-			return -ENOMEM;
+			goto out;
 		if (getaffinity(0, middle, cpus) < 0)
 			lower = middle;
 		else
 			upper = middle;
 	}
+	ret = CHAR_BIT*upper;
+out:
+	free(cpus);
 	return CHAR_BIT*upper;
 }
 

  reply	other threads:[~2004-06-04 18:39 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-03 16:43 [PATCH] Bitmap and Cpumask Cleanup - Overview Paul Jackson
2004-06-03 17:05 ` [PATCH] cpumask 1/10 cpu_present_map real even on non-smp Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 2/10 bitmap cleanup preparation for cpumask overhaul Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 3/10 bitmap inlining and optimizations Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 4/10 uninline find_next_bit on ia64 Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04  0:07   ` Andrew Morton
2004-06-04  0:25     ` Andrew Morton
2004-06-04  2:58       ` Paul Jackson
2004-06-04  2:47     ` Paul Jackson
2004-06-04  2:54       ` David S. Miller
2004-06-04  5:02         ` Paul Jackson
2004-06-04  5:01           ` David S. Miller
2004-06-04  1:47   ` Rusty Russell
2004-06-04  2:02     ` Nick Piggin
2004-06-04  2:19       ` Rusty Russell
2004-06-04  5:18       ` Paul Jackson
2004-06-04  5:22         ` David S. Miller
2004-06-04  6:57           ` Paul Jackson
2004-06-04  9:31         ` Mikael Pettersson
2004-06-04  9:37           ` William Lee Irwin III
2004-06-04  9:46             ` Mikael Pettersson
2004-06-04  9:59               ` William Lee Irwin III
2004-06-04 11:16                 ` Mikael Pettersson
2004-06-04 11:27                   ` William Lee Irwin III
2004-06-04 11:32                     ` William Lee Irwin III
2004-06-04 16:23                       ` Paul Jackson
2004-06-04 16:28                         ` William Lee Irwin III
2004-06-04 17:47                           ` Paul Jackson
2004-06-04 18:12                             ` William Lee Irwin III
2004-06-04 18:20                               ` William Lee Irwin III
2004-06-04 18:27                               ` Andrew Morton
2004-06-04 18:38                                 ` William Lee Irwin III [this message]
2004-06-05  2:51                                   ` William Lee Irwin III
2004-06-05  3:29                                     ` William Lee Irwin III
2004-06-04 18:42                               ` Paul Jackson
2004-06-04 18:42                                 ` William Lee Irwin III
2004-06-05  6:48                                   ` Paul Jackson
2004-06-06  2:07                               ` Rusty Russell
2004-06-06 12:16                                 ` Paul Jackson
2004-06-06 12:13                                   ` William Lee Irwin III
2004-06-06 12:28                                     ` Paul Jackson
2004-06-06 12:36                                       ` William Lee Irwin III
2004-06-06 13:42                                         ` Paul Jackson
2004-06-06 23:20                                   ` Rusty Russell
2004-06-07  6:44                                     ` Paul Jackson
2004-06-04  9:41           ` Andrew Morton
2004-06-05  7:01             ` Paul Jackson
2004-06-04 16:03           ` Paul Jackson
2004-06-04 16:56             ` William Lee Irwin III
2004-06-04 17:29               ` Paul Jackson
2004-06-04 17:52                 ` William Lee Irwin III
2004-06-04 19:01                   ` Paul Jackson
2004-06-04 19:08               ` Anton Blanchard
2004-06-04 19:17                 ` William Lee Irwin III
2004-06-04 20:28                 ` Andrew Morton
2004-06-07  7:55                   ` Anton Blanchard
2004-06-05  7:28                 ` Paul Jackson
2004-06-06  8:07                   ` Paul Jackson
2004-06-06  8:16                     ` William Lee Irwin III
2004-06-05  0:05               ` Paul Jackson
2004-06-05  1:31                 ` William Lee Irwin III
2004-06-05  8:04                   ` Paul Jackson
2004-06-05  8:26                     ` William Lee Irwin III
2004-06-06  8:40                       ` Paul Jackson
2004-06-06 12:34                         ` Paul Jackson
2004-06-07 16:54                       ` fix up compat_sched_[get/set]affinity Joe Korty
2004-06-07 17:07                         ` William Lee Irwin III
2004-06-04  5:30       ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04  5:35         ` Nick Piggin
2004-06-04  5:40           ` Andrew Morton
2004-06-04  5:53             ` Nick Piggin
2004-06-04  6:47             ` Paul Jackson
2004-06-04  4:31     ` Paul Jackson
2004-06-04  8:19   ` William Lee Irwin III
2004-06-04  8:43     ` Keith Owens
2004-06-04  9:54       ` William Lee Irwin III
2004-06-04 17:08         ` Paul Jackson
2004-06-09 16:38         ` William Lee Irwin III
2004-06-04  9:14     ` Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 6/10 remove 26 no longer used cpumask*.h files Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 7/10 remove obsolete cpumask macro uses - i386 arch Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 8/10 remove obsolete cpumask macro uses - other archs Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 9/10 Remove no longer used obsolete macro emulation Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 10/10 optimize various uses of new cpumasks Paul Jackson
2004-06-04  4:27   ` Rusty Russell
2004-06-04  4:40     ` Nick Piggin
2004-06-04  4:51     ` Paul Jackson
2004-06-09  0:09   ` PATCH] cpumask 11/10 comment, spacing tweaks Paul Jackson
  -- strict thread matches above, loose matches on Subject: below --
2004-06-06 15:07 [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Mikael Pettersson
2004-06-06 16:44 ` William Lee Irwin III
2004-06-06 17:46   ` 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=20040604183815.GI21007@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=colpatch@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=jbarnes@sgi.com \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mikpe@csd.uu.se \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=rusty@rustcorp.com.au \
    /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