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

[Paolo Valente]

> Il giorno 06 ott 2016, alle ore 20:32, Vivek Goyal <vgoyal@xxxxxxxxxx> ha scritto:
> 
> 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@xxxxxxxxxx> 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,
> 

Hi

> People have been using CFQ for many years.

Yes, but allow me just to add that a lot of people have also been
unhappy with 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.
> 

Although I think that BFQ's benefits are relevant (but I'm a little
bit an interested party :) ), I do agree that abruptly replacing the
most used I/O scheduler (AFAIK) with a so different one is at least a
little risky.

> At this point of time replacing CFQ with something better is not a
> priority for me.

ok

> But if something better and stable goes upstream, I
> will gladly use it.
> 

Then, in case of success, I will be glad to receive some feedback from
you, and possibly use it to improve the set of ideas that we have put
into BFQ.

Thank you,
Paolo

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


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