> Really, it should be in terms of "time". If you assume 6 msec seek and
> 30 mbyte/sec bandwidth, the crossover is a 120 kbyte I/O.
Now figure in the rotational latency and the crossover point has
moved to 200 kB. ;)
> Not that I'm sure this means anything interesting ;) But the lesson is
> that the size of a request isn't very important.
Besides, larger requests are much more efficient so penalising
those is the very last thing we want to do.
> Better would be to perform those reads and writes in nice big batches.
> That's easy for the writes, but for reads we need to wait for the
> application to submit another one. That means actually deliberately
> leaving the disk head idle for a few milliseconds in the anticipation
> that the application will submit another nearby read. This is called
> "anticipatory scheduling" and has been shown to provide 20%-70%
> performance boost in web serving workloads. It just makes heaps of
> sense to me and I'd love to see it in Linux...
It only makes sense under heavy multiprocessing workloads where
we have multiple processes submitting IO, but if it's just one
process all this deliberate delay will achieve is a slowdown of
the process.
> See http://www.cs.ucsd.edu/sosp01/papers/iyer.pdf
Looking at it now.
regards,
Rik
-- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>- 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/