Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[Jens Axboe]

On 10/28/2016 12:36 AM, Ulf Hansson wrote:
> [...]
>
> > > Moreover, I am still trying to understand what's the big deal to why
> > > you say no to BFQ as a legacy scheduler. Ideally it shouldn't cause
> > > you any maintenance burden and it doesn't make the removal of the
> > > legacy blk layer any more difficult, right?
> >
> >
> > Not sure I can state it much clearer. It's a new scheduler, and a
> > complicated one at that. It WILL carry a maintenance burden. And I'm
>
> Really? Either you maintain the code or not. And if Paolo would do it,
> then your are off the hook!

Are you trying to be deliberately obtuse? If so, good job. I'd advise 
you to look into how code in the kernel is maintained in general. A 
maintenance burden exists for code A, but it also carries over to the 
subsystem it is under, and the kernel in general. Adding code is never free.

> > really not that interested in adding such a burden for something that
> > will be defunct as soon as the single queue blk-mq version is done.
> > Additionally, if we put BFQ in right now, the motivation to do the real
> > work will be gone.
>
> You have been pushing Paolo in different directions throughout the
> years with his work in BFQ, wasting lots of his time/effort.

I have not. Various entities have advised Paolo approach it in various 
ways. We've had blk-mq for 3 years now, my position should have been 
pretty clear on that.

> You have not given him any credibility for his work in BFQ and now you
> point him yet in another direction.

I don't even know what that means. But I'm not pointing him in a new 
direction.

Ulf, I'm done discussing with you. I've made my position clear, yet you 
continue to beat on a dead horse. As far as I'm concerned, there's 
nothing further to discuss here. I'll be happy to discuss when there's 
some meat on the bone (ie code). Until then, EOD.

--
Jens Axboe