On Wed, 8 Mar 2000 yodaiken@fsmlabs.com wrote:
>On a UP -- no change except code is more complex
>On a SMP box performance loss without using affinity.
> Take two spinlocks instead of one, more cache boucing etc.
>One a SMP box using affinit no gain over just using affinity
> except whn we assign edge interrupts for one cpu and level to
> a second and even then it is hard to imagine that it does anything
> good. I think you are optimizing for a coner case of an 8 way box at
> the expense of everything else.
The scaling is conceptually correct. There's no point to disallow an i8259
irq to happen and to mask itself on CPU0 while an IO-APIC irq is masking
itself in CPU1. They are completly orthogonal irqs.
If there's only one irq controller in the machine there's no gain and
there's one more spinlock indeed.
BTW, affinity is not relevant to the scaling in IA32 where the CPU
selection is done in hardware.
On alpha there are several types of IRQ each caming from a different
source. So now the rtc irq can run irq_desc critical section in one CPU
while another i8259-irq is masking itself in another CPU and while another
dp264-pci-irq is masking itself in yet another CPU.
So I at least conceptually like the change since the irq.c code has to be
generic.
>The second problem is this idea of blocking _all_ interrupts on an IOAPIC
>during the execution of a level interrupt handler. This seems like a definite
>performance loss on a dual SMP where one processor would otherwise be able
>to take and service an irq while the other handleed a different irq.
I didn't checked the IO-APIC changes, but if that's true that's certainly
not intentional and it has to be fixed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:15 EST