Hi Andrea,
> not exactly decreases I/O throughput, the latest I/O benchmarks I seen
it decreases performance. I've seen this, Con also saw this (well it's better
than the 'nr_requests = 4' change ;) but mouse stops are still there.
> from Randy (dbench/tiotest/bonnie/etc..) were still the fastest and it
> included the lowlatency elevator patch. So it may not help latency but
> it doesn't hurt in the numbers, at least not in the high end (that in
> theory is the one that needs the overkill length in the I/O queue most).
I agree with the last sentence, in theory, but practice showed something
different (about 10% to 15% performance decrease)
But I am quite sure that this depends on your machine/hardware. Using IDE
instead of SCSI for example.
> However it definitely helps latency for me and I had a number of
> positive reports.
It helps but it's not as good as 2.4.18 stock.
> Also make sure that you elvtune -r 0 -w 0 /dev/hda, also the journaling
I also tried that.
> may affect the latency so you can try with plain ext2 to be sure it's
> not a fs issue.
Sure, I did this too. FS independent, where ReiserFS is still the best for
this scenario with the most few pauses than any other FS (ext2, ext3, ...)
But for desktop usage: not acceptable! No way, No go!
> the lowlatency elevator patch may not be perfect but it definitely seems
> to work better here. especially since there's no apparent throughput
> loss, it makes lots of sense to keep it applied, or it would waste lots
> of ram for apparently no gain.
hehe, well wasting RAM for no gain is my next part on my todo ;) (cache
everything even if there is no RAM for example, well but this is not the
point in this thread)
ciao, Marc
-
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/