From: Felix Domke <tmbinc@elitedvb.net>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: 2.6 vs 2.4
Date: Fri, 12 May 2006 16:23:21 +0200 [thread overview]
Message-ID: <44649A59.5050608@elitedvb.net> (raw)
In-Reply-To: <1147442231.9412.9.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-05-12 14:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 6:51 2.6 vs 2.4 Srinivas Murthy
2006-05-12 13:57 ` Benjamin Herrenschmidt
2006-05-12 14:02 ` Benjamin Herrenschmidt
2006-05-12 14:23 ` Felix Domke [this message]
2006-05-12 14:29 ` Thiago Galesi
2006-05-12 14:43 ` Felix Domke
2006-05-12 16:24 ` Thiago Galesi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44649A59.5050608@elitedvb.net \
--to=tmbinc@elitedvb.net \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).