lkml.org 
[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Apache performance: Run queue proportional to number of connections?

    Various people wrote:
    > > > Why you raise the finger against interrupts? Is the problem the irq
    > > > lantency? It's true that we call irq handlers through two function
    > > > pointers, we could remove such function pointers but I am not convinced
    > > > that that's the problem. I think also NT may have something similar to
    > > > allow the code to be object oriented and cleaner.
    > >
    > > the problem was the single lock for being in the tcp paths. we'd have N
    > > apaches running on the cpus trying to transmit the data they just figured
    > > out the client wants, and N interrupts arriving at the same time trying to
    > > pass more data in to the waiting apaches. sync_bh was WAY at the top of
    > > the profiling runs.

    I made a number of minor performance changes back in the 2.0.xx days
    that may still be applicable:

    1) Eliminate the dummy inb instruction when acking interrupts to the
    8259. The comments indicate that these are present to deal with
    some old disk controller problem, and probably a flaky 8259!

    2) Change the ethernet drivers to be more parsimonious in their use
    of i/o instructions in their interrupt routines. There are two
    changes here -- one is not to acknowledge interrupts if there
    are none to be acknowledged. The second is not to check for more
    working arriving while processing the first chunk of work.
    [This second change should be adaptive.]

    The deal is that i/o instructions are *incredibly* expensive on
    modern fast processors. A simple inb takes between 500 and 1500 ns
    depending on the device (on a 350Mhz PII). My suspicion is that this
    is bus limited, so it will be no fast on a 550 PIII. This means that
    it is worth spending significant code to avoid I/O (hundreds of
    normal instructions).

    Why do I bring it up? Essentially these changes can eliminate 3
    i/o instructions per interrupt, at around 2 usecs per interrupt.
    Will this help -- I don't know, it depends on the actual interrupt
    rates in the benchmark above.

    For those of you skeptics who doubt me, I attach a simple test
    program that does a bunch of inb/inw/inl to the port of your
    choice, and prints out the speeds. Make sure that you compile
    it with -O2, otherwise you get link errors.

    Philip
    --
    Philip Gladstone +1 781 530 2461
    Axent Technologies, Waltham, MA[unhandled content-type:application/x-unknown-content-type-cfile][unhandled content-type:application/x-pkcs7-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.020 / U:59.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site