Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

[Paolo Valente]

Il giorno 31/mag/2014, alle ore 01:28, Tejun Heo <tj@xxxxxxxxxx> ha scritto:

> Hello,
> 
> On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
>> I do agree that bfq has essentially the same purpose as cfq. I am
>> not sure that it is what you are proposing, but, in my opinion,
>> since both the engine and all the new heuristics of bfq differ from
>> those of cfq, a replacement would be most certainly a much easier
>> solution than any other transformation of cfq into bfq (needless to
>> say, leaving the same name for the scheduler would not be a problem
>> for me). Of course, before that we are willing to improve what has
>> to be improved in bfq.
> 
> Well, it's all about how to actually route the changes and in general
> whenever avoidable we try to avoid whole-sale code replacement
> especially when most of the structural code is similar like in this
> case.  Gradually evolving cfq to bfq is likely to take more work but
> I'm very positive that it'd definitely be a lot easier to merge the
> changes that way and people involved, including the developers and
> reviewers, would acquire a lot clearer picture of what's going on in
> the process.

I understand, and apologize for proposing an inappropriate shortcut.

>  For example, AFAICS, most of the heuristics added by the
> later patches are refined versions of what's already in cfq and at
> least some are applicable regardless of the underlying scheduling
> algorithm.

Absolutely correct.

>  It all depends on the details but, for example, steps like
> the following would be it a lot easier to get merged.
> 
> * Identify the improvements which can be applied to cfq as-is or with
>  some adaptation and apply those improvements to cfq.
> 
> * Make prepatory changes to make transition to new base scheduling
>  algorithm easier.
> 
> * Strip out or disable cfq features which get in the way of
>  conversion.
> 
> * Switch the base algorithm to the timestamp based one.
> 
> * Rebuild stripped down features and apply new heuristics,
>  optimizations and follow-up changes.
> 

OK, we can try.

> I understand that this might be non-significant amount of work

This may be a non-negligible difficulty, as Arianna, who is actively helping me with this project, and I are working on bfq in our (little) spare time. But if you are patient enough, we will be happy to try to make it one step at a time.

> but at
> the same time it's not something which is inherently difficult.  It's
> mostly logistical after all and I'd be happy to help where I can.
> 

This is certainly reassuring for us.

Thanks again,
Paolo

> Thanks.
> 
> -- 
> tejun


--
Paolo Valente                                                 
Algogroup
Dipartimento di Fisica, Informatica e Matematica		
Via Campi, 213/B
41125 Modena - Italy        				  
homepage:  http://algogroup.unimore.it/people/paolo/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/