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]

Date:   Thu, 6 Oct 2016 14:32:16 -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 08:01:42PM +0200, Paolo Valente wrote:
> 
> > Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal <vgoyal@...hat.com> ha scritto:
> > 
> > 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.
> > 
> 
> That's absolutely true.  But, why do we pretend not to know that, for
> (at least) hundreds of thousands of users Linux will go on giving bad
> responsiveness, starvation, high latency and unfairness, until blk
> will not be used any more (assuming that these problems will somehow
> disappear will blk-mq).  Many of these users are fully aware of these
> Linux long-standing problems.  We could solve these problems by just
> adding a scheduler that has already been adopted, and thus extensively
> tested, by thousands of users.  And more and more people are aware of
> this fact too.  Are we doing the right thing?

Hi Paolo,

People have been using CFQ for many years. I am not sure if benefits 
offered by BFQ over CFQ are significant enough to justify taking a
completely new code and get rid of CFQ. Or are the benfits significant
enough that one feels like putting time and effort into this and
take chances wiht new code.

At this point of time replacing CFQ with something better is not a
priority for me. But if something better and stable goes upstream, I
will gladly use it.

Vivek