RE: [PATCH][2.4] generic support for systems with more than 8 CP Us (2/2)

["Martin J. Bligh" <mbligh@aracnet.com>]

>> IIRC NUMA-Q can be dynamically detected at boot by means of an MP OEM
>> table's presence, in particular if there's a matching string in the 8B
>> OEM record in the OEM table, with a value of "IBM NUMA" IIRC. This is
>> probably a line or two's worth of change to mpparse.c and declaring a
>> variable for clustered_apic_mode. If it were difficult to detect, I
>> wouldn't have suggested implementing it (though do so at your leisure).
>> =)

I don't think you need the OEM table to detect this, current patches do:

+static inline void mps_oem_check(struct mp_config_table *mpc, char *oem,
+               char *productid)
+{
+       if (strncmp(oem, "IBM NUMA", 8))
+               printk("Warning!  May not be a NUMA-Q system!\n");
+       if (mpc->mpc_oemptr)
+               smp_read_mpc_oem((struct mp_config_oemtable *) 
mpc->mpc_oemptr,
+                               mpc->mpc_oemsize);
+}


 @@ -376,7 +368,7 @@ static int __init smp_read_mpc(struct mp
        str[12]=0;
        printk("Product ID: %s ",str);

-       summit_check(oem, str);
+       mps_oem_check(mpc, oem, str);

        printk("APIC at: 0x%lX\n",mpc->mpc_lapic);

> The format for the OEM table is pretty much freelance. ES7000 uses it in
> the most informal way. However, we need information from this table to
> switch to APIC mode, start CPUs, etc. To have the hook for OEM tables in
> MP parsing (and in ACPI, for that matter) seems pretty natural. Or if
> reading of the OEM table could also be done in more generic way so other
> platforms had chance to read their tables seamlessly...

Support for parsing the mps oem tables is already there - I use it for
NUMA-Q ... see if smp_read_mpc_oem will do what you want ... if not,
maybe we can generalise it out.

> Also, could the clustered_logical and clustered_physical modes be
> implemented as a primary item, with NUMA being a secondary with the set of
> its unique features on top of the certain APIC mode? This way, a clustered
> mode for the APIC could be selectable without NUMA. CLUSTERED_APIC_NUMAQ
> could be still an option with an appropriate clustered mode defined.

Yup - it was only set up that way because we had a 1-1 correlation between
NUMA and clustered_apic_mode at the time. Switching the ordering as you
suggest seems sensible now.

In the last patch from Venkatesh there was a > 8CPUs option ... that
seems like a direct correlation to clustered apic support to me ...
maybe we could just switch on CONFIG_X86_CLUSTERED_APIC directly and
bypass CONFIG_X86_MANY_CPU? The menu text could stay the same (less
confusing for users than asking them about apic modes) ...

M.