* [PATCH] x86: don't compile vsmp_64 for 32bit
@ 2009-02-26 5:20 Yinghai Lu
2009-02-26 5:40 ` Ingo Molnar
2009-02-26 6:48 ` Ravikiran G Thirumalai
0 siblings, 2 replies; 24+ messages in thread
From: Yinghai Lu @ 2009-02-26 5:20 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton
Cc: linux-kernel@vger.kernel.org
Impact: cleanup
that is only needed when CONFIG_X86_VSMP is defined with 64bit
also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/include/asm/apic.h | 7 +++++++
arch/x86/include/asm/setup.h | 4 ++++
arch/x86/kernel/Makefile | 2 +-
arch/x86/kernel/setup.c | 2 --
arch/x86/kernel/vsmp_64.c | 12 +-----------
5 files changed, 13 insertions(+), 14 deletions(-)
Index: linux-2.6/arch/x86/include/asm/apic.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/apic.h
+++ linux-2.6/arch/x86/include/asm/apic.h
@@ -75,7 +75,14 @@ static inline void default_inquire_remot
#define setup_secondary_clock setup_secondary_APIC_clock
#endif
+#ifdef CONFIG_X86_VSMP
extern int is_vsmp_box(void);
+#else
+static inline int is_vsmp_box(void)
+{
+ return 0;
+}
+#endif
extern void xapic_wait_icr_idle(void);
extern u32 safe_xapic_wait_icr_idle(void);
extern void xapic_icr_write(u32, u32);
Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -64,7 +64,11 @@ extern void x86_quirk_time_init(void);
#include <asm/bootparam.h>
/* Interrupt control for vSMPowered x86_64 systems */
+#ifdef CONFIG_X86_VSMP
void vsmp_init(void);
+#else
+static inline void vsmp_init(void) { }
+#endif
void setup_bios_corruption_check(void);
Index: linux-2.6/arch/x86/kernel/Makefile
===================================================================
--- linux-2.6.orig/arch/x86/kernel/Makefile
+++ linux-2.6/arch/x86/kernel/Makefile
@@ -70,7 +70,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += f
obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
-obj-y += vsmp_64.o
+obj-$(CONFIG_X86_VSMP) += vsmp_64.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_MODULES) += module_$(BITS).o
obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -863,9 +863,7 @@ void __init setup_arch(char **cmdline_p)
reserve_initrd();
-#ifdef CONFIG_X86_64
vsmp_init();
-#endif
io_delay_init();
Index: linux-2.6/arch/x86/kernel/vsmp_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/vsmp_64.c
+++ linux-2.6/arch/x86/kernel/vsmp_64.c
@@ -22,7 +22,7 @@
#include <asm/paravirt.h>
#include <asm/setup.h>
-#if defined CONFIG_PCI && defined CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT
/*
* Interrupt control on vSMPowered systems:
* ~AC is a shadow of IF. If IF is 'on' AC should be 'off'
@@ -114,7 +114,6 @@ static void __init set_vsmp_pv_ops(void)
}
#endif
-#ifdef CONFIG_PCI
static int is_vsmp = -1;
static void __init detect_vsmp_box(void)
@@ -139,15 +138,6 @@ int is_vsmp_box(void)
return 0;
}
}
-#else
-static void __init detect_vsmp_box(void)
-{
-}
-int is_vsmp_box(void)
-{
- return 0;
-}
-#endif
void __init vsmp_init(void)
{
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-26 5:20 [PATCH] x86: don't compile vsmp_64 for 32bit Yinghai Lu @ 2009-02-26 5:40 ` Ingo Molnar 2009-02-26 6:48 ` Ravikiran G Thirumalai 1 sibling, 0 replies; 24+ messages in thread From: Ingo Molnar @ 2009-02-26 5:40 UTC (permalink / raw) To: Yinghai Lu Cc: Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org * Yinghai Lu <yinghai@kernel.org> wrote: > > Impact: cleanup > > that is only needed when CONFIG_X86_VSMP is defined with 64bit > also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI > > Signed-off-by: Yinghai Lu <yinghai@kernel.org> > > --- > arch/x86/include/asm/apic.h | 7 +++++++ > arch/x86/include/asm/setup.h | 4 ++++ > arch/x86/kernel/Makefile | 2 +- > arch/x86/kernel/setup.c | 2 -- > arch/x86/kernel/vsmp_64.c | 12 +----------- > 5 files changed, 13 insertions(+), 14 deletions(-) Applied to tip:x86/apic, thanks Yinghai! Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-26 5:20 [PATCH] x86: don't compile vsmp_64 for 32bit Yinghai Lu 2009-02-26 5:40 ` Ingo Molnar @ 2009-02-26 6:48 ` Ravikiran G Thirumalai 2009-02-26 8:39 ` Yinghai Lu 2009-02-26 11:44 ` Ingo Molnar 1 sibling, 2 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-02-26 6:48 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Wed, Feb 25, 2009 at 09:20:50PM -0800, Yinghai Lu wrote: > >Impact: cleanup > >that is only needed when CONFIG_X86_VSMP is defined with 64bit >also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI > >Signed-off-by: Yinghai Lu <yinghai@kernel.org> > NAK! vsmp64.c is compiled unconditionally for a reason. There are ifdefs in the file to avoid code compilation based on config options. is_vsmp_box() is needed even when CONFIG_X86_VSMP is not enabled, since distro kernels don't ship with CONFIG_X86_VSMP, and since is_vsmp_box() is used to determine whether tsc's can be considered synced or not, this is needed. In the future, I would appreciate if you copy me on cleanups/changes involving vsmp64.c Thanks, Kiran >--- > arch/x86/include/asm/apic.h | 7 +++++++ > arch/x86/include/asm/setup.h | 4 ++++ > arch/x86/kernel/Makefile | 2 +- > arch/x86/kernel/setup.c | 2 -- > arch/x86/kernel/vsmp_64.c | 12 +----------- > 5 files changed, 13 insertions(+), 14 deletions(-) > >Index: linux-2.6/arch/x86/include/asm/apic.h >=================================================================== >--- linux-2.6.orig/arch/x86/include/asm/apic.h >+++ linux-2.6/arch/x86/include/asm/apic.h >@@ -75,7 +75,14 @@ static inline void default_inquire_remot > #define setup_secondary_clock setup_secondary_APIC_clock > #endif > >+#ifdef CONFIG_X86_VSMP > extern int is_vsmp_box(void); >+#else >+static inline int is_vsmp_box(void) >+{ >+ return 0; >+} >+#endif > extern void xapic_wait_icr_idle(void); > extern u32 safe_xapic_wait_icr_idle(void); > extern void xapic_icr_write(u32, u32); >Index: linux-2.6/arch/x86/include/asm/setup.h >=================================================================== >--- linux-2.6.orig/arch/x86/include/asm/setup.h >+++ linux-2.6/arch/x86/include/asm/setup.h >@@ -64,7 +64,11 @@ extern void x86_quirk_time_init(void); > #include <asm/bootparam.h> > > /* Interrupt control for vSMPowered x86_64 systems */ >+#ifdef CONFIG_X86_VSMP > void vsmp_init(void); >+#else >+static inline void vsmp_init(void) { } >+#endif > > void setup_bios_corruption_check(void); > >Index: linux-2.6/arch/x86/kernel/Makefile >=================================================================== >--- linux-2.6.orig/arch/x86/kernel/Makefile >+++ linux-2.6/arch/x86/kernel/Makefile >@@ -70,7 +70,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += f > obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o > obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o > obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o >-obj-y += vsmp_64.o >+obj-$(CONFIG_X86_VSMP) += vsmp_64.o > obj-$(CONFIG_KPROBES) += kprobes.o > obj-$(CONFIG_MODULES) += module_$(BITS).o > obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o >Index: linux-2.6/arch/x86/kernel/setup.c >=================================================================== >--- linux-2.6.orig/arch/x86/kernel/setup.c >+++ linux-2.6/arch/x86/kernel/setup.c >@@ -863,9 +863,7 @@ void __init setup_arch(char **cmdline_p) > > reserve_initrd(); > >-#ifdef CONFIG_X86_64 > vsmp_init(); >-#endif > > io_delay_init(); > >Index: linux-2.6/arch/x86/kernel/vsmp_64.c >=================================================================== >--- linux-2.6.orig/arch/x86/kernel/vsmp_64.c >+++ linux-2.6/arch/x86/kernel/vsmp_64.c >@@ -22,7 +22,7 @@ > #include <asm/paravirt.h> > #include <asm/setup.h> > >-#if defined CONFIG_PCI && defined CONFIG_PARAVIRT >+#ifdef CONFIG_PARAVIRT > /* > * Interrupt control on vSMPowered systems: > * ~AC is a shadow of IF. If IF is 'on' AC should be 'off' >@@ -114,7 +114,6 @@ static void __init set_vsmp_pv_ops(void) > } > #endif > >-#ifdef CONFIG_PCI > static int is_vsmp = -1; > > static void __init detect_vsmp_box(void) >@@ -139,15 +138,6 @@ int is_vsmp_box(void) > return 0; > } > } >-#else >-static void __init detect_vsmp_box(void) >-{ >-} >-int is_vsmp_box(void) >-{ >- return 0; >-} >-#endif > > void __init vsmp_init(void) > { >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-26 6:48 ` Ravikiran G Thirumalai @ 2009-02-26 8:39 ` Yinghai Lu 2009-02-26 11:44 ` Ingo Molnar 1 sibling, 0 replies; 24+ messages in thread From: Yinghai Lu @ 2009-02-26 8:39 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai Ravikiran G Thirumalai wrote: > On Wed, Feb 25, 2009 at 09:20:50PM -0800, Yinghai Lu wrote: >> Impact: cleanup >> >> that is only needed when CONFIG_X86_VSMP is defined with 64bit >> also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI >> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org> >> > > NAK! > vsmp64.c is compiled unconditionally for a reason. There are ifdefs in the > file to avoid code compilation based on config options. is_vsmp_box() is > needed even when CONFIG_X86_VSMP is not enabled, since distro kernels don't ship > with CONFIG_X86_VSMP, and since is_vsmp_box() is used to determine whether > tsc's can be considered synced or not, this is needed. so even CONFIG_X86_VSMP is not defined, you want all x86 systems including 32bit kernel and 64bit kernel to call static int is_vsmp = -1; static void __init detect_vsmp_box(void) { is_vsmp = 0; if (!early_pci_allowed()) return; /* Check if we are running on a ScaleMP vSMPowered box */ if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) == (PCI_VENDOR_ID_SCALEMP | (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16))) is_vsmp = 1; } int is_vsmp_box(void) { if (is_vsmp != -1) return is_vsmp; else { WARN_ON_ONCE(1); return 0; } } > > In the future, I would appreciate if you copy me on cleanups/changes involving > vsmp64.c i didn't touch vsmp64.c YH > > Thanks, > Kiran > >> --- >> arch/x86/include/asm/apic.h | 7 +++++++ >> arch/x86/include/asm/setup.h | 4 ++++ >> arch/x86/kernel/Makefile | 2 +- >> arch/x86/kernel/setup.c | 2 -- >> arch/x86/kernel/vsmp_64.c | 12 +----------- >> 5 files changed, 13 insertions(+), 14 deletions(-) >> >> Index: linux-2.6/arch/x86/include/asm/apic.h >> =================================================================== >> --- linux-2.6.orig/arch/x86/include/asm/apic.h >> +++ linux-2.6/arch/x86/include/asm/apic.h >> @@ -75,7 +75,14 @@ static inline void default_inquire_remot >> #define setup_secondary_clock setup_secondary_APIC_clock >> #endif >> >> +#ifdef CONFIG_X86_VSMP >> extern int is_vsmp_box(void); >> +#else >> +static inline int is_vsmp_box(void) >> +{ >> + return 0; >> +} >> +#endif >> extern void xapic_wait_icr_idle(void); >> extern u32 safe_xapic_wait_icr_idle(void); >> extern void xapic_icr_write(u32, u32); >> Index: linux-2.6/arch/x86/include/asm/setup.h >> =================================================================== >> --- linux-2.6.orig/arch/x86/include/asm/setup.h >> +++ linux-2.6/arch/x86/include/asm/setup.h >> @@ -64,7 +64,11 @@ extern void x86_quirk_time_init(void); >> #include <asm/bootparam.h> >> >> /* Interrupt control for vSMPowered x86_64 systems */ >> +#ifdef CONFIG_X86_VSMP >> void vsmp_init(void); >> +#else >> +static inline void vsmp_init(void) { } >> +#endif >> >> void setup_bios_corruption_check(void); >> >> Index: linux-2.6/arch/x86/kernel/Makefile >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/Makefile >> +++ linux-2.6/arch/x86/kernel/Makefile >> @@ -70,7 +70,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += f >> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o >> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o >> obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o >> -obj-y += vsmp_64.o >> +obj-$(CONFIG_X86_VSMP) += vsmp_64.o >> obj-$(CONFIG_KPROBES) += kprobes.o >> obj-$(CONFIG_MODULES) += module_$(BITS).o >> obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o >> Index: linux-2.6/arch/x86/kernel/setup.c >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/setup.c >> +++ linux-2.6/arch/x86/kernel/setup.c >> @@ -863,9 +863,7 @@ void __init setup_arch(char **cmdline_p) >> >> reserve_initrd(); >> >> -#ifdef CONFIG_X86_64 >> vsmp_init(); >> -#endif >> >> io_delay_init(); >> >> Index: linux-2.6/arch/x86/kernel/vsmp_64.c >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/vsmp_64.c >> +++ linux-2.6/arch/x86/kernel/vsmp_64.c >> @@ -22,7 +22,7 @@ >> #include <asm/paravirt.h> >> #include <asm/setup.h> >> >> -#if defined CONFIG_PCI && defined CONFIG_PARAVIRT >> +#ifdef CONFIG_PARAVIRT >> /* >> * Interrupt control on vSMPowered systems: >> * ~AC is a shadow of IF. If IF is 'on' AC should be 'off' >> @@ -114,7 +114,6 @@ static void __init set_vsmp_pv_ops(void) >> } >> #endif >> >> -#ifdef CONFIG_PCI >> static int is_vsmp = -1; >> >> static void __init detect_vsmp_box(void) >> @@ -139,15 +138,6 @@ int is_vsmp_box(void) >> return 0; >> } >> } >> -#else >> -static void __init detect_vsmp_box(void) >> -{ >> -} >> -int is_vsmp_box(void) >> -{ >> - return 0; >> -} >> -#endif >> >> void __init vsmp_init(void) >> { >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-26 6:48 ` Ravikiran G Thirumalai 2009-02-26 8:39 ` Yinghai Lu @ 2009-02-26 11:44 ` Ingo Molnar 2009-02-27 0:17 ` Ravikiran G Thirumalai 1 sibling, 1 reply; 24+ messages in thread From: Ingo Molnar @ 2009-02-26 11:44 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > On Wed, Feb 25, 2009 at 09:20:50PM -0800, Yinghai Lu wrote: > > > >Impact: cleanup > > > >that is only needed when CONFIG_X86_VSMP is defined with 64bit > >also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI > > > >Signed-off-by: Yinghai Lu <yinghai@kernel.org> > > > > NAK! > vsmp64.c is compiled unconditionally for a reason. There are ifdefs in the > file to avoid code compilation based on config options. is_vsmp_box() is > needed even when CONFIG_X86_VSMP is not enabled, since distro kernels don't ship > with CONFIG_X86_VSMP, and since is_vsmp_box() is used to determine whether > tsc's can be considered synced or not, this is needed. is_vsmp_box() is always available: > >+#ifdef CONFIG_X86_VSMP > > extern int is_vsmp_box(void); > >+#else > >+static inline int is_vsmp_box(void) > >+{ > >+ return 0; > >+} > >+#endif What this patch does is it reduces the kernel's size when CONFIG_X86_VSMP is turned off and also makes the code arguably cleaner. > In the future, I would appreciate if you copy me on > cleanups/changes involving vsmp64.c That is what i did when i queued up the change. That is how you became aware of this commit. Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-26 11:44 ` Ingo Molnar @ 2009-02-27 0:17 ` Ravikiran G Thirumalai 2009-02-28 9:44 ` Ingo Molnar 0 siblings, 1 reply; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-02-27 0:17 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Thu, Feb 26, 2009 at 12:44:57PM +0100, Ingo Molnar wrote: > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > >> On Wed, Feb 25, 2009 at 09:20:50PM -0800, Yinghai Lu wrote: >> > >> >Impact: cleanup >> > >> >that is only needed when CONFIG_X86_VSMP is defined with 64bit >> >also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI >> > >> >Signed-off-by: Yinghai Lu <yinghai@kernel.org> >> > >> >> NAK! >> vsmp64.c is compiled unconditionally for a reason. There are ifdefs in the >> file to avoid code compilation based on config options. is_vsmp_box() is >> needed even when CONFIG_X86_VSMP is not enabled, since distro kernels don't ship >> with CONFIG_X86_VSMP, and since is_vsmp_box() is used to determine whether >> tsc's can be considered synced or not, this is needed. > >is_vsmp_box() is always available: Yes. But it does not really detect if the machine is vsmp. It is just a 'return 0'. > >> >+#ifdef CONFIG_X86_VSMP >> > extern int is_vsmp_box(void); >> >+#else >> >+static inline int is_vsmp_box(void) >> >+{ >> >+ return 0; >> >+} >> >+#endif > >What this patch does is it reduces the kernel's size when >CONFIG_X86_VSMP is turned off and also makes the code arguably >cleaner. True, but by how much? 212 bytes, out of 7285943 bytes which is very very small percentage wise. -bash-3.1$ size results/2.6.29-rc6-defconfig/vmlinux text data bss dec hex filename 7285943 1482684 812968 9581595 92341b results/2.6.29-rc6-defconfig/vmlinux -bash-3.1$ size results/2.6.29-rc6-defconfig+patch/vmlinux text data bss dec hex filename 7285731 1482684 812968 9581383 923347 results/2.6.29-rc6-defconfig+patch/vmlinux Note that most of the code within vsmp64.c is dependent on PARAVIRT and won't get compiled if PARAVIRT is not enabled. We made this code dependent on PARAVIRT rather than CONFIG_X86_VSMP because, vsmp support has two aspects to it. One is a minimal paravirtualization part and the other is internode cacheline support. While CONFIG_X86_VSMP enables both, all that is needed for the paravirtualization part is PARAVIRT. And it is not heavy or penalizing like the internode cacheline setting. This will mean installation of distros with the distro provided installer kernels can be done relatively easily if paravirt is enabled. That's all! > >> In the future, I would appreciate if you copy me on >> cleanups/changes involving vsmp64.c > >That is what i did when i queued up the change. That is how you >became aware of this commit. > Thanks for that. But I started replying to the message before the patch was queued/received your email. But the patch was queued by the time i finished replying. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-27 0:17 ` Ravikiran G Thirumalai @ 2009-02-28 9:44 ` Ingo Molnar 2009-03-02 23:51 ` Ravikiran G Thirumalai 0 siblings, 1 reply; 24+ messages in thread From: Ingo Molnar @ 2009-02-28 9:44 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > On Thu, Feb 26, 2009 at 12:44:57PM +0100, Ingo Molnar wrote: > > > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > > > >> On Wed, Feb 25, 2009 at 09:20:50PM -0800, Yinghai Lu wrote: > >> > > >> >Impact: cleanup > >> > > >> >that is only needed when CONFIG_X86_VSMP is defined with 64bit > >> >also remove dead code about PCI, because CONFIG_X86_VSMP depends on PCI > >> > > >> >Signed-off-by: Yinghai Lu <yinghai@kernel.org> > >> > > >> > >> NAK! > >> vsmp64.c is compiled unconditionally for a reason. There are ifdefs in the > >> file to avoid code compilation based on config options. is_vsmp_box() is > >> needed even when CONFIG_X86_VSMP is not enabled, since distro kernels don't ship > >> with CONFIG_X86_VSMP, and since is_vsmp_box() is used to determine whether > >> tsc's can be considered synced or not, this is needed. > > > >is_vsmp_box() is always available: > > Yes. But it does not really detect if the machine is vsmp. > It is just a 'return 0'. > > > > >> >+#ifdef CONFIG_X86_VSMP > >> > extern int is_vsmp_box(void); > >> >+#else > >> >+static inline int is_vsmp_box(void) > >> >+{ > >> >+ return 0; > >> >+} > >> >+#endif > > > >What this patch does is it reduces the kernel's size when > >CONFIG_X86_VSMP is turned off and also makes the code arguably > >cleaner. > > True, but by how much? 212 bytes, out of 7285943 bytes which > is very very small percentage wise. How does this eliminate the validity of the patch? Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-02-28 9:44 ` Ingo Molnar @ 2009-03-02 23:51 ` Ravikiran G Thirumalai 2009-03-03 0:08 ` Yinghai Lu 2009-03-22 12:48 ` Ingo Molnar 0 siblings, 2 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-02 23:51 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote: > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > >> >> True, but by how much? 212 bytes, out of 7285943 bytes which >> is very very small percentage wise. > >How does this eliminate the validity of the patch? > It costs 212 bytes to leave is_vsmp_box() to not just be a dummy no-op. Having is_vsmp_box() detect if the hardware is indeed vSMP, is meaningful even when CONFIG_VSMP is not turned on. This is because is_vsmp_box() is used to tell the kernel, that although the cpus being used are supposed to have TSCs in sync, they are not really in sync. This is because you cannot ensure TSCs won't drift between multiple boards being aggregated on vSMP systems. Take the case of distro kernels. Distro kernels typically do not have CONFIG_X86_VSMP on. Due to the large internode cacheline setting, CONFIG_VSMP would not be on on the generic distro installer kernels. If is_vsmp_box() is a no-op, the generic distro installer kernels will assume TSCs to be synched, which is bad. Hence, it will be nice if, for the cost of 212 bytes, vsmp64.o be compiled either unconditionally, OR conditionally for 64bit architectures only. The question is, is 212 bytes out of 7285943 bytes too expensive for the generic kernels? I hope not. Thanks, Kiran ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-02 23:51 ` Ravikiran G Thirumalai @ 2009-03-03 0:08 ` Yinghai Lu 2009-03-22 12:48 ` Ingo Molnar 1 sibling, 0 replies; 24+ messages in thread From: Yinghai Lu @ 2009-03-03 0:08 UTC (permalink / raw) To: Ravikiran G Thirumalai, Ingo Molnar, Suresh Siddha Cc: Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai Ravikiran G Thirumalai wrote: > On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote: >> * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: >> >>> True, but by how much? 212 bytes, out of 7285943 bytes which >>> is very very small percentage wise. >> How does this eliminate the validity of the patch? >> > > It costs 212 bytes to leave is_vsmp_box() to not just be a dummy no-op. > Having is_vsmp_box() detect if the hardware is indeed vSMP, is meaningful even when > CONFIG_VSMP is not turned on. This is because is_vsmp_box() is used to > tell the kernel, that although the cpus being used are supposed to have TSCs > in sync, they are not really in sync. This is because > you cannot ensure TSCs won't drift between multiple boards being aggregated > on vSMP systems. Take the case of distro kernels. Distro kernels typically do > not have CONFIG_X86_VSMP on. Due to the large internode cacheline > setting, CONFIG_VSMP would not be on on the generic distro installer kernels. > If is_vsmp_box() is a no-op, the generic distro installer kernels will > assume TSCs to be synched, which is bad. Hence, it will be nice if, for > the cost of 212 bytes, vsmp64.o be compiled either unconditionally, OR > conditionally for 64bit architectures only. The question is, is 212 bytes out > of 7285943 bytes too expensive for the generic kernels? I hope not. we may need to revisit apic_is_clustered_box() /* * apic_is_clustered_box() -- Check if we can expect good TSC * * Thus far, the major user of this is IBM's Summit2 series: * * Clustered boxes may have unsynced TSC problems if they are * multi-chassis. Use available data to take a good guess. * If in doubt, go HPET. */ __cpuinit int apic_is_clustered_box(void) .... /* * If clusters > 2, then should be multi-chassis. * May have to revisit this when multi-core + hyperthreaded CPUs come * out, but AFAIK this will work even for them. */ with intel new cpus with 8 cores and HT enabled, even 2 sockets system will get 3 (?) so called "apic cluster" we really need to use dmi etc way to detect multi-chassis system from now on YH ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-02 23:51 ` Ravikiran G Thirumalai 2009-03-03 0:08 ` Yinghai Lu @ 2009-03-22 12:48 ` Ingo Molnar 2009-03-24 6:14 ` Ravikiran G Thirumalai 1 sibling, 1 reply; 24+ messages in thread From: Ingo Molnar @ 2009-03-22 12:48 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote: > > > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > > > >> > >> True, but by how much? 212 bytes, out of 7285943 bytes which > >> is very very small percentage wise. > > > >How does this eliminate the validity of the patch? > > > > It costs 212 bytes to leave is_vsmp_box() to not just be a dummy > no-op. Having is_vsmp_box() detect if the hardware is indeed vSMP, > is meaningful even when CONFIG_VSMP is not turned on. This is > because is_vsmp_box() is used to tell the kernel, that although > the cpus being used are supposed to have TSCs in sync, they are > not really in sync. This is because you cannot ensure TSCs won't > drift between multiple boards being aggregated on vSMP systems. > Take the case of distro kernels. Distro kernels typically do not > have CONFIG_X86_VSMP on. Due to the large internode cacheline > setting, CONFIG_VSMP would not be on on the generic distro > installer kernels. If is_vsmp_box() is a no-op, the generic distro > installer kernels will assume TSCs to be synched, which is bad. > Hence, it will be nice if, for the cost of 212 bytes, vsmp64.o be > compiled either unconditionally, OR conditionally for 64bit > architectures only. The question is, is 212 bytes out of 7285943 > bytes too expensive for the generic kernels? I hope not. Sorry - got distracted and forgot about this thread. The TSC quirk indeed looks required for your systems - you dont have a reliable TSC due to virtualization, right? Mind sending a patch (partial revert or so) against latest -tip that fixes that? Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-22 12:48 ` Ingo Molnar @ 2009-03-24 6:14 ` Ravikiran G Thirumalai 2009-03-24 9:10 ` Ingo Molnar 2009-03-26 7:57 ` [tip:x86/apic] Revert "x86: don't compile vsmp_64 for 32bit" Ravikiran G Thirumalai 0 siblings, 2 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-24 6:14 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Sun, Mar 22, 2009 at 01:48:18PM +0100, Ingo Molnar wrote: > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > >> On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote: >> > >> >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: >> > >> >> >> >> True, but by how much? 212 bytes, out of 7285943 bytes which >> >> is very very small percentage wise. >> > >> >How does this eliminate the validity of the patch? >> > >> >> It costs 212 bytes to leave is_vsmp_box() to not just be a dummy >> no-op. Having is_vsmp_box() detect if the hardware is indeed vSMP, >> is meaningful even when CONFIG_VSMP is not turned on. This is >> because is_vsmp_box() is used to tell the kernel, that although >> the cpus being used are supposed to have TSCs in sync, they are >> not really in sync. This is because you cannot ensure TSCs won't >> drift between multiple boards being aggregated on vSMP systems. >> Take the case of distro kernels. Distro kernels typically do not >> have CONFIG_X86_VSMP on. Due to the large internode cacheline >> setting, CONFIG_VSMP would not be on on the generic distro >> installer kernels. If is_vsmp_box() is a no-op, the generic distro >> installer kernels will assume TSCs to be synched, which is bad. >> Hence, it will be nice if, for the cost of 212 bytes, vsmp64.o be >> compiled either unconditionally, OR conditionally for 64bit >> architectures only. The question is, is 212 bytes out of 7285943 >> bytes too expensive for the generic kernels? I hope not. > >Sorry - got distracted and forgot about this thread. The TSC quirk >indeed looks required for your systems - you dont have a reliable >TSC due to virtualization, right? > Yes. Also, because there is no way to avoid tsc drift on multiple boards/nodes. >Mind sending a patch (partial revert or so) against latest -tip that >fixes that? > Sure. Here's a revert, it is a partial revert which compiles vsmp64.c only for 64bit architectures. Thanks, Kiran Partial revert of commit 129d8bc828e011bda0b7110a097bf3a0167f966e titled 'x86: don't compile vsmp_64 for 32bit' Commit reverted to compile vsmp_64.c if CONFIG_X86_64 is defined, since is_vsmp_box() needs to indicate that TSCs are not synchronized, and hence, not a valid time source, even when CONFIG_X86_VSMP is not defined. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Index: git.tip/arch/x86/include/asm/apic.h =================================================================== --- git.tip.orig/arch/x86/include/asm/apic.h 2009-03-23 12:50:37.000000000 -0800 +++ git.tip/arch/x86/include/asm/apic.h 2009-03-23 20:21:02.000000000 -0800 @@ -75,7 +75,7 @@ static inline void default_inquire_remot #define setup_secondary_clock setup_secondary_APIC_clock #endif -#ifdef CONFIG_X86_VSMP +#ifdef CONFIG_X86_64 extern int is_vsmp_box(void); #else static inline int is_vsmp_box(void) Index: git.tip/arch/x86/include/asm/setup.h =================================================================== --- git.tip.orig/arch/x86/include/asm/setup.h 2009-03-23 12:50:37.000000000 -0800 +++ git.tip/arch/x86/include/asm/setup.h 2009-03-23 20:19:18.000000000 -0800 @@ -64,7 +64,7 @@ extern void x86_quirk_time_init(void); #include <asm/bootparam.h> /* Interrupt control for vSMPowered x86_64 systems */ -#ifdef CONFIG_X86_VSMP +#ifdef CONFIG_X86_64 void vsmp_init(void); #else static inline void vsmp_init(void) { } Index: git.tip/arch/x86/kernel/Makefile =================================================================== --- git.tip.orig/arch/x86/kernel/Makefile 2009-03-23 12:50:37.000000000 -0800 +++ git.tip/arch/x86/kernel/Makefile 2009-03-23 20:29:34.000000000 -0800 @@ -71,7 +71,6 @@ obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace. obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o -obj-$(CONFIG_X86_VSMP) += vsmp_64.o obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_MODULES) += module_$(BITS).o obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o @@ -121,4 +120,5 @@ ifeq ($(CONFIG_X86_64),y) obj-$(CONFIG_AMD_IOMMU) += amd_iommu_init.o amd_iommu.o obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o + obj-y += vsmp_64.o endif Index: git.tip/arch/x86/kernel/vsmp_64.c =================================================================== --- git.tip.orig/arch/x86/kernel/vsmp_64.c 2009-03-23 12:50:37.000000000 -0800 +++ git.tip/arch/x86/kernel/vsmp_64.c 2009-03-23 21:09:34.000000000 -0800 @@ -22,7 +22,7 @@ #include <asm/paravirt.h> #include <asm/setup.h> -#ifdef CONFIG_PARAVIRT +#if defined CONFIG_PCI && defined CONFIG_PARAVIRT /* * Interrupt control on vSMPowered systems: * ~AC is a shadow of IF. If IF is 'on' AC should be 'off' @@ -114,6 +114,7 @@ static void __init set_vsmp_pv_ops(void) } #endif +#ifdef CONFIG_PCI static int is_vsmp = -1; static void __init detect_vsmp_box(void) @@ -139,6 +140,15 @@ int is_vsmp_box(void) } } +#else +static void __init detect_vsmp_box(void) +{ +} +int is_vsmp_box(void) +{ + return 0; +} +#endif void __init vsmp_init(void) { detect_vsmp_box(); ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-24 6:14 ` Ravikiran G Thirumalai @ 2009-03-24 9:10 ` Ingo Molnar 2009-03-25 18:51 ` Ravikiran G Thirumalai 2009-03-26 7:57 ` [tip:x86/apic] Revert "x86: don't compile vsmp_64 for 32bit" Ravikiran G Thirumalai 1 sibling, 1 reply; 24+ messages in thread From: Ingo Molnar @ 2009-03-24 9:10 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > Sure. Here's a revert, it is a partial revert which compiles > vsmp64.c only for 64bit architectures. hm, why dont you add 'depends on X86_64' to the X86_VSMP Kconfig rules? That's far clear - or am i missing some detail? Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-24 9:10 ` Ingo Molnar @ 2009-03-25 18:51 ` Ravikiran G Thirumalai 2009-03-25 22:16 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-25 18:51 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Tue, Mar 24, 2009 at 10:10:35AM +0100, Ingo Molnar wrote: > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > >> Sure. Here's a revert, it is a partial revert which compiles >> vsmp64.c only for 64bit architectures. > >hm, why dont you add 'depends on X86_64' to the X86_VSMP Kconfig >rules? That's far clear - or am i missing some detail? It is already there, and has been there! But we still need to make vsmp64.c compile only when CONFIG_X86_64 is defined no? Thanks, Kiran ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 18:51 ` Ravikiran G Thirumalai @ 2009-03-25 22:16 ` Jeremy Fitzhardinge 2009-03-25 22:36 ` Ravikiran G Thirumalai 0 siblings, 1 reply; 24+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-25 22:16 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai Ravikiran G Thirumalai wrote: > It is already there, and has been there! But we still need to make > vsmp64.c compile only when CONFIG_X86_64 is defined no? > I still think you should restructure it so that vsmp_64.c only gets compiled with CONFIG_X86_VSMP enabled. Having all that stuff compiled into every kernel seems pretty pointless. J ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 22:16 ` Jeremy Fitzhardinge @ 2009-03-25 22:36 ` Ravikiran G Thirumalai 2009-03-25 23:15 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-25 22:36 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Wed, Mar 25, 2009 at 03:16:14PM -0700, Jeremy Fitzhardinge wrote: > Ravikiran G Thirumalai wrote: >> It is already there, and has been there! But we still need to make >> vsmp64.c compile only when CONFIG_X86_64 is defined no? >> > > I still think you should restructure it so that vsmp_64.c only gets > compiled with CONFIG_X86_VSMP enabled. Having all that stuff compiled into > every kernel seems pretty pointless. > Well, not everything gets compiled in. Only the is_vsmp_box() logic and related stuff gets compiled in. Other paravirt related stuff in vsmp64.c depends on CONFIG_PARAVIRT. Thanks, Kiran ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 22:36 ` Ravikiran G Thirumalai @ 2009-03-25 23:15 ` Jeremy Fitzhardinge 2009-03-25 23:29 ` Ravikiran G Thirumalai 0 siblings, 1 reply; 24+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-25 23:15 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai Ravikiran G Thirumalai wrote: > On Wed, Mar 25, 2009 at 03:16:14PM -0700, Jeremy Fitzhardinge wrote: > >> Ravikiran G Thirumalai wrote: >> >>> It is already there, and has been there! But we still need to make >>> vsmp64.c compile only when CONFIG_X86_64 is defined no? >>> >>> >> I still think you should restructure it so that vsmp_64.c only gets >> compiled with CONFIG_X86_VSMP enabled. Having all that stuff compiled into >> every kernel seems pretty pointless. >> >> > > Well, not everything gets compiled in. Only the is_vsmp_box() logic and > related stuff gets compiled in. Other paravirt related stuff in vsmp64.c > depends on CONFIG_PARAVIRT. > Sure, but it would be cleaner if the whole file were controlled by CONFIG_X86_VSMP. is_vsmp_box() is already defined as const inline returning 0 if !CONFIG_X86_VSMP. J > Thanks, > Kiran > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 23:15 ` Jeremy Fitzhardinge @ 2009-03-25 23:29 ` Ravikiran G Thirumalai 2009-03-25 23:36 ` Thomas Gleixner 2009-03-25 23:58 ` Jeremy Fitzhardinge 0 siblings, 2 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-25 23:29 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Wed, Mar 25, 2009 at 04:15:49PM -0700, Jeremy Fitzhardinge wrote: > Ravikiran G Thirumalai wrote: >> On Wed, Mar 25, 2009 at 03:16:14PM -0700, Jeremy Fitzhardinge wrote: >> >>> Ravikiran G Thirumalai wrote: >>> >>>> It is already there, and has been there! But we still need to make >>>> vsmp64.c compile only when CONFIG_X86_64 is defined no? >>>> >>> I still think you should restructure it so that vsmp_64.c only gets >>> compiled with CONFIG_X86_VSMP enabled. Having all that stuff compiled >>> into every kernel seems pretty pointless. >>> >>> >> >> Well, not everything gets compiled in. Only the is_vsmp_box() logic and >> related stuff gets compiled in. Other paravirt related stuff in vsmp64.c >> depends on CONFIG_PARAVIRT. >> > > Sure, but it would be cleaner if the whole file were controlled by > CONFIG_X86_VSMP. is_vsmp_box() is already defined as const inline > returning 0 if !CONFIG_X86_VSMP. > The point in this thread was, is_vsmp_box() needs to be meaningful even when CONFIG_X86_VSMP is not on. This is needed because is_vsmp_box() is used to determine if the platform has reliable tscs. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 23:29 ` Ravikiran G Thirumalai @ 2009-03-25 23:36 ` Thomas Gleixner 2009-03-26 0:11 ` Ravikiran G Thirumalai 2009-03-25 23:58 ` Jeremy Fitzhardinge 1 sibling, 1 reply; 24+ messages in thread From: Thomas Gleixner @ 2009-03-25 23:36 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Jeremy Fitzhardinge, Ingo Molnar, Yinghai Lu, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Wed, 25 Mar 2009, Ravikiran G Thirumalai wrote: > > Sure, but it would be cleaner if the whole file were controlled by > > CONFIG_X86_VSMP. is_vsmp_box() is already defined as const inline > > returning 0 if !CONFIG_X86_VSMP. > > > > The point in this thread was, is_vsmp_box() needs to be meaningful even when > CONFIG_X86_VSMP is not on. This is needed because is_vsmp_box() is used to > determine if the platform has reliable tscs. Did you even read what Jeremy wrote or bother to look at the code in arch/x86/include/asm/apic.h ? #ifdef CONFIG_X86_VSMP extern int is_vsmp_box(void); #else static inline int is_vsmp_box(void) { return 0; } #endif So the .c file is completely useless if CONFIG_X86_VSMP=n. Thanks, tglx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 23:36 ` Thomas Gleixner @ 2009-03-26 0:11 ` Ravikiran G Thirumalai 0 siblings, 0 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-26 0:11 UTC (permalink / raw) To: Thomas Gleixner Cc: Jeremy Fitzhardinge, Ingo Molnar, Yinghai Lu, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Thu, Mar 26, 2009 at 12:36:11AM +0100, Thomas Gleixner wrote: >On Wed, 25 Mar 2009, Ravikiran G Thirumalai wrote: >> > Sure, but it would be cleaner if the whole file were controlled by >> > CONFIG_X86_VSMP. is_vsmp_box() is already defined as const inline >> > returning 0 if !CONFIG_X86_VSMP. >> > >> >> The point in this thread was, is_vsmp_box() needs to be meaningful even when >> CONFIG_X86_VSMP is not on. This is needed because is_vsmp_box() is used to >> determine if the platform has reliable tscs. > >Did you even read what Jeremy wrote or bother to look at the code in >arch/x86/include/asm/apic.h ? > Might I politely point out the origin of this code: http://lkml.org/lkml/2009/2/26/5 Please note the subject of the patch in the link and the subject of this discussion. It is the same thread. The patch was commited to tip and is still being discussed if it is any clarification :) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 23:29 ` Ravikiran G Thirumalai 2009-03-25 23:36 ` Thomas Gleixner @ 2009-03-25 23:58 ` Jeremy Fitzhardinge 2009-03-26 0:31 ` Ravikiran G Thirumalai 1 sibling, 1 reply; 24+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-25 23:58 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai Ravikiran G Thirumalai wrote: > The point in this thread was, is_vsmp_box() needs to be meaningful even when > CONFIG_X86_VSMP is not on. This is needed because is_vsmp_box() is used to > determine if the platform has reliable tscs. > Well, as I said, that code is inoperative at present. But aside from that, how well will a non-VSMP kernel work on your hardware, with a normal cacheline, etc. Is the tsc stability really all that important, given that the kernel should notice if the tsc is busted pretty quickly anyway. unsynchronized_tsc() just returns a guess anyway, and if you don't have X86_FEATURE_CONSTANT_TSC set, then it will return unstable for your hardware anyway, even without the is_vsmp_box() test. Failing that, you could add yourself to bad_tsc_dmi_table[] and have that mark the tsc as unstable (you have DMI, right?). J ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-25 23:58 ` Jeremy Fitzhardinge @ 2009-03-26 0:31 ` Ravikiran G Thirumalai 2009-03-26 9:11 ` Ingo Molnar 0 siblings, 1 reply; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-26 0:31 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Wed, Mar 25, 2009 at 04:58:59PM -0700, Jeremy Fitzhardinge wrote: > Ravikiran G Thirumalai wrote: >> The point in this thread was, is_vsmp_box() needs to be meaningful even >> when >> CONFIG_X86_VSMP is not on. This is needed because is_vsmp_box() is used >> to >> determine if the platform has reliable tscs. >> > > Well, as I said, that code is inoperative at present. But aside from that, If you read this thread completely and the patch that is being discussed, you'd find that code would be operative. Here's a threaded view of the complete discussion as we discuss for everyone's convenience, as people seem to be jumping into the discussion without actually reading up the context of the discussion. http://lkml.org/lkml/2009/2/26/5 > how well will a non-VSMP kernel work on your hardware, with a normal > cacheline, etc. Is the tsc stability really all that important, given that > the kernel should notice if the tsc is busted pretty quickly anyway. > The installer kernels do not have vSMP enabled, and needs to be atleast able to install the full distro reliably. > unsynchronized_tsc() just returns a guess anyway, and if you don't have > X86_FEATURE_CONSTANT_TSC set, then it will return unstable for your > hardware anyway, even without the is_vsmp_box() test. Unfortunately we use hardware which has X86_FEATURE_CONSTANT_TSC. > > Failing that, you could add yourself to bad_tsc_dmi_table[] and have that > mark the tsc as unstable (you have DMI, right?). > Newer versions of the VMM does, but older ones don't :(, and obviously we have older versions out in the field that still needs to be supported. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-26 0:31 ` Ravikiran G Thirumalai @ 2009-03-26 9:11 ` Ingo Molnar 2009-03-26 18:17 ` Ravikiran G Thirumalai 0 siblings, 1 reply; 24+ messages in thread From: Ingo Molnar @ 2009-03-26 9:11 UTC (permalink / raw) To: Ravikiran G Thirumalai Cc: Jeremy Fitzhardinge, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai * Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > > unsynchronized_tsc() just returns a guess anyway, and if you > > don't have X86_FEATURE_CONSTANT_TSC set, then it will return > > unstable for your hardware anyway, even without the > > is_vsmp_box() test. > > Unfortunately we use hardware which has X86_FEATURE_CONSTANT_TSC. > > > > > Failing that, you could add yourself to bad_tsc_dmi_table[] and > > have that mark the tsc as unstable (you have DMI, right?). > > > > Newer versions of the VMM does, but older ones don't :(, and > obviously we have older versions out in the field that still needs > to be supported. But those old versions wont have X86_FEATURE_CONSTANT_TSC set, right? Ingo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86: don't compile vsmp_64 for 32bit 2009-03-26 9:11 ` Ingo Molnar @ 2009-03-26 18:17 ` Ravikiran G Thirumalai 0 siblings, 0 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-26 18:17 UTC (permalink / raw) To: Ingo Molnar Cc: Jeremy Fitzhardinge, Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel@vger.kernel.org, shai On Thu, Mar 26, 2009 at 10:11:53AM +0100, Ingo Molnar wrote: > >* Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > >> > unsynchronized_tsc() just returns a guess anyway, and if you >> > don't have X86_FEATURE_CONSTANT_TSC set, then it will return >> > unstable for your hardware anyway, even without the >> > is_vsmp_box() test. >> >> Unfortunately we use hardware which has X86_FEATURE_CONSTANT_TSC. >> >> > >> > Failing that, you could add yourself to bad_tsc_dmi_table[] and >> > have that mark the tsc as unstable (you have DMI, right?). >> > >> >> Newer versions of the VMM does, but older ones don't :(, and >> obviously we have older versions out in the field that still needs >> to be supported. > >But those old versions wont have X86_FEATURE_CONSTANT_TSC set, >right? No, the old versions also do have X86_FEATURE_CONSTANT_TSC. The kernel assumes that even netburst based cpus have synced tscs (of course this is never mentioned in the intel documentation, but in the past we've been told that that intel engineers say so -- that tscs are synced and guaranteed to not drift between intel cpus) Here's the code that sets X86_FEATURE_CONSTANT_TSC. static void __cpuinit early_init_intel(struct cpuinfo_x86 *c) { if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); ... Thanks, Kiran ^ permalink raw reply [flat|nested] 24+ messages in thread
* [tip:x86/apic] Revert "x86: don't compile vsmp_64 for 32bit" 2009-03-24 6:14 ` Ravikiran G Thirumalai 2009-03-24 9:10 ` Ingo Molnar @ 2009-03-26 7:57 ` Ravikiran G Thirumalai 1 sibling, 0 replies; 24+ messages in thread From: Ravikiran G Thirumalai @ 2009-03-26 7:57 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, hpa, mingo, yinghai, kiran, akpm, tglx, mingo Commit-ID: 70511134f61bd6e5eed19f767381f9fb3e762d49 Gitweb: http://git.kernel.org/tip/70511134f61bd6e5eed19f767381f9fb3e762d49 Author: Ravikiran G Thirumalai <kiran@scalex86.org> AuthorDate: Mon, 23 Mar 2009 23:14:29 -0700 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Wed, 25 Mar 2009 21:34:28 +0100 Revert "x86: don't compile vsmp_64 for 32bit" Partial revert of commit 129d8bc828e011bda0b7110a097bf3a0167f966e titled 'x86: don't compile vsmp_64 for 32bit' Commit reverted to compile vsmp_64.c if CONFIG_X86_64 is defined, since is_vsmp_box() needs to indicate that TSCs are not synchronized, and hence, not a valid time source, even when CONFIG_X86_VSMP is not defined. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: shai@scalex86.org LKML-Reference: <20090324061429.GH7278@localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/include/asm/apic.h | 2 +- arch/x86/include/asm/setup.h | 2 +- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/vsmp_64.c | 12 +++++++++++- 4 files changed, 14 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index 130a9e2..df8a300 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -75,7 +75,7 @@ static inline void default_inquire_remote_apic(int apicid) #define setup_secondary_clock setup_secondary_APIC_clock #endif -#ifdef CONFIG_X86_VSMP +#ifdef CONFIG_X86_64 extern int is_vsmp_box(void); #else static inline int is_vsmp_box(void) diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h index fbf0521..bdc2ada 100644 --- a/arch/x86/include/asm/setup.h +++ b/arch/x86/include/asm/setup.h @@ -64,7 +64,7 @@ extern void x86_quirk_time_init(void); #include <asm/bootparam.h> /* Interrupt control for vSMPowered x86_64 systems */ -#ifdef CONFIG_X86_VSMP +#ifdef CONFIG_X86_64 void vsmp_init(void); #else static inline void vsmp_init(void) { } diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 339ce35..6e9c1f3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -70,7 +70,6 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o -obj-$(CONFIG_X86_VSMP) += vsmp_64.o obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_MODULES) += module_$(BITS).o obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o @@ -120,4 +119,5 @@ ifeq ($(CONFIG_X86_64),y) obj-$(CONFIG_AMD_IOMMU) += amd_iommu_init.o amd_iommu.o obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o + obj-y += vsmp_64.o endif diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c index 74de562..a1d804b 100644 --- a/arch/x86/kernel/vsmp_64.c +++ b/arch/x86/kernel/vsmp_64.c @@ -22,7 +22,7 @@ #include <asm/paravirt.h> #include <asm/setup.h> -#ifdef CONFIG_PARAVIRT +#if defined CONFIG_PCI && defined CONFIG_PARAVIRT /* * Interrupt control on vSMPowered systems: * ~AC is a shadow of IF. If IF is 'on' AC should be 'off' @@ -114,6 +114,7 @@ static void __init set_vsmp_pv_ops(void) } #endif +#ifdef CONFIG_PCI static int is_vsmp = -1; static void __init detect_vsmp_box(void) @@ -139,6 +140,15 @@ int is_vsmp_box(void) } } +#else +static void __init detect_vsmp_box(void) +{ +} +int is_vsmp_box(void) +{ + return 0; +} +#endif void __init vsmp_init(void) { detect_vsmp_box(); ^ permalink raw reply related [flat|nested] 24+ messages in thread
end of thread, other threads:[~2009-03-26 18:18 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-02-26 5:20 [PATCH] x86: don't compile vsmp_64 for 32bit Yinghai Lu 2009-02-26 5:40 ` Ingo Molnar 2009-02-26 6:48 ` Ravikiran G Thirumalai 2009-02-26 8:39 ` Yinghai Lu 2009-02-26 11:44 ` Ingo Molnar 2009-02-27 0:17 ` Ravikiran G Thirumalai 2009-02-28 9:44 ` Ingo Molnar 2009-03-02 23:51 ` Ravikiran G Thirumalai 2009-03-03 0:08 ` Yinghai Lu 2009-03-22 12:48 ` Ingo Molnar 2009-03-24 6:14 ` Ravikiran G Thirumalai 2009-03-24 9:10 ` Ingo Molnar 2009-03-25 18:51 ` Ravikiran G Thirumalai 2009-03-25 22:16 ` Jeremy Fitzhardinge 2009-03-25 22:36 ` Ravikiran G Thirumalai 2009-03-25 23:15 ` Jeremy Fitzhardinge 2009-03-25 23:29 ` Ravikiran G Thirumalai 2009-03-25 23:36 ` Thomas Gleixner 2009-03-26 0:11 ` Ravikiran G Thirumalai 2009-03-25 23:58 ` Jeremy Fitzhardinge 2009-03-26 0:31 ` Ravikiran G Thirumalai 2009-03-26 9:11 ` Ingo Molnar 2009-03-26 18:17 ` Ravikiran G Thirumalai 2009-03-26 7:57 ` [tip:x86/apic] Revert "x86: don't compile vsmp_64 for 32bit" Ravikiran G Thirumalai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox