Paolo Valente
unread,Jan 28, 2014, 5:51:27 AM1/28/14Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to bfq-i...@googlegroups.com
Hi,
believe it or not, BFQ-v7 is out! It has been a remarkable effort, but it seems like we made it.
One of the main improvements over v6r2 is that we found, or, more honestly, we bumped into a way to preserve a high responsiveness also in the presence of write hogs. Maybe some of you remember the discussion we had on this ml about the bad things that happen even if you just copy a large file: once the configured threshold of dirty pages is reached, a storm of asynchronous write requests starts. In particular, the rate at which writes are issued happen to be higher than that at which the device can serve them. To handle this kind of situations, the block layer uses a simple blocking scheme: the maximum number of overall pending I/O request for a device is limited, and, if a process tries to make a new I/O request when the pool is exhausted, that process just blocks, waiting for a request to be available.
Many problems follow from this fact:
1) If the unlucky process is updating metadata, the access to the whole filesystem may then be blocked until this process completes its job
2) If the unlucky process is executing an interactive task, such loading its own image and related libraries to start, you risk to wait for a while, until it 'grabs' all the I/O requests it needs.
In the end, the system, i.e., you, experience low responsiveness or even whole-system starvation. I let you imagine what happens if more than one process is writing greedily …
Well, BFQ-v7 contains an improvements that seems to recover responsiveness also in these situations! If you are curious about how this is achieved, have a look at the changelog, or, if you are brave enough, to the code itself.
Other relevant improvements are:
- better (and fixed) detection of soft real-time applications, which now filters out unwanted intruders and hence improves latency for the applications that really need it
- better handling of NCQ-enabled rotational disks, which boosts the throughput on these devices more than before (well, honestly this was a middle way between a bugfix and an improvement :) )
- a simple solution to make low-latency heuristics more robust inside a QEMU virtual machine and on an embedded system.
I wish to thank Virtual Open Systems, a company that, as part of a contract, allowed us to test BFQ also on new medias, such as microSDHC Cards, eMMCs and 1.8-inch HDDs. They also contributed to the above last improvement to BFQ.
I am sorry for the long email, but, believe me on that there would be even more to say about this new version of BFQ. The main improvements that you should experience are, regardless of the background workload and regardless on what device or environment you are executing BFQ in: a lower and more 'stable' responsiveness, a lower latency for time-sensitive applications such as video players, a higher throughput on NCQ-enabled hard disks.
This time we have tested BFQ-v7 on really many devices: single high-speed hard disks, high-speed disks paired in a software RAID1 configuration, SSDs, plus the above mentioned medias. We should publish soon a new version of the "test results" page, reporting our last results on these devices.
To conclude, I wish to thank as usual Arianna for her fundamental help and, in particular, for preparing all the patches also this time. Should you need BFQ-v7 for a previous kernel release than 3.2, just ask.
That's all, I hope you will all enjoy the results of our last two years of work on BFQ. Any feedback is more than welcome,
Paolo