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

On Thu, Oct 06, 2016 at 08:01:42PM +0200, Paolo Valente wrote:

quoted

Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal [off-list ref] ha scritto:

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

[..]

quoted

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.

quoted

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