[...] > >> 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! > 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. You have not given him any credibility for his work in BFQ and now you point him yet in another direction. I understand Paolo is a very persistent hard working guy, most likely because he is really confident about his work in BFQ and he should be! But, regarding motivation, if you continue to push him in different directions and without giving him any credibility - then at some point, you probably knows what will happen. > > The path forward is clear. It'd be a lot better to put some work behind > that, rather than continue this email thread. Yes, it seems so! Kind regards Ulf Hansson -- 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
