lkml.org 
[lkml]   [2005]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git patches] IDE update


On Wed, 6 Jul 2005, Grant Coady wrote:
>
> Sure, take a while longer to vary by block size. One effect seems
> to be wrong is interaction between /dev/hda and /dev/hdc in 'peetoo',
> the IDE channels not independent?

Well, looking at your numbers for "silly" and "tosh", which were perhaps
the most extreme examples of slowdown on the /dev/hda thing:

silly: 22MB/s -> 8.5MB/s, oread similar 13GB
tosh: 35MB/s -> 23MB/s, oread similar 40GB 2.5"

now it says:

> summary 2.4.31-hf1 2.6.12.2
> boxen \ time -> w r w r
> --------------- ---- ---- ---- ----
> silly 54 24 49 25
> tosh 30 19.5 27 19.5

ie here both silly and tosh do equally well on 2.4.x and 2.6.x on reads,
and seem to perhaps show a bit of slowdown on writes (which I suspect may
be due to the fact that we try to limit the queues a bit more, but hey,
that's handwaving).

The point being that the slowdown you see seems to really largely be
limited to the raw partition code. Your filesystem throughput numbers for
reads are generally _better_ on 2.6.x than on 2.4.x when doing filesystem
accesses (but the differences aren't all that big).

So my gut feel is that the reason hdparm and dd from the raw partition
gives different performance is not so much the driver, but probably that
we've tweaked read-ahead for file access or something like that. Maybe
the maximum fs-level read-ahead changed?

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.067 / U:7.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site