mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-09-22 22:11:38 +08:00
3c337690d2
BFQ tags some bfq_queues as interactive or soft_rt if it deems that these bfq_queues contain the I/O of, respectively, interactive or soft real-time applications. BFQ privileges both these special types of bfq_queues over normal bfq_queues. To privilege a bfq_queue, BFQ mainly raises the weight of the bfq_queue. In particular, soft_rt bfq_queues get a higher weight than interactive bfq_queues. A bfq_queue may turn from interactive to soft_rt. And this leads to a tricky issue. Soft real-time applications usually start with an I/O-bound, interactive phase, in which they load themselves into main memory. BFQ correctly detects this phase, and keeps the bfq_queues associated with the application in interactive mode for a while. Problems arise when the I/O pattern of the application finally switches to soft real-time. One of the conditions for a bfq_queue to be deemed as soft_rt is that the bfq_queue does not consume too much bandwidth. But the bfq_queues associated with a soft real-time application consume as much bandwidth as they can in the loading phase of the application. So, after the application becomes truly soft real-time, a lot of time should pass before the average bandwidth consumed by its bfq_queues finally drops to a value acceptable for soft_rt bfq_queues. As a consequence, there might be a time gap during which the application is not privileged at all, because its bfq_queues are not interactive any longer, but cannot be deemed as soft_rt yet. To avoid this problem, BFQ pretends that an interactive bfq_queue consumes zero bandwidth, and allows an interactive bfq_queue to switch to soft_rt. Yet, this fake zero-bandwidth consumption easily causes the bfq_queue to often switch to soft_rt deceptively, during its loading phase. As in soft_rt mode, the bfq_queue gets its bandwidth correctly computed, and therefore soon switches back to interactive. Then it switches again to soft_rt, and so on. These spurious fluctuations usually cause losses of throughput, because they deceive BFQ's mechanisms for boosting throughput (injection, I/O-plugging avoidance, ...). This commit addresses this issue as follows: 1) It does compute actual bandwidth consumption also for interactive bfq_queues. This avoids the above false positives. 2) When a bfq_queue switches from interactive to normal mode, the consumed bandwidth is reset (forgotten). This allows the bfq_queue to enjoy soft_rt very quickly. In particular, two alternatives are possible in this switch: - the bfq_queue still has backlog, and therefore there is a budget already scheduled to serve the bfq_queue; in this case, the scheduling of the current budget of the bfq_queue is not hindered, because only the scheduling of the next budget will be affected by the weight drop. After that, if the bfq_queue is actually in a soft_rt phase, and becomes empty during the service of its current budget, which is the natural behavior of a soft_rt bfq_queue, then the bfq_queue will be considered as soft_rt when its next I/O arrives. If, in contrast, the bfq_queue remains constantly non-empty, then its next budget will be scheduled with a low weight, which is the natural treatment for an I/O-bound (non soft_rt) bfq_queue. - the bfq_queue is empty; in this case, the bfq_queue may be considered unjustly soft_rt when its new I/O arrives. Yet the problem is now much smaller than before, because it is unlikely that more than one spurious fluctuation occurs. Tested-by: Jan Kara <jack@suse.cz> Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
---|---|---|
.. | ||
partitions | ||
badblocks.c | ||
bfq-cgroup.c | ||
bfq-iosched.c | ||
bfq-iosched.h | ||
bfq-wf2q.c | ||
bio-integrity.c | ||
bio.c | ||
blk-cgroup-rwstat.c | ||
blk-cgroup-rwstat.h | ||
blk-cgroup.c | ||
blk-core.c | ||
blk-crypto-fallback.c | ||
blk-crypto-internal.h | ||
blk-crypto.c | ||
blk-exec.c | ||
blk-flush.c | ||
blk-integrity.c | ||
blk-ioc.c | ||
blk-iocost.c | ||
blk-iolatency.c | ||
blk-lib.c | ||
blk-map.c | ||
blk-merge.c | ||
blk-mq-cpumap.c | ||
blk-mq-debugfs-zoned.c | ||
blk-mq-debugfs.c | ||
blk-mq-debugfs.h | ||
blk-mq-pci.c | ||
blk-mq-rdma.c | ||
blk-mq-sched.c | ||
blk-mq-sched.h | ||
blk-mq-sysfs.c | ||
blk-mq-tag.c | ||
blk-mq-tag.h | ||
blk-mq-virtio.c | ||
blk-mq.c | ||
blk-mq.h | ||
blk-pm.c | ||
blk-pm.h | ||
blk-rq-qos.c | ||
blk-rq-qos.h | ||
blk-settings.c | ||
blk-stat.c | ||
blk-stat.h | ||
blk-sysfs.c | ||
blk-throttle.c | ||
blk-timeout.c | ||
blk-wbt.c | ||
blk-wbt.h | ||
blk-zoned.c | ||
blk.h | ||
bounce.c | ||
bsg-lib.c | ||
bsg.c | ||
cmdline-parser.c | ||
elevator.c | ||
genhd.c | ||
ioctl.c | ||
ioprio.c | ||
Kconfig | ||
Kconfig.iosched | ||
keyslot-manager.c | ||
kyber-iosched.c | ||
Makefile | ||
mq-deadline.c | ||
opal_proto.h | ||
scsi_ioctl.c | ||
sed-opal.c | ||
t10-pi.c |