From: Ashok Raj <ashok.raj@intel.com>
To: Nathan Lynch <ntl@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>, Eric Dumazet <dada1@cosmosbay.com>,
riel@redhat.com, linux-kernel@vger.kernel.org, torvalds@osdl.org,
mingo@elte.hu, ak@muc.de, 76306.1226@compuserve.com,
wli@holomorphy.com, heiko.carstens@de.ibm.com,
Paul Jackson <pj@sgi.com>
Subject: Re: [PATCH] percpu data: only iterate over possible CPUs
Date: Thu, 9 Feb 2006 09:03:21 -0800 [thread overview]
Message-ID: <20060209090321.A9380@unix-os.sc.intel.com> (raw)
In-Reply-To: <20060209160808.GL18730@localhost.localdomain>; from ntl@pobox.com on Thu, Feb 09, 2006 at 08:08:09AM -0800
On Thu, Feb 09, 2006 at 08:08:09AM -0800, Nathan Lynch wrote:
>
> powerpc/ppc64, for instance, determines the number of possible cpus
> from information exported by firmware (and I'm mystified as to why
> other platforms don't do this). So it's typical to have a kernel an a
> pSeries partition with NR_CPUS=128, but cpu_possible_map = 0xff.
>
Iam assuming in the above ase, cpu_possible_map == cpu_present_map and both
dont change after the OS is booted. v.s in platforms capable of hot-plug
cpus present could grow up to cpu_possible_map (max) when a new cpu is
newly added, that wasnt even present at boot time.
The problem was with ACPI just simply looking at the namespace doesnt
exactly give us an idea of how many processors are possible in this platform.
The reason is we could get more added via SSDT dynamically.
on x86_64, we used the number of disabled cpus reported in MADT at boot time
as an indicator to set cpu_possible_map. So if you had 4 sockets, but just
2 populated, the BIOS would set the missing CPUS with disabled flag. We
simply count the number of disabled CPUs and add to possible map.
Andi added documentation to cover that as well in
Documentation/x86_64/cpu-hotplug-spec as a guideline for BIOS folks.
--
Cheers,
Ashok Raj
- Open Source Technology Center
next prev parent reply other threads:[~2006-02-09 17:05 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200602051959.k15JxoHK001630@hera.kernel.org>
2006-02-07 15:15 ` [PATCH] percpu data: only iterate over possible CPUs Heiko Carstens
2006-02-07 15:31 ` Jens Axboe
2006-02-07 16:25 ` Eric Dumazet
2006-02-07 16:42 ` Linus Torvalds
2006-02-07 17:34 ` Andrew Morton
2006-02-07 17:48 ` Linus Torvalds
2006-02-07 18:30 ` Dipankar Sarma
2006-02-07 18:43 ` Linus Torvalds
2006-02-07 18:53 ` Dipankar Sarma
2006-02-07 19:11 ` Linus Torvalds
2006-02-08 4:40 ` Heiko Carstens
2006-02-08 8:55 ` Ivan Kokshaysky
2006-02-08 22:31 ` Rik van Riel
2006-02-09 1:20 ` Rik van Riel
2006-02-09 1:20 ` Rik van Riel
2006-02-09 3:05 ` Andrew Morton
2006-02-09 3:08 ` Andrew Morton
2006-02-09 4:36 ` Eric Dumazet
2006-02-09 4:45 ` Andrew Morton
2006-02-09 4:56 ` Paul Jackson
2006-02-09 16:08 ` Nathan Lynch
2006-02-09 16:13 ` Heiko Carstens
2006-02-09 16:38 ` Rik van Riel
2006-02-09 16:59 ` Nathan Lynch
2006-02-09 17:37 ` Andi Kleen
2006-02-10 10:05 ` Heiko Carstens
2006-02-10 10:13 ` Andi Kleen
2006-02-11 14:49 ` Heiko Carstens
2006-02-11 18:04 ` Andi Kleen
2006-02-09 17:03 ` Ashok Raj [this message]
2006-02-09 17:23 ` Nathan Lynch
2006-02-09 18:04 ` Andrew Morton
2006-02-09 18:52 ` Ashok Raj
2006-02-09 20:37 ` Andrew Morton
2006-02-09 21:03 ` Ashok Raj
2006-02-10 10:02 ` Andi Kleen
2006-02-10 10:42 ` Andrew Morton
2006-02-10 11:09 ` Eric Dumazet
2006-02-10 11:23 ` Andrew Morton
2006-02-10 11:26 ` Andrew Morton
2006-02-10 14:13 ` Eric Dumazet
2006-02-11 0:10 ` Nathan Lynch
2006-02-11 0:25 ` Andrew Morton
2006-02-10 12:10 ` Andi Kleen
2006-02-10 19:08 ` Andrew Morton
2006-02-09 4:39 ` Eric Dumazet
2006-02-09 4:46 ` Nick Piggin
2006-02-09 8:32 Chuck Ebbert
2006-02-09 8:55 ` Paul Jackson
2006-02-09 9:06 ` Andrew Morton
2006-02-09 9:11 ` Andrew Morton
2006-02-09 10:08 ` Heiko Carstens
2006-02-09 10:13 ` Andrew Morton
2006-02-09 10:23 ` Heiko Carstens
2006-02-09 10:31 ` Andrew Morton
2006-02-09 11:47 ` Heiko Carstens
2006-02-09 12:46 ` Eric Dumazet
2006-02-09 13:12 ` Heiko Carstens
2006-02-09 13:55 ` Eric Dumazet
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=20060209090321.A9380@unix-os.sc.intel.com \
--to=ashok.raj@intel.com \
--cc=76306.1226@compuserve.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=dada1@cosmosbay.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ntl@pobox.com \
--cc=pj@sgi.com \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
--cc=wli@holomorphy.com \
/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.