I didn't get a response to my other patch to do this so i'm guessing that
people want a simpler patch(??) This one simply sets TARGET_CPUS to
cpu_callout_map instead of cpu_online_map so that when we finally do boot
we actually use the other cpus for servicing interrupts.
Only tested on 2way AMD/SMP booted with noirqbalance, interrupts get
distributed via apic bus arbitration.
Zwane
Index: linux-2.5.62-numaq//include/asm-i386/mach-bigsmp/mach_apic.h
===================================================================
RCS file: /build/cvsroot/linux-2.5.62/include/asm-i386/mach-bigsmp/mach_apic.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mach_apic.h
--- linux-2.5.62-numaq//include/asm-i386/mach-bigsmp/mach_apic.h 18 Feb 2003 00:16:00 -0000 1.1.1.1
+++ linux-2.5.62-numaq//include/asm-i386/mach-bigsmp/mach_apic.h 7 Mar 2003 05:34:49 -0000
@@ -19,7 +19,7 @@
}
#define APIC_DFR_VALUE (APIC_DFR_CLUSTER)
-#define TARGET_CPUS ((cpu_online_map < 0xf)?cpu_online_map:0xf)
+#define TARGET_CPUS ((cpu_callout_map < 0xf)?cpu_callout_map:0xf)
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
Index: linux-2.5.62-numaq//include/asm-i386/mach-default/mach_apic.h
===================================================================
RCS file: /build/cvsroot/linux-2.5.62/include/asm-i386/mach-default/mach_apic.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mach_apic.h
--- linux-2.5.62-numaq//include/asm-i386/mach-default/mach_apic.h 18 Feb 2003 00:15:59 -0000 1.1.1.1
+++ linux-2.5.62-numaq//include/asm-i386/mach-default/mach_apic.h 7 Mar 2003 05:33:20 -0000
@@ -4,7 +4,7 @@
#define APIC_DFR_VALUE (APIC_DFR_FLAT)
#ifdef CONFIG_SMP
- #define TARGET_CPUS (cpu_online_map)
+ #define TARGET_CPUS (cpu_callout_map)
#else
#define TARGET_CPUS 0x01
#endif
Index: linux-2.5.62-numaq//include/asm-i386/mach-summit/mach_apic.h
===================================================================
RCS file: /build/cvsroot/linux-2.5.62/include/asm-i386/mach-summit/mach_apic.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mach_apic.h
--- linux-2.5.62-numaq//include/asm-i386/mach-summit/mach_apic.h 18 Feb 2003 00:15:59 -0000 1.1.1.1
+++ linux-2.5.62-numaq//include/asm-i386/mach-summit/mach_apic.h 7 Mar 2003 05:36:40 -0000
@@ -13,7 +13,7 @@
((phys_apic) & XAPIC_DEST_CLUSTER_MASK) )
#define APIC_DFR_VALUE (x86_summit ? APIC_DFR_CLUSTER : APIC_DFR_FLAT)
-#define TARGET_CPUS (x86_summit ? XAPIC_DEST_CPUS_MASK : cpu_online_map)
+#define TARGET_CPUS (x86_summit ? XAPIC_DEST_CPUS_MASK : cpu_callout_map)
#define INT_DELIVERY_MODE (x86_summit ? dest_Fixed : dest_LowestPrio)
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
--
function.linuxpower.ca
> I didn't get a response to my other patch to do this so i'm guessing that
> people want a simpler patch(??) This one simply sets TARGET_CPUS to
> cpu_callout_map instead of cpu_online_map so that when we finally do boot
> we actually use the other cpus for servicing interrupts.
Actually, I think your first patch is correct. TARGET_CPUS seems like the
wrong thing to be changing (for example, if we take a CPU offline later)
However, doesn't this:
> +/*
> + * This function currently is only a helper for the i386 smp boot process where
> + * we need to reprogram the ioredtbls to cater for the cpus which have come online
> + * so mask in all cases should simply be TARGET_CPUS
> + */
> +void __devinit set_ioapic_logical_dest (unsigned long mask)
> +{
> + struct IO_APIC_route_entry entry;
> + unsigned long flags;
> + int apic, pin;
> +
> + spin_lock_irqsave(&ioapic_lock, flags);
> + for (apic = 0; apic < nr_ioapics; apic++) {
> + for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
> + *(((int *)&entry)+0) = io_apic_read(apic, 0x10+pin*2);
> + *(((int *)&entry)+1) = io_apic_read(apic, 0x11+pin*2);
> + entry.dest.logical.logical_dest = mask;
> + io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry) + 0));
> + io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry) + 1));
> + }
> +
> + }
> + spin_unlock_irqrestore(&ioapic_lock, flags);
> +}
do more or less the same as set_ioapic_affinity? And even if not, don't
you have to do "mask << 24" instead of "mask" ... or am I just confused?
M.
On Fri, 7 Mar 2003, Martin J. Bligh wrote:
> Actually, I think your first patch is correct. TARGET_CPUS seems like the
> wrong thing to be changing (for example, if we take a CPU offline later)
> However, doesn't this:
Not to mention if we take an interrupt (say pit doing timer ints) and it
gets sent to one of the still yet to boot cpus? (Although we're so close
to bringing them up it really doesn't matter).
> > +/*
> > + * This function currently is only a helper for the i386 smp boot process where
> > + * we need to reprogram the ioredtbls to cater for the cpus which have come online
> > + * so mask in all cases should simply be TARGET_CPUS
> > + */
> > +void __devinit set_ioapic_logical_dest (unsigned long mask)
> > +{
> > + struct IO_APIC_route_entry entry;
> > + unsigned long flags;
> > + int apic, pin;
> > +
> > + spin_lock_irqsave(&ioapic_lock, flags);
> > + for (apic = 0; apic < nr_ioapics; apic++) {
> > + for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
> > + *(((int *)&entry)+0) = io_apic_read(apic, 0x10+pin*2);
> > + *(((int *)&entry)+1) = io_apic_read(apic, 0x11+pin*2);
> > + entry.dest.logical.logical_dest = mask;
> > + io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry) + 0));
> > + io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry) + 1));
> > + }
> > +
> > + }
> > + spin_unlock_irqrestore(&ioapic_lock, flags);
> > +}
>
> do more or less the same as set_ioapic_affinity? And even if not, don't
> you have to do "mask << 24" instead of "mask" ... or am I just confused?
union { struct { __u32
__reserved_1 : 24,
physical_dest : 4,
__reserved_2 : 4;
} physical;
struct { __u32
__reserved_1 : 24,
logical_dest : 8;
} logical;
} dest;
Yes. But here we're lucky here because IO_APIC_route_entry is a nicely
setup struct, all we need to do is put in the mask, for SMP boxes
with over 8 cpus we'd stuff 0xf with all the magic being in TARGET_CPUS
for each sub architecture.
Thanks,
Zwane
--
function.linuxpower.ca