From: Andi Kleen <andi@firstfloor.org>
To: Chuck Ebbert <cebbert@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [patch x86/core] x86: allow number of additional hotplug CPUs to be set at compile time
Date: Thu, 2 Oct 2008 22:40:18 +0200 [thread overview]
Message-ID: <20081002204018.GD8318@one.firstfloor.org> (raw)
In-Reply-To: <20081002160907.68d79e0b@redhat.com>
> The prefix rewriting doesn't happen unless I boot with additional_cpus=0,
> maxcpus=1, or with this patch applied and the config option set. I think
> the rules for when/if the rewriting happens changed a while ago to avoid
> multiple switches and now it's not happening at all on this machine by
> default.
Well then something is broken, but the fix is not to lower num_possible_cpus(),
but to fix the root cause.
Does the appended patch help?
> Oh, and with NR_CPUS=512 I am seeing 1.6MB per-cpu data (I'll have to
> check that, but I remember being surprised at how big the number was.)
How did you measure? And you mean total right? If it's total
then it's ~32KB/CPU which is roughly similar to my 40k number
(probably depends on CONFIG options)
The standard way is __per_cpu_start - __per_cpu_end (on 64bit;
or the other way round on 32bit). That segment is duplicated
per CPU. Ok there are some dynamic data structures that scale too,
so it's possible a little more.
Single per cpu data should not scale with NR_CPUS, but be constant.
-Andi
---
Take disabled cpus into account in alternative.c
Otherwise an UP system with one hotplug CPU will not
go into UP mode.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Index: linux-2.6.27-rc4-misc/arch/x86/kernel/alternative.c
===================================================================
--- linux-2.6.27-rc4-misc.orig/arch/x86/kernel/alternative.c
+++ linux-2.6.27-rc4-misc/arch/x86/kernel/alternative.c
@@ -454,7 +454,7 @@ void __init alternative_instructions(voi
_text, _etext);
/* Only switch to UP mode if we don't immediately boot others */
- if (num_possible_cpus() == 1 || setup_max_cpus <= 1)
+ if (num_possible_cpus() - additional_cpus == 1 || setup_max_cpus <= 1)
alternatives_smp_switch(0);
}
#endif
Index: linux-2.6.27-rc4-misc/arch/x86/kernel/smpboot.c
===================================================================
--- linux-2.6.27-rc4-misc.orig/arch/x86/kernel/smpboot.c
+++ linux-2.6.27-rc4-misc/arch/x86/kernel/smpboot.c
@@ -1276,7 +1276,7 @@ static void remove_siblinginfo(int cpu)
cpu_clear(cpu, cpu_sibling_setup_map);
}
-static int additional_cpus __initdata = -1;
+int additional_cpus = -1;
static __init int setup_additional_cpus(char *s)
{
Index: linux-2.6.27-rc4-misc/include/asm-x86/smp.h
===================================================================
--- linux-2.6.27-rc4-misc.orig/include/asm-x86/smp.h
+++ linux-2.6.27-rc4-misc/include/asm-x86/smp.h
@@ -204,5 +204,7 @@ static inline int hard_smp_processor_id(
extern void cpu_uninit(void);
#endif
+extern int additional_cpus;
+
#endif /* __ASSEMBLY__ */
#endif
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-10-02 20:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 23:19 [patch x86/core] x86: allow number of additional hotplug CPUs to be set at compile time Chuck Ebbert
2008-10-02 8:12 ` Ingo Molnar
2008-10-02 19:30 ` [patch x86/core] x86: allow number of additional hotplug CPUs to be set at compile time, V2 Chuck Ebbert
2008-10-02 19:42 ` Ingo Molnar
2008-10-02 19:48 ` H. Peter Anvin
2008-10-02 19:50 ` Ingo Molnar
2008-10-02 9:12 ` [patch x86/core] x86: allow number of additional hotplug CPUs to be set at compile time Andi Kleen
2008-10-02 19:25 ` Chuck Ebbert
2008-10-02 19:44 ` Andi Kleen
2008-10-02 20:09 ` Chuck Ebbert
2008-10-02 20:40 ` Andi Kleen [this message]
2008-10-04 16:52 ` <PING> " Andi Kleen
2008-10-04 22:30 ` Chuck Ebbert
2008-10-05 10:28 ` Ingo Molnar
2008-10-05 14:52 ` Thomas Gleixner
2008-10-05 15:20 ` Ingo Molnar
2008-10-05 15:51 ` Thomas Gleixner
2008-10-05 15:56 ` Ingo Molnar
2008-10-05 20:39 ` Andi Kleen
2008-10-05 21:49 ` Thomas Gleixner
2008-10-05 22:45 ` Andi Kleen
2008-10-05 20:28 ` Andi Kleen
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=20081002204018.GD8318@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=cebbert@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.