Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH RFC 0/5] hard_smp_processor_id overhaul
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
