If you are looking at network performance ...
A while back I briefly looked at this and it
looked like the per packet processing time had
gone up significantly between 2.4.20 and
2.6.x. Problem was not NAPI which switches
from interrupt to polling mode when you get a burst
of packets. I actually traced a single packet from Rx
to Tx. Unfortunately I didn't save my data and did
not isolate where increased time was being spent.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of Ralf Baechle
> Sent: Wednesday, October 19, 2005 8:54 AM
> To: kernel coder
> Cc: email@example.com
> Subject: Re: Fwd: How to improve performance of 2.6 kernel
> On Wed, Oct 19, 2005 at 10:55:01AM +0500, kernel coder wrote:
> > I did lmbench benchmarks tests... and the results i got were pretty
> > weird.. I am attaching the jpegs :) of the graphs i made in
> MS Excel.
> We're happy with cold, raw ASCII numbers :)
> > Btw, I have implemented NAPI in both 2.4.20 and 2.6.10. I ported the
> > code to linux-2.6 in order to increase the board's
> efficiency but I'm
> > quite dissapointed with the results so far :(.
> NAPI is doing it's job which is keeping a system responsive
> under extreme
> loads very well. The pre-NAPI behaviour was simply locking
> up thus making
> systems easily DOS-able. NAPI is not meant to improve
> latency; it isn't
> meant but frequently mistaken to.