[PATCH][RFT] noirqbalance still doesn't do anything

[PATCH][RFT] noirqbalance still doesn't do anything

[Zwane Mwaikambo]

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

Re: [PATCH][RFT] noirqbalance still doesn't do anything

[Martin J. Bligh]

> 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.

Re: [PATCH][RFT] noirqbalance still doesn't do anything

[Zwane Mwaikambo]

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