Messages in this thread | | | Date | Thu, 9 Mar 2000 03:32:55 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |