UV is fairly rare.... and much of the support is already there to cope with
32-bit builds. So this makes sense I think.
--
Make X86 SGI Ultraviolet support configurable. Saves about 13K of text size
on my modest config.
text data bss dec hex filename
6770537 1158680 694356 8623573 8395d5 vmlinux
6757492 1157664 694228 8609384 835e68 vmlinux.nouv
Signed-off-by: Nick Piggin <[email protected]>
---
arch/x86/Kconfig | 7 +++++++
arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
arch/x86/include/asm/genapic_32.h | 7 -------
arch/x86/include/asm/genapic_64.h | 9 ---------
arch/x86/kernel/Makefile | 5 +++--
arch/x86/kernel/entry_64.S | 2 ++
arch/x86/kernel/genapic_64.c | 3 ++-
arch/x86/kernel/io_apic.c | 2 +-
8 files changed, 39 insertions(+), 20 deletions(-)
Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -390,6 +390,13 @@ config X86_RDC321X
as R-8610-(G).
If you don't have one of these chips, you should say N here.
+config X86_UV
+ bool "SGI Ultraviolet"
+ depends on X86_64
+ help
+ This option is needed in order to support SGI Ultraviolet systems.
+ If you don't have one of these, you should say N here.
+
config SCHED_OMIT_FRAME_POINTER
def_bool y
prompt "Single-depth WCHAN output"
Index: linux-2.6/arch/x86/include/asm/genapic.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/genapic.h
+++ linux-2.6/arch/x86/include/asm/genapic.h
@@ -1,5 +1,29 @@
+#ifndef _ASM_X86_GENAPIC_H
+#define _ASM_X86_GENAPIC_H
+
#ifdef CONFIG_X86_32
# include "genapic_32.h"
#else
# include "genapic_64.h"
#endif
+
+#ifdef CONFIG_X86_UV
+DECLARE_PER_CPU(int, x2apic_extra_bits);
+enum uv_system_type {UV_NONE, UV_LEGACY_APIC, UV_X2APIC, UV_NON_UNIQUE_APIC};
+extern enum uv_system_type get_uv_system_type(void);
+extern int is_uv_system(void);
+
+extern struct genapic apic_x2apic_uv_x;
+extern void uv_cpu_init(void);
+extern void uv_system_init(void);
+extern int uv_wakeup_secondary(int phys_apicid, unsigned int start_rip);
+#else
+enum uv_system_type {UV_NONE, UV_LEGACY_APIC, UV_X2APIC, UV_NON_UNIQUE_APIC};
+#define get_uv_system_type() UV_NONE
+#define is_uv_system() 0
+#define uv_wakeup_secondary(a, b) 1
+#define uv_system_init() do {} while (0)
+#define uv_cpu_init() do {} while (0)
+#endif
+
+#endif
Index: linux-2.6/arch/x86/include/asm/genapic_32.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/genapic_32.h
+++ linux-2.6/arch/x86/include/asm/genapic_32.h
@@ -138,11 +138,4 @@ struct genapic {
extern struct genapic *genapic;
extern void es7000_update_genapic_to_cluster(void);
-enum uv_system_type {UV_NONE, UV_LEGACY_APIC, UV_X2APIC, UV_NON_UNIQUE_APIC};
-#define get_uv_system_type() UV_NONE
-#define is_uv_system() 0
-#define uv_wakeup_secondary(a, b) 1
-#define uv_system_init() do {} while (0)
-
-
#endif /* _ASM_X86_GENAPIC_32_H */
Index: linux-2.6/arch/x86/include/asm/genapic_64.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/genapic_64.h
+++ linux-2.6/arch/x86/include/asm/genapic_64.h
@@ -51,15 +51,6 @@ extern struct genapic apic_x2apic_phys;
extern int acpi_madt_oem_check(char *, char *);
extern void apic_send_IPI_self(int vector);
-enum uv_system_type {UV_NONE, UV_LEGACY_APIC, UV_X2APIC, UV_NON_UNIQUE_APIC};
-extern enum uv_system_type get_uv_system_type(void);
-extern int is_uv_system(void);
-
-extern struct genapic apic_x2apic_uv_x;
-DECLARE_PER_CPU(int, x2apic_extra_bits);
-extern void uv_cpu_init(void);
-extern void uv_system_init(void);
-extern int uv_wakeup_secondary(int phys_apicid, unsigned int start_rip);
extern void setup_apic_routing(void);
Index: linux-2.6/arch/x86/kernel/Makefile
===================================================================
--- linux-2.6.orig/arch/x86/kernel/Makefile
+++ linux-2.6/arch/x86/kernel/Makefile
@@ -114,10 +114,11 @@ obj-$(CONFIG_SWIOTLB) += pci-swiotlb_6
###
# 64 bit specific files
ifeq ($(CONFIG_X86_64),y)
- obj-y += genapic_64.o genapic_flat_64.o genx2apic_uv_x.o tlb_uv.o
- obj-y += bios_uv.o uv_irq.o uv_sysfs.o
+ obj-y += genapic_64.o genapic_flat_64.o
obj-y += genx2apic_cluster.o
obj-y += genx2apic_phys.o
+ obj-$(CONFIG_X86_UV) += genx2apic_uv_x.o tlb_uv.o
+ obj-$(CONFIG_X86_UV) += bios_uv.o uv_irq.o uv_sysfs.o
obj-$(CONFIG_X86_PM_TIMER) += pmtimer_64.o
obj-$(CONFIG_AUDIT) += audit_64.o
Index: linux-2.6/arch/x86/kernel/entry_64.S
===================================================================
--- linux-2.6.orig/arch/x86/kernel/entry_64.S
+++ linux-2.6/arch/x86/kernel/entry_64.S
@@ -981,8 +981,10 @@ apicinterrupt IRQ_MOVE_CLEANUP_VECTOR \
irq_move_cleanup_interrupt smp_irq_move_cleanup_interrupt
#endif
+#ifdef CONFIG_X86_UV
apicinterrupt UV_BAU_MESSAGE \
uv_bau_message_intr1 uv_bau_message_interrupt
+#endif
apicinterrupt LOCAL_TIMER_VECTOR \
apic_timer_interrupt smp_apic_timer_interrupt
Index: linux-2.6/arch/x86/kernel/genapic_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/genapic_64.c
+++ linux-2.6/arch/x86/kernel/genapic_64.c
@@ -25,14 +25,15 @@
extern struct genapic apic_flat;
extern struct genapic apic_physflat;
-extern struct genapic apic_x2xpic_uv_x;
extern struct genapic apic_x2apic_phys;
extern struct genapic apic_x2apic_cluster;
struct genapic __read_mostly *genapic = &apic_flat;
static struct genapic *apic_probe[] __initdata = {
+#ifdef CONFIG_X86_UV
&apic_x2apic_uv_x,
+#endif
&apic_x2apic_phys,
&apic_x2apic_cluster,
&apic_physflat,
Index: linux-2.6/arch/x86/kernel/io_apic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/io_apic.c
+++ linux-2.6/arch/x86/kernel/io_apic.c
@@ -3762,7 +3762,7 @@ int arch_setup_ht_irq(unsigned int irq,
}
#endif /* CONFIG_HT_IRQ */
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_X86_UV
/*
* Re-target the irq to the specified CPU and enable the specified MMR located
* on the specified blade to allow the sending of MSIs to the specified CPU.
On Mon, Jan 5, 2009 at 10:03 PM, Nick Piggin <[email protected]> wrote:
> UV is fairly rare.... and much of the support is already there to cope with
> 32-bit builds. So this makes sense I think.
>
> --
> Make X86 SGI Ultraviolet support configurable. Saves about 13K of text size
> on my modest config.
>
> text data bss dec hex filename
> 6770537 1158680 694356 8623573 8395d5 vmlinux
> 6757492 1157664 694228 8609384 835e68 vmlinux.nouv
>
> Signed-off-by: Nick Piggin <[email protected]>
> ---
> arch/x86/Kconfig | 7 +++++++
> arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
> arch/x86/include/asm/genapic_32.h | 7 -------
> arch/x86/include/asm/genapic_64.h | 9 ---------
> arch/x86/kernel/Makefile | 5 +++--
> arch/x86/kernel/entry_64.S | 2 ++
> arch/x86/kernel/genapic_64.c | 3 ++-
> arch/x86/kernel/io_apic.c | 2 +-
> 8 files changed, 39 insertions(+), 20 deletions(-)
how about
kernel/efi.c: efi.uv_systab = config_tables[i].table;
?
YH
On Mon, Jan 05, 2009 at 10:38:17PM -0800, Yinghai Lu wrote:
> On Mon, Jan 5, 2009 at 10:03 PM, Nick Piggin <[email protected]> wrote:
> > UV is fairly rare.... and much of the support is already there to cope with
> > 32-bit builds. So this makes sense I think.
> >
> > --
> > Make X86 SGI Ultraviolet support configurable. Saves about 13K of text size
> > on my modest config.
> >
> > text data bss dec hex filename
> > 6770537 1158680 694356 8623573 8395d5 vmlinux
> > 6757492 1157664 694228 8609384 835e68 vmlinux.nouv
> >
> > Signed-off-by: Nick Piggin <[email protected]>
> > ---
> > arch/x86/Kconfig | 7 +++++++
> > arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
> > arch/x86/include/asm/genapic_32.h | 7 -------
> > arch/x86/include/asm/genapic_64.h | 9 ---------
> > arch/x86/kernel/Makefile | 5 +++--
> > arch/x86/kernel/entry_64.S | 2 ++
> > arch/x86/kernel/genapic_64.c | 3 ++-
> > arch/x86/kernel/io_apic.c | 2 +-
> > 8 files changed, 39 insertions(+), 20 deletions(-)
>
> how about
> kernel/efi.c: efi.uv_systab = config_tables[i].table;
> ?
Good point, I missed that. Will resend a patch with that ifdef'ed tomorrow
unless any serious objections are raised.
* Nick Piggin <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 10:38:17PM -0800, Yinghai Lu wrote:
> > On Mon, Jan 5, 2009 at 10:03 PM, Nick Piggin <[email protected]> wrote:
> > > UV is fairly rare.... and much of the support is already there to cope with
> > > 32-bit builds. So this makes sense I think.
> > >
> > > --
> > > Make X86 SGI Ultraviolet support configurable. Saves about 13K of text size
> > > on my modest config.
> > >
> > > text data bss dec hex filename
> > > 6770537 1158680 694356 8623573 8395d5 vmlinux
> > > 6757492 1157664 694228 8609384 835e68 vmlinux.nouv
> > >
> > > Signed-off-by: Nick Piggin <[email protected]>
> > > ---
> > > arch/x86/Kconfig | 7 +++++++
> > > arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
> > > arch/x86/include/asm/genapic_32.h | 7 -------
> > > arch/x86/include/asm/genapic_64.h | 9 ---------
> > > arch/x86/kernel/Makefile | 5 +++--
> > > arch/x86/kernel/entry_64.S | 2 ++
> > > arch/x86/kernel/genapic_64.c | 3 ++-
> > > arch/x86/kernel/io_apic.c | 2 +-
> > > 8 files changed, 39 insertions(+), 20 deletions(-)
> >
> > how about
> > kernel/efi.c: efi.uv_systab = config_tables[i].table;
> > ?
>
> Good point, I missed that. Will resend a patch with that ifdef'ed
> tomorrow unless any serious objections are raised.
Looks good to me, but please also extend the Makefile changes to
kernel/tlb_uv.c, ./kernel/uv_sysfs.c, kernel/uv_irq.c, kernel/bios_uv.c -
UV not just the genapic bits. Perhaps do it via gradual patches.
Ingo
On Tuesday 06 January 2009 20:01:38 Ingo Molnar wrote:
> > > > ---
> > > > arch/x86/Kconfig | 7 +++++++
> > > > arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
> > > > arch/x86/include/asm/genapic_32.h | 7 -------
> > > > arch/x86/include/asm/genapic_64.h | 9 ---------
> > > > arch/x86/kernel/Makefile | 5 +++--
> > > > arch/x86/kernel/entry_64.S | 2 ++
> > > > arch/x86/kernel/genapic_64.c | 3 ++-
> > > > arch/x86/kernel/io_apic.c | 2 +-
> > > > 8 files changed, 39 insertions(+), 20 deletions(-)
> > >
> > > how about
> > > kernel/efi.c: efi.uv_systab = config_tables[i].table;
> > > ?
> >
> > Good point, I missed that. Will resend a patch with that ifdef'ed
> > tomorrow unless any serious objections are raised.
>
> Looks good to me, but please also extend the Makefile changes to
> kernel/tlb_uv.c, ./kernel/uv_sysfs.c, kernel/uv_irq.c, kernel/bios_uv.c -
> UV not just the genapic bits. Perhaps do it via gradual patches.
Hmm, I think the Makefile changes should be there... the files
you reference AFAIKS are put under conditional compilation with
my patch?
* Nick Piggin <[email protected]> wrote:
> On Tuesday 06 January 2009 20:01:38 Ingo Molnar wrote:
>
> > > > > ---
> > > > > arch/x86/Kconfig | 7 +++++++
> > > > > arch/x86/include/asm/genapic.h | 24 ++++++++++++++++++++++++
> > > > > arch/x86/include/asm/genapic_32.h | 7 -------
> > > > > arch/x86/include/asm/genapic_64.h | 9 ---------
> > > > > arch/x86/kernel/Makefile | 5 +++--
> > > > > arch/x86/kernel/entry_64.S | 2 ++
> > > > > arch/x86/kernel/genapic_64.c | 3 ++-
> > > > > arch/x86/kernel/io_apic.c | 2 +-
> > > > > 8 files changed, 39 insertions(+), 20 deletions(-)
> > > >
> > > > how about
> > > > kernel/efi.c: efi.uv_systab = config_tables[i].table;
> > > > ?
> > >
> > > Good point, I missed that. Will resend a patch with that ifdef'ed
> > > tomorrow unless any serious objections are raised.
> >
> > Looks good to me, but please also extend the Makefile changes to
> > kernel/tlb_uv.c, ./kernel/uv_sysfs.c, kernel/uv_irq.c, kernel/bios_uv.c -
> > UV not just the genapic bits. Perhaps do it via gradual patches.
>
> Hmm, I think the Makefile changes should be there... the files you
> reference AFAIKS are put under conditional compilation with my patch?
ah, indeed - i was looking at the diffstat and went "where's the
mm/Makefile changes" ;-) So your patch is good as-is, as long as the thing
Yinghai noticed is fixed.
Ingo
On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
> UV is fairly rare.... and much of the support is already there to cope with
> 32-bit builds. So this makes sense I think.
>
Looks ok to me. One suggestion though. There is a MAXSMP config
option. I would suggest enabling UV if MAXSMP is enabled. This
will help ensure that UV is tested more frequently & may minimize
regressions.
--- jack
On Tue, Jan 06, 2009 at 08:33:30AM -0600, Jack Steiner wrote:
> On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
> > UV is fairly rare.... and much of the support is already there to cope with
> > 32-bit builds. So this makes sense I think.
> >
>
>
> Looks ok to me. One suggestion though. There is a MAXSMP config
> option. I would suggest enabling UV if MAXSMP is enabled. This
> will help ensure that UV is tested more frequently & may minimize
> regressions.
Yeah.... I don't know. OTOH it would be more logical to enable
MAXSMP iff UV is enabled (or change the MAXSMP limits for when
UV is enabled). Or you could select Intel CPUs if UV is enabled,
or disable GRU if UV is not set etc etc.
I didn't want to get too fancy with config options because arbitrary
linkages seem to just cause headaches. I figure if someone wants
to enable it, they can do so.
Jack Steiner wrote:
> On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
>> UV is fairly rare.... and much of the support is already there to cope with
>> 32-bit builds. So this makes sense I think.
>>
>
>
> Looks ok to me. One suggestion though. There is a MAXSMP config
> option. I would suggest enabling UV if MAXSMP is enabled. This
> will help ensure that UV is tested more frequently & may minimize
> regressions.
>
>
> --- jack
Nick - would you add something like this to your patch? Thanks! Mike
---
Subject: x86: enable UV when MAXSMP is configured.
We want UV code to be tested even for non-UV architectures. Enabling
MAXSMP specifies "maximizing the system capabitlity" and UV is one of
these methods. Also helps distros select the correct config options
for their default configurations.
Signed-off-by: Mike Travis <[email protected]>
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-2.6-for-ingo.orig/arch/x86/Kconfig
+++ linux-2.6-for-ingo/arch/x86/Kconfig
@@ -616,6 +616,7 @@ config MAXSMP
bool "Configure Maximum number of SMP Processors and NUMA Nodes"
depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
select CPUMASK_OFFSTACK
+ select X86_UV
default n
help
Configure maximum number of CPUS and NUMA Nodes for this architecture.
On Tue, Jan 06, 2009 at 06:54:08AM -0800, Mike Travis wrote:
> Jack Steiner wrote:
> > On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
> >> UV is fairly rare.... and much of the support is already there to cope with
> >> 32-bit builds. So this makes sense I think.
> >>
> >
> >
> > Looks ok to me. One suggestion though. There is a MAXSMP config
> > option. I would suggest enabling UV if MAXSMP is enabled. This
> > will help ensure that UV is tested more frequently & may minimize
> > regressions.
> >
> >
> > --- jack
>
> Nick - would you add something like this to your patch? Thanks! Mike
> ---
> Subject: x86: enable UV when MAXSMP is configured.
>
> We want UV code to be tested even for non-UV architectures. Enabling
> MAXSMP specifies "maximizing the system capabitlity" and UV is one of
> these methods. Also helps distros select the correct config options
> for their default configurations.
I don't really follow. The config option I added is very visible and
clear, isn't it? I don't think MAXSMP means that, otherwise it would
basically be allyesconfig.
I wouldn't object to have a platform types menu like the processor
types one. Or a generic architecture checkbox to select some of
these things together.
Nick Piggin wrote:
> On Tue, Jan 06, 2009 at 08:33:30AM -0600, Jack Steiner wrote:
>> On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
>>> UV is fairly rare.... and much of the support is already there to cope with
>>> 32-bit builds. So this makes sense I think.
What, you haven't heard of "UV on a chip"? It will be in every
smart phone soon... ;-)
>>>
>>
>> Looks ok to me. One suggestion though. There is a MAXSMP config
>> option. I would suggest enabling UV if MAXSMP is enabled. This
>> will help ensure that UV is tested more frequently & may minimize
>> regressions.
>
> Yeah.... I don't know. OTOH it would be more logical to enable
> MAXSMP iff UV is enabled (or change the MAXSMP limits for when
> UV is enabled). Or you could select Intel CPUs if UV is enabled,
> or disable GRU if UV is not set etc etc.
>
> I didn't want to get too fancy with config options because arbitrary
> linkages seem to just cause headaches. I figure if someone wants
> to enable it, they can do so.
>
Hi Nick,
The problem arises that if the option becomes too obscure (and never
enabled), then it won't get tested. We (as many companies do) rely on
distros to certify applications and security features using a standard
kernel, and if an option (such as X86_UV) causes any problems whatsoever,
they'll drop it and we no longer have that application certification.
Currently, Ingo's test setup sets MAXSMP quite a bit and he's found
many problems with large NR_CPUS counts that we never would have found
ourselves. Please don't make that process any harder.
In fact, 13k is peanuts. Why don't you set something like "very minimal
support" and drop all obsolete features, anything older than a couple of
years, anything not available from Dell ;-) Perhaps call it "Desktop
System"?
Thanks,
Mike
* Mike Travis <[email protected]> wrote:
> @@ -616,6 +616,7 @@ config MAXSMP
> bool "Configure Maximum number of SMP Processors and NUMA Nodes"
> depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
> select CPUMASK_OFFSTACK
> + select X86_UV
> default n
> help
why not add this to X86_UV:
default MAXSMP
this way it still stays fully configurable, but it is default-enabled if
someone strives for a big SMP kernel.
Ingo
On Tue, Jan 06, 2009 at 07:05:42AM -0800, Mike Travis wrote:
> Nick Piggin wrote:
> > On Tue, Jan 06, 2009 at 08:33:30AM -0600, Jack Steiner wrote:
> >> On Tue, Jan 06, 2009 at 07:03:48AM +0100, Nick Piggin wrote:
> >>> UV is fairly rare.... and much of the support is already there to cope with
> >>> 32-bit builds. So this makes sense I think.
>
> What, you haven't heard of "UV on a chip"? It will be in every
> smart phone soon... ;-)
NUMAlink over microwave? Cool!
> >> Looks ok to me. One suggestion though. There is a MAXSMP config
> >> option. I would suggest enabling UV if MAXSMP is enabled. This
> >> will help ensure that UV is tested more frequently & may minimize
> >> regressions.
> >
> > Yeah.... I don't know. OTOH it would be more logical to enable
> > MAXSMP iff UV is enabled (or change the MAXSMP limits for when
> > UV is enabled). Or you could select Intel CPUs if UV is enabled,
> > or disable GRU if UV is not set etc etc.
> >
> > I didn't want to get too fancy with config options because arbitrary
> > linkages seem to just cause headaches. I figure if someone wants
> > to enable it, they can do so.
> >
>
> Hi Nick,
>
> The problem arises that if the option becomes too obscure (and never
> enabled), then it won't get tested. We (as many companies do) rely on
> distros to certify applications and security features using a standard
> kernel, and if an option (such as X86_UV) causes any problems whatsoever,
> they'll drop it and we no longer have that application certification.
I wouldn't be so pessimistic ;) The people involved should have a
shared interest in the feature so then they will fix it.
It might be nice for one person to enable their code on everyone's
builds, but it's kind of a selfish viewpoint (imagine if everyone
did it).
> Currently, Ingo's test setup sets MAXSMP quite a bit and he's found
> many problems with large NR_CPUS counts that we never would have found
> ourselves. Please don't make that process any harder.
Ingo's setup does randconfigs I think? Then it should pick up this
option.
> In fact, 13k is peanuts.
Ahh, you SGIers ;) Everything adds up, and 13k is a gold mine
for some people, especially considering how unintrusive the patch
is.
> Why don't you set something like "very minimal
> support" and drop all obsolete features, anything older than a couple of
> years, anything not available from Dell ;-) Perhaps call it "Desktop
> System"?
Well, because I don't perceive any benefit from doing that :)
In the end I don't want to make a big deal of it so long as it is
configurable. I'll resubmit the patch, and let others play with
Kconfig...
Ingo Molnar wrote:
> * Mike Travis <[email protected]> wrote:
>
>> @@ -616,6 +616,7 @@ config MAXSMP
>> bool "Configure Maximum number of SMP Processors and NUMA Nodes"
>> depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
>> select CPUMASK_OFFSTACK
>> + select X86_UV
>> default n
>> help
>
> why not add this to X86_UV:
>
> default MAXSMP
>
> this way it still stays fully configurable, but it is default-enabled if
> someone strives for a big SMP kernel.
>
> Ingo
Yes, that does sounds better, thanks!
Mike
Hi!
> The problem arises that if the option becomes too obscure (and never
> enabled), then it won't get tested. We (as many companies do) rely on
> distros to certify applications and security features using a standard
> kernel, and if an option (such as X86_UV) causes any problems whatsoever,
> they'll drop it and we no longer have that application certification.
If SGI UV is really important, I'm sure you can ask distros to keep it
enabled.
> Currently, Ingo's test setup sets MAXSMP quite a bit and he's found
> many problems with large NR_CPUS counts that we never would have found
> ourselves. Please don't make that process any harder.
Yeah, and remove config_386 too. Just hardcode it to y.
No, sorry, I don't see why we should treat UV specially.
> In fact, 13k is peanuts. Why don't you set something like "very minimal
13K is quite a lot, actually.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html