From: Andrew Morton <akpm@osdl.org>
To: Ashok Raj <ashok.raj@intel.com>
Cc: ashok.raj@intel.com, ntl@pobox.com, 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, pj@sgi.com
Subject: Re: [PATCH] percpu data: only iterate over possible CPUs
Date: Thu, 9 Feb 2006 12:37:29 -0800 [thread overview]
Message-ID: <20060209123729.5fcd3808.akpm@osdl.org> (raw)
In-Reply-To: <20060209105230.A10147@unix-os.sc.intel.com>
Ashok Raj <ashok.raj@intel.com> wrote:
>
> >
> > Does the ACPI problem which you describe occur with present-CPUs,
> > or only with possible-but-not-present ones?
>
> Describing present cpus is not problem.
>
> Only knowing possible-but-not-present upfront is an issue.
>
> logical-cpu-hotplug only: cpu_present_map == cpu_possible_map always
> physical-cpu-hotplug: At boot, cpu_present_map is a subset of possible_map.
>
> Think its best to NOT set cpu_present_map to MASK_ALL as its being proposed,
> but let the arch/platform code figure out early enough to set possible_map
> accurately for that platform. If a platform has no way to determine it,
> then it could use cmdline like what x86_64 introduced (additional_cpus=)
> to overcome that.
There is no proposal to change cpu_present_map.
The problem is cpu_possible_map. That is presently being initialised to
CPU_MASK_ALL, which adversely affects perfoermance. An NR_CPUS=16 kernel
on a 2-way presently has cpu_possible_map=0xffff, which will hurt.
The proposal is this:
From: Andrew Morton <akpm@osdl.org>
Initialising cpu_possible_map to all-ones with CONFIG_HOTPLUG_CPU means that
a) All for_each_cpu() loops will iterate across all NR_CPUS CPUs, rather
than over possible ones. That can be quite expensive.
b) Soon we'll be allocating per-cpu areas only for possible CPUs. So with
CPU_MASK_ALL, we'll be wasting memory.
I also switched voyager over to not use CPU_MASK_ALL in the non-CPU-hotplug
case. Will that break it?
I note that parisc is also using CPU_MASK_ALL. Suggest that it stop doing
that.
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Paul Jackson <pj@sgi.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Zwane Mwaikambo <zwane@linuxpower.ca>
Cc: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/i386/kernel/smpboot.c | 4 ----
arch/i386/mach-voyager/voyager_smp.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff -puN arch/i386/kernel/smpboot.c~x86-dont-initialise-cpu_possible_map-to-all-ones arch/i386/kernel/smpboot.c
--- devel/arch/i386/kernel/smpboot.c~x86-dont-initialise-cpu_possible_map-to-all-ones 2006-02-09 01:11:55.000000000 -0800
+++ devel-akpm/arch/i386/kernel/smpboot.c 2006-02-09 01:12:24.000000000 -0800
@@ -87,11 +87,7 @@ EXPORT_SYMBOL(cpu_online_map);
cpumask_t cpu_callin_map;
cpumask_t cpu_callout_map;
EXPORT_SYMBOL(cpu_callout_map);
-#ifdef CONFIG_HOTPLUG_CPU
-cpumask_t cpu_possible_map = CPU_MASK_ALL;
-#else
cpumask_t cpu_possible_map;
-#endif
EXPORT_SYMBOL(cpu_possible_map);
static cpumask_t smp_commenced_mask;
diff -puN arch/i386/mach-voyager/voyager_smp.c~x86-dont-initialise-cpu_possible_map-to-all-ones arch/i386/mach-voyager/voyager_smp.c
--- devel/arch/i386/mach-voyager/voyager_smp.c~x86-dont-initialise-cpu_possible_map-to-all-ones 2006-02-09 01:11:55.000000000 -0800
+++ devel-akpm/arch/i386/mach-voyager/voyager_smp.c 2006-02-09 01:12:43.000000000 -0800
@@ -240,7 +240,7 @@ static cpumask_t smp_commenced_mask = CP
cpumask_t cpu_callin_map = CPU_MASK_NONE;
cpumask_t cpu_callout_map = CPU_MASK_NONE;
EXPORT_SYMBOL(cpu_callout_map);
-cpumask_t cpu_possible_map = CPU_MASK_ALL;
+cpumask_t cpu_possible_map = CPU_MASK_NONE;
EXPORT_SYMBOL(cpu_possible_map);
/* The per processor IRQ masks (these are usually kept in sync) */
_
next prev parent reply other threads:[~2006-02-09 20:40 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
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 [this message]
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=20060209123729.5fcd3808.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=76306.1226@compuserve.com \
--cc=ak@muc.de \
--cc=ashok.raj@intel.com \
--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.