Hi,
you may have the impression that we entered a frenetic code-development
phase with BFQ. Well, you are right. Why?
Because at last it seems that we have found the time to pack BFQ for
submission to lkml. And, while breaking down BFQ into a set of logically
distinct patches (for review), we have bumped into a small piece of BFQ
that we could not describe clearly. Finally, we have understood,
embarrassingly, that we let the heuristic for soft real-time
applications perform one important step in a confused way ...
So we fixed that, and here is the result: v7r2. Besides being
conceptually clear, the new version of this step also provided little
additional benefits in terms of responsiveness and latency for soft
real-time applications. If you are interested into more details, I
pasted an excerpt of the changelog at the end of this email.
Thanks to the indispensable contribution of Arianna, patches are again
available for a countless number of kernel versions.
Finally, I took the opportunity to further update the test-result page
with the results for v7r2, obtained using the just-released new version
of the benchmark suite:
http://www.algogroup.unimo.it/people/paolo/disk_sched/results.php
In particular, this page now also contains a link to an extra result
page, with responsiveness results for two more applications and, above
all, frame-drop-rate results for our video-playing tests. I do suggest
you to have a look at these results, if only to better know what you are
putting in your kernels :)
Paolo
Excerpt from the changelog:
BUGFIX/IMPROVEMENT. One of the requirements for an application to be
deemed as soft real-time is that it issues its requests in batches, and
stops doing I/O for a well-defined amount of time before issuing a new
batch. Imposing this minimum idle time allows BFQ to filter out I/O-bound
applications that may otherwise be incorrectly deemed as soft real-time
(under the circumstances described in detail in the comments to the
function bfq_bfqq_softrt_next_start()). Unfortunately, BFQ could however
start counting this idle time from two different events: either from the
expiration of the queue, if all requests of the queue had also been already
completed when the queue expired, or, if the previous condition did not
hold, from the first completion of one of the still outstanding requests.
In the second case, an application had more chances to be deemed as soft
real-time.
Actually, there was no reason for this differentiated treatment. We
addressed this issue by defining more precisely the above requirement for
an application to be deemed as soft real-time, and changing the code
consequently: a well-defined amount of time must elapse between the
completion of *all the requests* of the current pending batch and the
issuing of the first request of the next batch (this is, in the end, what
happens with a true soft real-time application). This change further
reduced false positives, and, as such, improved responsiveness and reduced
latency for actual soft real-time applications.