lkml.org 
[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IO scheduler benchmarking
rwhron@earthlink.net wrote:
>
> Executive question: Why does 2.5.62-mm2 have higher sequential
> write latency than 2.5.61-mm1?

Well bear in mind that we sometimes need to perform reads to be able to
perform writes. So the way tiobench measures it, you could be seeing
read-vs-write latencies here.

And there are various odd interactions in, at least, ext3. You did not
specify which filesystem was used.

> ...
> Thr MB/sec CPU% avg lat max latency
> 2.5.62-mm2-as 8 14.76 52.04% 6.14 4.5
> 2.5.62-mm2-dline 8 9.91 13.90% 9.41 .8
> 2.5.62-mm2 8 9.83 15.62% 7.38 408.9

Fishiness. 2.5.62-mm2 _is_ 2.5.62-mm2-as. Why the 100x difference?

That 408 seconds looks suspect.


I don't know what tiobench is doing in there, really. I find it more useful
to test simple things, which I can understand. If you want to test write
latency, do this:

while true
do
write-and-fsync -m 200 -O -f foo
done

Maybe run a few of these. This command will cause a continuous streaming
file overwrite.


then do:

time write-and-fsync -m1 -f foo

this will simply write a megabyte file, fsync it and exit.

You need to be careful with this - get it wrong and most of the runtime is
actually paging the executables back in. That is why the above background
load is just reusing the same pagecache over and over.

The latency which I see for the one megabyte write and fsync varies a lot.
From one second to ten. That's with the deadline scheduler.

There is a place in VFS where one writing task could accidentally hammer a
different one. I cannot trigger that, but I'll fix it up in next -mm.


-
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: 2005-03-22 13:33    [W:0.041 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site