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 bash, xterm and lowriter.
As for responsiveness results, the same comments as in the main result page apply for bash and xterm, so we do not repeat them also in this page. Things change with lowriter.
HITACHI HDD
The next two figures show the cold-cache start-up time of bash and xterm while one of the following four heavy workloads is being executed: 10 parallel sequential or random readers (10r-seq, 10r-rand), 5 parallel sequential or random readers plus 5 parallel sequential or random writers (5r5w-seq, 5r5w-rand). The symbol X means that, for that workload and with that scheduler, the application failed to start in 60 seconds.
Finally, here are our responsiveness results with lowriter.
Except for the case 5r5w-seq, BFQ again guarantees a start-up time comparable to that with an idle disk, 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, 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).
SEAGATE HDD
Tests abandoned because the relative performance of the schedulers is the same as on the other HDD.
PLEXTOR SSD
The next three figures show the cold-cache start-up time of bash, xterm and lowriter.
