Messages in this thread | | | Date | Fri, 3 Mar 2000 15:25:23 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Fri, 3 Mar 2000 yodaiken@chelm.cs.nmt.edu wrote:
> On Sun, Feb 27, 2000 at 04:04:13PM +0100, Ingo Molnar wrote: > > - per-IRQ-source spinlocks and per-IRQ-controller spinlocks > > increasing scalability: now two IRQ handlers on two CPUs > > can run do_IRQ in parallel. Note that level-triggered PCI IRQ > > handlers never actually take the IRQ-controller spinlock in the > > 'IRQ handling fast path'. > > This change puts spinlock back into the low level irq code -- and I took > them out specifically to make RTLinux work and to make Linus happy since > he was concerned about minimizing the number of spinlocks. The > "optimization" means that you can, in parallel run a tiny section of code > that is called infrequently -- [...]
it actually makes a huge difference as the _real_ optimization you missed is the lack of cacheline ping-pongs, which pingpong inevitably happens if globally shared spinlocks are used.
> [...] if there is any performance gain at all, it > comes at the expense of introducing extra spin locks, making the low > level code bigger and therefore less cache friendly, and causing an > additional check for irq status which is quite expensive on some hardware > (including x86).
you have not actually checked the fast IRQ handling path, have you? The IO-APIC level-triggered IRQ code does not use the lowlevel spinlock, at all. This was one of the goals of the optimization.
> I don't see the "fast path" in a first look at the code. Are you now > skiping "do_irq" for some interrupt handlers?
check out the fast path of level-triggered PCI IRQs:
do_IRQ() mask_and_ack_level_ioapic_irq: empty! ->handler() end_level_ioapic_irq: a fast local-APIC write
no lowlevel spinlock taken. This is actually the case where the IOAPIC IRQ hardware turned out to be very sane. The borken edge-triggered case is nicely isolated.
-- mingo
- 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/
| |