Additional responsiveness results
In this page we report further responsiveness results, with respect to the ones provided in our main result page. In particular, for each device we report our results with xterm and lowriter.
The same comments as in the main result page apply for xterm, so we do not repeat them also in this page. On the other hand, we add an explanation of why lowriter start-up time almost doubles with writes in the background.
HITACHI HDD
With 10r-seq, BFQ guarantees a start-up time comparable to that with an idle device, whereas with all the other schedulers the application fails, with any background workload, to start in 60 seconds. As for 5r5w-seq, the higher start-up time of lowriter with BFQ is mainly due to the combination of the following tricky problems:
- lowriter needs to perform some writes to complete its start-up process.
- Because of the high rate at which the five greedy writers issue write requests, opposed to the slow relative speed of the device, dirty pages start to be flushed soon. After that, and until greedy writers stop, all writes become blocking, i.e., any process issuing a write request is blocked until that request is completed.
- Write requests are delegated to flusher threads, and, in the BFQ queues associated to these threads, the writes generated by lowriter get mixed up anonymously with the writes incessantly generated by the greedy writers.
- BFQ has no information to know that lowriter's writes are more urgent than others. In addition, the writes generated by the greedy writers are sequential, i.e., the most beneficial ones to achieve a high throughput. For these reasons, BFQ privileges the latter with respect to lowriter writes.
- BFQ guarantees however that, after a given maximum waiting time, any queued request eventually gets dispatched. But having each write request to wait, in the worst-case, for this maximum time before being dispatched, significantly inflates the start-up time of lowriter (on the opposite side, reducing this maximum waiting time would unavoidably impact throughput).
PLEXTOR SSD
With writes in the background, the start-up time of lowriter almost doubles, for the same reason as for the HDD.