The CFQ "low latency" mode
The CFQ "low latency" mode
Posted Oct 15, 2009 14:50 UTC (Thu) by guest (guest, #2027)In reply to: The CFQ "low latency" mode by Yenya
Parent article: The CFQ "low latency" mode
Anyway, if you have such workloads and you do *not* pause, what happens? You perform the first seek to A, read, A, seek to B, read B and in the meantime, more requests for A have arrived. If it's only one, you still seem to be fast enough despite seeking - just seek back to A and go on. If the seek takes too long, multiple request should have been queued already and you can coalesque them and handle them with one seek.
IMHO, letting a disk stay idle when there's work to do is wrong!
Posted Oct 15, 2009 17:57 UTC (Thu)
by efexis (guest, #26355)
[Link]
"letting a disk stay idle when there's work to do is wrong!"
The CFQ "low latency" mode
Except that the disk is as good as idle while it's seeking... you can't read or write while it's happening.
I already know this to be true, I come across it on a server I part manage, which tries to schedule backups for several sites all at once. The disk thrashes, it grinds to a halt, and it takes forever to finish. So, I wrote a small bash script that when the load gets high, sends a STOP signal to all the backup processes, and then sends just one of them a CONT signal, so only that one process is running. Every few seconds it will STOP that task, and CONT a different one. The backups complete in a much shorter time, and system responsiveness is much better while it's happening. Why? Because the heads don't move away from the current reader's position as often, even though it does that same issue-read, wait, process, issue-read, wait, process etc... read pattern. So, with the amount of time the drive spends seeking reduced, the SAME drive is able to complete the SAME amount of work in LESS time with LESS effect on the rest of the system.
This is just a fact, it's real, it works, as much as it may sound counter-intuitive to you, the numbers don't lie.