lkml.org 
[lkml]   [2000]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:2.438 / U:0.556 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site