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.
PLEXTOR SSD
Both with 10r-seq and 5r5w-seq, BFQ guarantees a start-up time of lowriter comparable to that with an idle device, and dramatically outperforms the other I/O schedulers. In some cases, the latter even make the application fail to start in 60 seconds. With 5r5w-seq, BFQ guarantees a higher start-up time than with 10r-seq. This 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, 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).
HITACHI HDD
With 10r-seq, BFQ guarantees a start-up time comparable to that with an idle device also in case of an HDD, whereas with all the other schedulers the application fails, with any background workload, to start in 60 seconds. With writes in the background, the start-up time of lowriter with BFQ almost doubles, for the same reason as for the HDD.