5 ms·

That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.) Linux supports quite a lot of different workloads on quite a lot of

by CrLf 10y ago

That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.) Linux supports quite a lot of different workloads on quite a lot of different hardware. 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. 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.) There have been many instances in the past where "clearly superior" patches ended up having pathological behavior for many workloads. Something that would only be discovered after impacting a lot of users if it weren't for the review processes in place. Some of these were merged anyway (but not made default) while some others didn't prove to provide enough improvement (even in the cases they optimize for) to justify the extra bloat.

forgotpwtomain 10y ago
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. [0] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php http://algo.ing.unimo.it/people/paolo/disk_sched/results.php [1] http://algo.ing.unimo.it/people/paolo/disk_sched/comparison.php http://algo.ing.unimo.it/people/paolo/disk_sched/comparison.... [2] http://algo.ing.unimo.it/people/paolo/disk_sched/description.php http://algo.ing.unimo.it/people/paolo/disk_sched/description... [3] http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techreport.pdf http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techrep... [4] https://lkml.org/lkml/2014/5/30/412 https://lkml.org/lkml/2014/5/30/412

by CrLf 10y ago

forgotpwtomain 10y ago

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. [0] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php http://algo.ing.unimo.it/people/paolo/disk_sched/results.php [1] http://algo.ing.unimo.it/people/paolo/disk_sched/comparison.php http://algo.ing.unimo.it/people/paolo/disk_sched/comparison.... [2] http://algo.ing.unimo.it/people/paolo/disk_sched/description.php http://algo.ing.unimo.it/people/paolo/disk_sched/description... [3] http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techreport.pdf http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techrep... [4] https://lkml.org/lkml/2014/5/30/412 https://lkml.org/lkml/2014/5/30/412