> Il giorno 08 gen 2017, alle ore 17:30, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> ha scritto: > > On Tue, 2017-01-03 at 10:39 +0100, Paolo Valente wrote: >>> Il giorno 03 gen 2017, alle ore 09:17, Bart Van Assche <Bart.VanAss >>> che@xxxxxxxxxxx> ha scritto: >>> >>> * Since BFQ has been designed for hard disks and since the approach >>> in BFQ for handling deceptive idleness reduces bandwidth, what >>> scheduling algorithm to use for storage media that do not have any >>> moving parts (SSDs and MMC). >> >> I would really like to have the opportunity to debunk this false >> myth. BFQ is optimized for rotational as well as non-rotational >> device. BFQ does not keep up only if IOPS go beyond ~50k. And I'm >> already working on this limitation, but, as agreed with Jens, the >> priority for the moment is pushing BFQ as it is. > > Hello Paolo, > > A quote from the section "Service Properties" from a paper from 2010 > about BFQ: "In this section we report the service properties of BFQ, in > both sector (bandwidth distribution) and time domains. [ ... ] As a > consequence, one would set Twait as high as possible to include as many > applications as possible. However, the value of Twait has an important > impact on the disk throughput. It may provide significant boosting in > presence of deceptive idleness, but only if its value is in the order > of the seek and rotational latencies [1], namely a few milliseconds. In > contrast, higher values may cause progressive performance degradation, > as the disk may be left idle for too long." > > Did I understand correctly that BFQ uses disk idling to improve > sequential I/O throughput for hard disks? Definitely. > If so, my question is why you > think that disk idling will not reduce throughput for SSDs since disk > idling keeps the queue depth low while SSDs perform best for workloads > with a high queue depth? > Because BFQ disables idling for non-rotational devices, especially if NCQ-capable. More precisely, on non-rotations devices, BFQ does not idle to boost throughput, because idling would yield the opposite result. Unfortunately, this is one of the small improvements that I had not the occasion to describe in any paper. However, you can find a detailed description of this improvement, in,.e.g., the commit message for the patch that makes this change within the last BFQ patch series I have submitted (October 26). I have pasted this message below for your convenience. Thanks, Paolo block, bfq: boost the throughput on NCQ-capable flash-based devices This patch boosts the throughput on NCQ-capable flash-based devices, while still preserving latency guarantees for interactive and soft real-time applications. The throughput is boosted by just not idling the device when the in-service queue remains empty, even if the queue is sync and has a non-null idle window. This helps to keep the drive's internal queue full, which is necessary to achieve maximum performance. This solution to boost the throughput is a port of commits a68bbdd and f7d7b7a for CFQ. As already highlighted in a previous patch, allowing the device to prefetch and internally reorder requests trivially causes loss of control on the request service order, and hence on service guarantees. Fortunately, as discussed in detail in the comments on the function bfq_bfqq_may_idle(), if every process has to receive the same fraction of the throughput, then the service order enforced by the internal scheduler of a flash-based device is relatively close to that enforced by BFQ. In particular, it is close enough to let service guarantees be substantially preserved. Things change in an asymmetric scenario, i.e., if not every process has to receive the same fraction of the throughput. In this case, to guarantee the desired throughput distribution, the device must be prevented from prefetching requests. This is exactly what this patch does in asymmetric scenarios. > Thanks, > > Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
