| |||||||||||||
The CFQ "low latency" modeThe CFQ "low latency" modePosted Oct 13, 2009 0:22 UTC (Tue) by giraffedata (subscriber, #1954)In reply to: The CFQ "low latency" mode by Yenya Parent article: The CFQ "low latency" mode OK, I'll buy that. Letting the disk sit idle can improve the throughput capacity for a limited workload like that (limited not because there are times when there is no work available but because there are only two streams and each apparently doesn't want to have more than one I/O at a time outstanding). What I was thinking is that when people ask about disk throughput (capacity), it's usually on a system that drives the disk a lot harder than that -- i.e. the disk's basic capacity is in question. That means requesters throw large amounts of I/O at the disk and the speed is then determined by how quickly the disk can move the I/Os through. In the A-B scenario you describe, I would ask about the disk's response time, not its throughput, because it's the waiting for a response that governs the speed of this system.
(Log in to post comments)
The CFQ "low latency" mode Posted Oct 13, 2009 18:06 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
it's not necessarily as different as you are making it out to be.
remember that seeks are _expensive_, you can transfer a LOT of data in the time of one seek that you can avoid doing.
so throughput optimizations like this can be relevant to the total disk response capabilities.
|
|||||||||||||