On Fri 2014-05-30 19:28:04, Tejun Heo wrote:

Hello,

On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:

quoted

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.  For example, AFAICS, most of the heuristics added by

Would it make sense to merge bfq first, _then_ turn cfq into bfq, then
remove bfq?

That way

1. Users like me would see improvements soon 

2. BFQ would get more testing early. 

3. If there are some problems in some workload, switching between bfq
and cfq will be easier than playing with git/patches.

Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
are worth it?

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html