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
--
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
