linux-kernel - Re: [PATCH V3 00/11] block-throttle: add .high limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161006174943.GD17335@redhat.com>
Date:   Thu, 6 Oct 2016 13:49:43 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Paolo Valente <paolo.valente@...more.it>
Cc:     Shaohua Li <shli@...com>, Tejun Heo <tj@...nel.org>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jens Axboe <axboe@...com>, Kernel-team@...com,
        jmoyer@...hat.com, Mark Brown <broonie@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit

On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote:

[..]
> Shaohua, I have just realized that I have unconsciously defended a
> wrong argument.  Although all the facts that I have reported are
> evidently true, I have argued as if the question was: "do we need to
> throw away throttling because there is proportional, or do we need to
> throw away proportional share because there is throttling?".  This
> question is simply wrong, as I think consciously (sorry for my
> dissociated behavior :) ).

I was wondering about the same. We need both and both should be able 
to work with fast devices of today using blk-mq interfaces without
much overhead.

> 
> The best goal to achieve is to have both a good throttling mechanism,
> and a good proportional share scheduler.  This goal would be valid if
> even if there was just one important scenario for each of the two
> approaches.  The vulnus here is that you guys are constantly, and
> rightly, working on solutions to achieve and consolidate reasonable
> QoS guarantees, but an apparently very good proportional-share
> scheduler has been kept off for years.  If you (or others) have good
> arguments to support this state of affairs, then this would probably
> be an important point to discuss.

Paolo, CFQ is legacy now and if we can come up with a proportional
IO mechanism which works reasonably well with fast devices using
blk-mq interfaces, that will be much more interesting.

Vivek