On Thu, Apr 14, 2016 at 6:29 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > On Thu, Apr 14, 2016 at 12:23:14PM +0200, Paolo Valente wrote: > ... >> >> 3) Stable(r) and low latency for soft real-time applications (...) >> Goals 2-4 are obtained by granting a higher share of the throughput >> to the applications to privilege. (...) > 4) makes sense as a lot of that workload would be at least > quasi-sequential but I can't tell why 2) and 3) would depend on > bandwidth based scheduling. They're about recognizing workloads which > can benefit from low latency and treating them accordingly. Why would > making the underlying scheduling time based change that? For (3) Isn't that fairly intuitive? Media people (think vlc, mplayer, gstreamer and whatnot) have a framed media format, and need the following to process it and guarantee an enjoyable media stream with audio/video: - a certain number of bits/s from the storage device or network - a certain number of MIPS or FLOPS or whatnot from the CPU before a certain deadline (a determinate time slice of computation time) What they don't need is an allocated time slice on a block device. So the BFQ is asking the right question for that kind of applications: how many bits/s can I get, and it delivers accordingly. For the record I have successfully reproduced Paulo's reported benefits from this test case: https://github.com/Algodev-github/S/blob/master/video_playing_vs_commands/video_play_vs_comms.sh Less frames *are* dropped! And I have been booting BFQ kernels for my development laptop for the last months simply because I like to have a music stream running while working. With a stock kernel, my heavy git operations (like git fetch && git reset --hard origin/master on linux-next) makes the audio skip and hang for seconds. With the BFQ-patched kernel it does *not* happen. This is subjective though, based on intuition. Yours, Linus Walleij -- 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
