Please sign in to comment.
bfq-mq, bfq-sq: fix wrong init of saved start time for weight raising
This commit fixes a bug causing bfq to fail to guarantee high responsiveness on some drives, if there is heavy random read+write I/O in the background. More precisely, this failure allowed this bug to be found , but the bug may well cause other yet unreported anomalies. BFQ raises the weight of the bfq_queues associated to soft real-time applications, to privilege the I/O, and thus reduce latency for the latter. This mechanism is named soft-real-time weight raising in BFQ. It may happen that, when a bfq_queue switches to a soft real-time weight-raised state, the bfq_queue is already being weight-raised for a different reason: because it is deemed interactive too. In this case, BFQ saves in a special variable wr_start_at_switch_to_srt, the time instant when the interactive weight-raising period started for the bfq_queue, i.e., the time instant when BFQ started to deem the bfq_queue interactive. This value is then used to understand whether the interactive weight-raising period needs to be restored for the bfq_queue, when the soft real-time weight-raising period ends. If, instead, a bfq_queue switches to soft-real-time weight raising while it *is not* already in an interactive weight-raising period, then the variable wr_start_at_switch_to_srt has no meaning during the following soft real-time weight-raising period. Unfortunately the handling of this case is wrong in BFQ: not only the variable is not flagged somehow as meaningless, but it is also set to the time when the switch to soft real-time weight-raising occurs. This may cause an interactive weight-raising period to be considered mistakenly as still in progress, and thus a spurious interactive weight-raising period to start for the bfq_queue, at the end of the soft-real-time weight-raising period. In particular the spurious interactive weight-raising period will be considered as still in progress, if the soft-real-time weight-raising period does not last very long. The bfq_queue will then be wrongly privileged and, if I/O bound, will unjustly steal bandwidth to truly interactive or soft real-time bfq_queues, harming responsiveness and low latency. This commit fixes this issue by just setting wr_start_at_switch_to_srt to minus infinity (farthest past time instant according to jiffies macros): when the soft-real-time weight-raising period ends, certainly no interactive weight-raising period will be considered as still in progress.  Background I/O Type: Random - Background I/O mix: Reads and writes - Application to start: LibreOffice Writer in http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.13-IO-Laptop Signed-off-by: Paolo Valente <email@example.com> Signed-off-by: Angelo Ruocco <firstname.lastname@example.org>
- Loading branch information...
Showing with 62 additions and 38 deletions.