All of lore.kernel.org
 help / color / mirror / Atom feed
* Fwd: How to improve performance of 2.6 kernel
  2005-10-17 16:38     ` Dan Malek
@ 2005-10-19  5:55       ` kernel coder
  2005-10-19 15:53         ` Ralf Baechle
  0 siblings, 1 reply; 5+ messages in thread
From: kernel coder @ 2005-10-19  5:55 UTC (permalink / raw)
  To: linux-mips

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

Hi,

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.
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 :(.



---------- Forwarded message ----------
From: Dan Malek <dan@embeddedalley.com>
Date: Oct 17, 2005 9:38 PM
Subject: Re: How to improve performance of 2.6 kernel
To: "Kevin D. Kissell" <KevinK@mips.com>
Cc: kernel coder <lhrkernelcoder@gmail.com>,
linux-mips@linux-mips.org, Stuart Longland <redhatter@gentoo.org>



On Oct 17, 2005, at 11:19 AM, Kevin D. Kissell wrote:

> If this can't be explained by a configuration error, we have a real
> problem here, but if that's the case, I'm surprised no one has raised
> a red flag earlier.

It has been discussed on other processor architecture lists.
It's been hard to justify the move from 2.4 to 2.6 on resource
challenged embedded systems, which unfortunately make up the
majority of systems running Linux.  There are various processor
specific modifications (mostly around VM, MMU, and cache
management) being attempted to bring the performance level
back up to 2.4.  If these were back ported to 2.4, I suspect the
performance difference would be even greater.

Of course, the speed and resources of workstations masks
the problems, so most developers don't "feel" the system is
any different. There isn't interest in the detailed performance
measurements we have to do on embedded systems when
we do an upgrade and realize it doesn't meet the performance
goals.  This is usually just written off with the "....  well, you have
new features .." statement, but somehow it doesn't add up.

There isn't any magic configuration option or quick fix.  You
have to take the time to dig into the details of a specific
performance issue and then try to optimize anything you can
to improve the situation.

Thanks.

        -- Dan

[-- Attachment #2: diagram1.JPG --]
[-- Type: image/jpeg, Size: 91133 bytes --]

[-- Attachment #3: diagram2.JPG --]
[-- Type: image/jpeg, Size: 89134 bytes --]

[-- Attachment #4: diagram3.JPG --]
[-- Type: image/jpeg, Size: 83849 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fwd: How to improve performance of 2.6 kernel
  2005-10-19  5:55       ` Fwd: " kernel coder
@ 2005-10-19 15:53         ` Ralf Baechle
  0 siblings, 0 replies; 5+ messages in thread
From: Ralf Baechle @ 2005-10-19 15:53 UTC (permalink / raw)
  To: kernel coder; +Cc: linux-mips

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.

  Ralf

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Fwd: How to improve performance of 2.6 kernel
@ 2005-10-19 18:12 ` Mitchell, Earl
  0 siblings, 0 replies; 5+ messages in thread
From: Mitchell, Earl @ 2005-10-19 18:12 UTC (permalink / raw)
  To: Ralf Baechle, kernel coder; +Cc: linux-mips


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. 

-earlm

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ralf Baechle
> Sent: Wednesday, October 19, 2005 8:54 AM
> To: kernel coder
> Cc: linux-mips@linux-mips.org
> 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.
> 
>   Ralf
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Fwd: How to improve performance of 2.6 kernel
@ 2005-10-19 18:12 ` Mitchell, Earl
  0 siblings, 0 replies; 5+ messages in thread
From: Mitchell, Earl @ 2005-10-19 18:12 UTC (permalink / raw)
  To: Ralf Baechle, kernel coder; +Cc: linux-mips


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. 

-earlm

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ralf Baechle
> Sent: Wednesday, October 19, 2005 8:54 AM
> To: kernel coder
> Cc: linux-mips@linux-mips.org
> 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.
> 
>   Ralf
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fwd: How to improve performance of 2.6 kernel
  2005-10-19 18:12 ` Mitchell, Earl
  (?)
@ 2005-10-20  9:36 ` Ralf Baechle
  -1 siblings, 0 replies; 5+ messages in thread
From: Ralf Baechle @ 2005-10-20  9:36 UTC (permalink / raw)
  To: Mitchell, Earl; +Cc: kernel coder, linux-mips

On Wed, Oct 19, 2005 at 11:12:22AM -0700, Mitchell, Earl wrote:

> 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. 

A common cause for low networking performance is connection tracking.  Just
loading the module will have serious impact.

  Ralf

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-10-20  9:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-19 18:12 Fwd: How to improve performance of 2.6 kernel Mitchell, Earl
2005-10-19 18:12 ` Mitchell, Earl
2005-10-20  9:36 ` Ralf Baechle
  -- strict thread matches above, loose matches on Subject: below --
2005-10-17 11:29 kernel coder
2005-10-17 12:36 ` Stuart Longland
2005-10-17 15:19   ` Kevin D. Kissell
2005-10-17 16:38     ` Dan Malek
2005-10-19  5:55       ` Fwd: " kernel coder
2005-10-19 15:53         ` Ralf Baechle

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.