It's been a while since I've looked at the papers or read the discussion surrounding it's inclusion into the mainline (so I apologize if I get some details wrong), but my understanding regarding the first point is two fold:
> That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.)
A) There are is a range of benchmarks which support that conclusion across various hardware and workloads. [0][1]
B) It is my understanding that the current day CFQ is a complicated code-base with various engineering improvements that don't have formal specs or theoretical guarantees, the improvements BFQ brings have theoretical underpinnings [2][3], at the least a spec other than "read the code to understand how and why".
> Looking for the best possible performance while ensuring reliability is a very big task and a very big responsibility not to be taken lightly by stereotyping kernel maintainers as some villains looking to make victims out or poor, well-intentioned, contributors.
It's definitely not my intention to villainize kernel developers (for example Tejun Heo appears to be highly supportive in [4]) - and I don't think Paolo is a victim here; but I do think that both casual and professional users are hurt by the end result.
> Also, arguing that contributors don't have the means to go through a public review process intended to result in better code doesn't really add much credibility to the original code, does it? (Not saying that's the case with BFQ either.)
I mean to the extent that you are talking about ripping out a sub-system for a new one, it's nearly impossible to really talk about having the means. The later is I presume a non-trivial task even for someone with a long track-record of good engineering and maintenance. Paolo is if anything also a very good engineer - but that's not even the case for a lot of academics. I guess from my perspective if an Academic provides you with formalized improvements + benchmarks + working code that's already really, really great, there is very significant reason to have engineers with a long track record of reliability who can review the specs, implement/verify/improve the code to get it up to standards, and to deal the with requirements/politics for making these changes. Again my understanding can be totally off here, I'm not a kernel developer - I am just a user who patches with BFQ (and CK for my personal machine) since given the current process improvements do not seem to be forthcoming.
> That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.)
A) There are is a range of benchmarks which support that conclusion across various hardware and workloads. [0][1]
B) It is my understanding that the current day CFQ is a complicated code-base with various engineering improvements that don't have formal specs or theoretical guarantees, the improvements BFQ brings have theoretical underpinnings [2][3], at the least a spec other than "read the code to understand how and why".
> Looking for the best possible performance while ensuring reliability is a very big task and a very big responsibility not to be taken lightly by stereotyping kernel maintainers as some villains looking to make victims out or poor, well-intentioned, contributors.
It's definitely not my intention to villainize kernel developers (for example Tejun Heo appears to be highly supportive in [4]) - and I don't think Paolo is a victim here; but I do think that both casual and professional users are hurt by the end result.
> Also, arguing that contributors don't have the means to go through a public review process intended to result in better code doesn't really add much credibility to the original code, does it? (Not saying that's the case with BFQ either.)
I mean to the extent that you are talking about ripping out a sub-system for a new one, it's nearly impossible to really talk about having the means. The later is I presume a non-trivial task even for someone with a long track-record of good engineering and maintenance. Paolo is if anything also a very good engineer - but that's not even the case for a lot of academics. I guess from my perspective if an Academic provides you with formalized improvements + benchmarks + working code that's already really, really great, there is very significant reason to have engineers with a long track record of reliability who can review the specs, implement/verify/improve the code to get it up to standards, and to deal the with requirements/politics for making these changes. Again my understanding can be totally off here, I'm not a kernel developer - I am just a user who patches with BFQ (and CK for my personal machine) since given the current process improvements do not seem to be forthcoming.
[0] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php
[1] http://algo.ing.unimo.it/people/paolo/disk_sched/comparison....
[2] http://algo.ing.unimo.it/people/paolo/disk_sched/description...
[3] http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techrep...
[4] https://lkml.org/lkml/2014/5/30/412