LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH RFC 0/5] hard_smp_processor_id overhaul
@ 2007-03-01  7:16 Fernando Luis Vázquez Cao
  2007-03-01 14:06 ` Benjamin LaHaise
  2007-03-02  7:23 ` [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul Horms
  0 siblings, 2 replies; 7+ messages in thread
From: Fernando Luis Vázquez Cao @ 2007-03-01  7:16 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: fastboot, ebiederm, ak, akpm, judith

With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) does not hold true anymore. The reason
being that the dump capture kernel boots on the crashed CPU (the CPU
that invoked crash_kexec).

As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
systems (see "linux/smp.h") is not correct.

This patch-set does the following:

1- Remove hardcoding of hard_smp_processor_id on UP systems.

2- Ask the hardware when possible to obtain the hardware processor id on
i386, x86_64, and ia64, independently of whether CONFIG_SMP is set or
not.

3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h
on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I
guess that hardware features could be used to implement
hard_smp_processor_id even in the UP case, but since I am not an expert
in this architectures I just move the definition.

The patches have been tested on i386, x86_64, and ia64.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH RFC 0/5] hard_smp_processor_id overhaul
  2007-03-01  7:16 [PATCH RFC 0/5] hard_smp_processor_id overhaul Fernando Luis Vázquez Cao
@ 2007-03-01 14:06 ` Benjamin LaHaise
  2007-03-02  3:10   ` Fernando Luis Vázquez Cao
  2007-03-02  4:14   ` [Fastboot] " Vivek Goyal
  2007-03-02  7:23 ` [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul Horms
  1 sibling, 2 replies; 7+ messages in thread
From: Benjamin LaHaise @ 2007-03-01 14:06 UTC (permalink / raw)
  To: Fernando Luis Vázquez Cao
  Cc: Linux Kernel Mailing List, fastboot, ebiederm, ak, akpm, judith

On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> systems (see "linux/smp.h") is not correct.
> 
> This patch-set does the following:
> 
> 1- Remove hardcoding of hard_smp_processor_id on UP systems.

NAK.  This has to be configurable, as many embedded systems don't even 
have APICs.  Please rework the patch set so that there is not any overhead 
for existing UP systems.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH RFC 0/5] hard_smp_processor_id overhaul
  2007-03-01 14:06 ` Benjamin LaHaise
@ 2007-03-02  3:10   ` Fernando Luis Vázquez Cao
  2007-03-02  4:14   ` [Fastboot] " Vivek Goyal
  1 sibling, 0 replies; 7+ messages in thread
From: Fernando Luis Vázquez Cao @ 2007-03-02  3:10 UTC (permalink / raw)
  To: Benjamin LaHaise
  Cc: Linux Kernel Mailing List, fastboot, ebiederm, ak, akpm, judith

On Thu, 2007-03-01 at 09:06 -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > systems (see "linux/smp.h") is not correct.
> > 
> > This patch-set does the following:
> > 
> > 1- Remove hardcoding of hard_smp_processor_id on UP systems.
> 
> NAK.  This has to be configurable, as many embedded systems don't even 
> have APICs.  Please rework the patch set so that there is not any overhead 
> for existing UP systems.
In i386 (with the exception of voyager) and x86_64,
hard_smp_processor_id is not used anywhere in the kernel when there are
no APICs available.

Regarding the overhead, hard_smp_processor_id is used mostly during
initialization and doesn't seem to be used in any fast path in i386,
x86_64, and ia64. All the other architectures are not affected by this
patch, because I kept the hardcoding of hard_smp_processor_id on UP
kernels, and just moved the definition to asm/smp.h because it should be
handled by architecture-speficic code.

So unless strictly necessary I would not like to make this patches
dependent on kdump.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
  2007-03-01 14:06 ` Benjamin LaHaise
  2007-03-02  3:10   ` Fernando Luis Vázquez Cao
@ 2007-03-02  4:14   ` Vivek Goyal
  2007-03-02  8:06     ` Fernando Luis Vázquez Cao
  1 sibling, 1 reply; 7+ messages in thread
From: Vivek Goyal @ 2007-03-02  4:14 UTC (permalink / raw)
  To: Benjamin LaHaise
  Cc: Fernando Luis Vázquez Cao, ebiederm, judith, akpm, fastboot,
	ak, Linux Kernel Mailing List

On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > systems (see "linux/smp.h") is not correct.
> > 
> > This patch-set does the following:
> > 
> > 1- Remove hardcoding of hard_smp_processor_id on UP systems.
> 
> NAK.  This has to be configurable, as many embedded systems don't even 
> have APICs.  Please rework the patch set so that there is not any overhead 
> for existing UP systems.

Fernando did the code audit and found no instance of hard_smp_processor_id
being used for non APIC case. So are embedded systems you are referring,
patching the kernel?

Anyway, I think providing hard_smp_processor_id() definition for UP systems
without APIC does not harm.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
  2007-03-01  7:16 [PATCH RFC 0/5] hard_smp_processor_id overhaul Fernando Luis Vázquez Cao
  2007-03-01 14:06 ` Benjamin LaHaise
@ 2007-03-02  7:23 ` Horms
  1 sibling, 0 replies; 7+ messages in thread
From: Horms @ 2007-03-02  7:23 UTC (permalink / raw)
  To: Fernando Luis Vázquez Cao
  Cc: Linux Kernel Mailing List, akpm, judith, fastboot, ebiederm, ak

On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a hardware ID of 0 (usually referred
> to as BSP on some architectures) does not hold true anymore. The reason
> being that the dump capture kernel boots on the crashed CPU (the CPU
> that invoked crash_kexec).
> 
> As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> systems (see "linux/smp.h") is not correct.
> 
> This patch-set does the following:
> 
> 1- Remove hardcoding of hard_smp_processor_id on UP systems.
> 
> 2- Ask the hardware when possible to obtain the hardware processor id on
> i386, x86_64, and ia64, independently of whether CONFIG_SMP is set or
> not.
> 
> 3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h
> on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I
> guess that hardware features could be used to implement
> hard_smp_processor_id even in the UP case, but since I am not an expert
> in this architectures I just move the definition.
> 
> The patches have been tested on i386, x86_64, and ia64.

Hi Fernando,

These patches seem find to me. Tested on ia64 (Tiger2)

Acked: Simon Horman <horms@verge.net.au>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
  2007-03-02  4:14   ` [Fastboot] " Vivek Goyal
@ 2007-03-02  8:06     ` Fernando Luis Vázquez Cao
  2007-03-02  8:16       ` [PATCH] hard_smp_processor_id definition for UP systems without APIC (i386) Fernando Luis Vázquez Cao
  0 siblings, 1 reply; 7+ messages in thread
From: Fernando Luis Vázquez Cao @ 2007-03-02  8:06 UTC (permalink / raw)
  To: vgoyal
  Cc: Benjamin LaHaise, ebiederm, Linux Kernel Mailing List, fastboot,
	ak, akpm, judith

On Fri, 2007-03-02 at 09:44 +0530, Vivek Goyal wrote:
> On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> > On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > > systems (see "linux/smp.h") is not correct.
> > > 
> > > This patch-set does the following:
> > > 
> > > 1- Remove hardcoding of hard_smp_processor_id on UP systems.
> > 
> > NAK.  This has to be configurable, as many embedded systems don't even 
> > have APICs.  Please rework the patch set so that there is not any overhead 
> > for existing UP systems.
> 
> Fernando did the code audit and found no instance of hard_smp_processor_id
> being used for non APIC case. So are embedded systems you are referring,
> patching the kernel?
> 
> Anyway, I think providing hard_smp_processor_id() definition for UP systems
> without APIC does not harm.
Hi Vivek,

I am replying to this email with a patch that does exactly that.

Thanks,
Fernando


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH] hard_smp_processor_id definition for UP systems without APIC (i386)
  2007-03-02  8:06     ` Fernando Luis Vázquez Cao
@ 2007-03-02  8:16       ` Fernando Luis Vázquez Cao
  0 siblings, 0 replies; 7+ messages in thread
From: Fernando Luis Vázquez Cao @ 2007-03-02  8:16 UTC (permalink / raw)
  To: vgoyal
  Cc: Benjamin LaHaise, ebiederm, Linux Kernel Mailing List, fastboot,
	ak, akpm, judith

Provide hard_smp_processor_id definition also for non apic case.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---

diff -urNp linux-2.6.21-rc2-orig/include/asm-i386/smp.h linux-2.6.21-rc2/include/asm-i386/smp.h
--- linux-2.6.21-rc2-orig/include/asm-i386/smp.h	2007-03-02 16:47:37.000000000 +0900
+++ linux-2.6.21-rc2/include/asm-i386/smp.h	2007-03-02 16:59:42.000000000 +0900
@@ -93,6 +93,7 @@ extern unsigned int num_processors;
 #ifndef __ASSEMBLY__
 
 #ifdef CONFIG_X86_LOCAL_APIC
+
 #ifdef APIC_DEFINITION
 extern int hard_smp_processor_id(void);
 #else
@@ -103,6 +104,13 @@ static inline int hard_smp_processor_id(
 	return GET_APIC_ID(*(unsigned long *)(APIC_BASE+APIC_ID));
 }
 #endif /* APIC_DEFINITION */
+
+#else /* CONFIG_X86_LOCAL_APIC */
+
+#ifndef CONFIG_SMP
+#define hard_smp_processor_id()		0
+#endif
+
 #endif /* CONFIG_X86_LOCAL_APIC */
 
 extern u8 apicid_2_node[];



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-03-02  8:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-01  7:16 [PATCH RFC 0/5] hard_smp_processor_id overhaul Fernando Luis Vázquez Cao
2007-03-01 14:06 ` Benjamin LaHaise
2007-03-02  3:10   ` Fernando Luis Vázquez Cao
2007-03-02  4:14   ` [Fastboot] " Vivek Goyal
2007-03-02  8:06     ` Fernando Luis Vázquez Cao
2007-03-02  8:16       ` [PATCH] hard_smp_processor_id definition for UP systems without APIC (i386) Fernando Luis Vázquez Cao
2007-03-02  7:23 ` [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul Horms

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).