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: <FE2E9F43-610D-40B7-BA08-627CC53B2F6C@unimore.it>
Date:   Thu, 6 Oct 2016 20:01:42 +0200
From:   Paolo Valente <paolo.valente@...more.it>
To:     Vivek Goyal <vgoyal@...hat.com>
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


> 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?

Thanks,
Paolo


> Vivek


--
Paolo Valente
Algogroup
Dipartimento di Scienze Fisiche, Informatiche e Matematiche
Via Campi 213/B
41125 Modena - Italy
http://algogroup.unimore.it/people/paolo/