From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751487AbcDOOtZ (ORCPT ); Fri, 15 Apr 2016 10:49:25 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:35081 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbcDOOtX (ORCPT ); Fri, 15 Apr 2016 10:49:23 -0400 MIME-Version: 1.0 In-Reply-To: <20160414162953.GG12583@htj.duckdns.org> References: <1454364778-25179-1-git-send-email-paolo.valente@linaro.org> <1454364778-25179-10-git-send-email-paolo.valente@linaro.org> <20160211222210.GC3741@mtj.duckdns.org> <8FDE2B10-9BD2-4741-917F-5A37A74E5B58@linaro.org> <20160217170206.GU3741@mtj.duckdns.org> <72E81252-203C-4EB7-8459-B9B7060029C6@linaro.org> <20160301184656.GI3965@htj.duckdns.org> <20160413204110.GF20142@htj.duckdns.org> <2B664E4D-857C-4BBA-BE77-97EA6CC3F270@linaro.org> <20160414162953.GG12583@htj.duckdns.org> Date: Fri, 15 Apr 2016 16:49:22 +0200 Message-ID: Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler From: Linus Walleij To: Tejun Heo Cc: Paolo Valente , Jens Axboe , Fabio Checconi , Arianna Avanzini , linux-block@vger.kernel.org, "linux-kernel@vger.kernel.org" , Ulf Hansson , Mark Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2016 at 6:29 PM, Tejun Heo 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