Subject: Re: 2.6 vs 2.4

From: Felix Domke <[email-masked]>
Date: Fri, 12 May 2006 16:23:21 +0200

Benjamin Herrenschmidt wrote:
>> Wolfgang Denk has a good listing of issues to consider betn linux 2.4
>>vs 2.6 for ppc82xx based platforms
>>(http://www.denx.de/wiki/Know/Linux24vs26).
>> Would this recommendation still hold?
>> Are there any patches, developments in this area?
> The main open question is: is somebody still maintaining the 8xx kernel
> port ?
The 4xx port has the same problem.

When we switched from 2.4 to 2.6, IDE performance ("hdparm -t" to have a
single number) was reduced by about 25% (even after trying to finetune
the IDE driver - the time between the end of one transfer and the begin
of the next transfer was just too long to saturate the harddisk).

Because of my lack of knowledge of the block device layer's internals I
wasn't able to track that down. My initial plan was to build a trace
using the RiscTrace environment, to see any instruction executed between
requests, but my company moved away from PPC4xx hardware
(unfortunately), so I was never able to complete this. I still believe
that other platforms have the same problems.

On a 300MHz embedded mips machine, saturating a 100MBit network link via
ftp is not easy. Our old 252MHZ PPC machines never performed better than
around 5MB/s (but had a non-DMA NIC, which however could be satured in
theory with about 70% cpu load, based on the bus bandwidth. Why are the
remaining 30% not enough to do IDE DMA and the TCP overhead? Memory
performance? But why did we had better numbers with 2.4 then?).

On that mips machine, both IDE and network support DMA (agreed, it's a
RTL8139, so it requires another memcpy), and memcpy() performance is
>100MB/s. Where is the bottleneck? And, much more important: how do
measure it?

I'm sorry that I can't really much do anything else than complaining,
but all my attempts to track down the problems were futile. I'm not sure
if testing "ftp performance" (as a completely non-synthetic benchmark -
FTP speed is/was a real issue on our platform) is "the right test", but
it's one of the things where i personally want linux to become better.

Or is this just a misconfiguration? Are there mysterious IO scheduler
default parameters which are just suboptimal for our case?

regards,
Felix