Re: [PATCH V3 00/11] block-throttle: add .high limit
From: Paolo Valente
Date: Thu Oct 06 2016 - 16:53:27 EST
> 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,
> 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
> 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.
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
> 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
Dipartimento di Scienze Fisiche, Informatiche e Matematiche
Via Campi 213/B
41125 Modena - Italy