[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 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.033 / U:57.088 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site