BFQ I/O Scheduler Patches Revised, Aiming To Be Extra Scheduler In The Kernel

[johnp117]

at last, BFQ may be about to land into mainline

[cj.wijtmans]

That does not apply to this situation. The linux kernel has had a modular architecture for IO schedulers for years. Adding BFQ as another optional IO scheduler -- which a good project manager would have done years ago shortly after the BFQ patches were submitted -- does not affect overall kernel stability or any business critical applications. BFQ was repeatedly denied and jerked around for no good reason.

business critical: use LTS version of whatever software. no problem with merging BFQ even if it could make problems it wont affect business at all.

[jwilliams]

i think that is because linux is pretty much business critical at this point. even if businesses are rather conservative with upgrades.

also, if one would be so inclined they might just roll their own linux repository. which, thanks to the nature of git is exactly what many people do. people follow linus partly for traditional reasons, partly for him being the last line of sanity when something dubious gets past the maintainers.

you can definitely do so in smaller projects where things are easier to test, and impact is less critical. i managed to get a couple of things patched in fusioninventory, for instance.

That does not apply to this situation. The linux kernel has had a modular architecture for IO schedulers for years. Adding BFQ as another optional IO scheduler -- which a good project manager would have done years ago shortly after the BFQ patches were submitted -- does not affect overall kernel stability or any business critical applications. BFQ was repeatedly denied and jerked around for no good reason.

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

It's you that spreads stupid propaganda. Let's say you're a maintainer of some project. If someone sends you a patch will you accept or reject it? It's up to you. If you reject he can always fork your project. I don't know who told you kernel maintainers are obligated to accept every piece of code somebody sends to them. Don't listen to stupid people. It's my advise for you. Linus and Co. shape Linux the way they want not the way you want. Summing up your objections against Open Source don't hold, naive one.

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

Bla, bla, bla. In Open Source you can always fork which is impossible with closed source crap. Bla, bla, bla.

[starshipeleven]

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

Fun fact: In closed source it is far worse.

[yoshi314]

Yeah, it's a pretty common situation for me, if you're a "nobody" and you have a patch with serious functionality - you have to wage a long time demoralizing uphill battle that in 90% of cases is not worth unless you're paid.

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

i think that is because linux is pretty much business critical at this point. even if businesses are rather conservative with upgrades.

also, if one would be so inclined they might just roll their own linux repository. which, thanks to the nature of git is exactly what many people do. people follow linus partly for traditional reasons, partly for him being the last line of sanity when something dubious gets past the maintainers.

you can definitely do so in smaller projects where things are easier to test, and impact is less critical. i managed to get a couple of things patched in fusioninventory, for instance.

[cl333r]

We could have had BFQ years ago, if every submission wasn't hit with the latest arbitrary wishlist. Never mind that it's demonstrably better than CFS in every metric, that it's more maintainable, that the code already exists...

It needs to replace CFQ. It needs to be patched from CFQ. Patching from CFQ is too confusing. The fundamental concept is wrong, if you ignore the real behaviour. Now, having been bikeshedded continuously for years, it's behind on the latest churn.

Yeah, it's a pretty common situation for me, if you're a "nobody" and you have a patch with serious functionality - you have to wage a long time demoralizing uphill battle that in 90% of cases is not worth unless you're paid.

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

[liam]

Yay, back to the moving goalposts!

"We could have had BFQ for mq NOW, if we didn't keep coming back to this very point."

We could have had BFQ years ago, if every submission wasn't hit with the latest arbitrary wishlist. Never mind that it's demonstrably better than CFS in every metric, that it's more maintainable, that the code already exists...

It needs to replace CFQ. It needs to be patched from CFQ. Patching from CFQ is too confusing. The fundamental concept is wrong, if you ignore the real behaviour. Now, having been bikeshedded continuously for years, it's behind on the latest churn.

BFQ doesn't have to be better than any I/O scheduler in the kernel, or planned to be in the kernel, it has to be better than any of the hypothetical alternatives that get invented on the spot whenever the (real, usable-right-now) patches show up.

A long running issue with the kernel has been the difficulty with getting certain features included.
I've been looking into the history of linux aio and you just wouldn't believe how many attempts have been made (and by no means do all of them add new syscalls). Seriously, take a look for yourselves (and consider how many changes the kernel has incorporated since ~2000 b/c of not properly implementing asynchronous behavior---a hint is that two of them have to do with epoll).
I've felt really bad for Paolo b/c of how little attention his patches have gotten. He's done everything asked of him. Yet, the number of times he's submitted bfq pales next to the attempts to get kevent (at least 20 and it never happened), let alone devfs (more than 150, iirc...and then it was removed a few years later---so, we know the process doesn't even guarantee that the solution is any good).
This is a very broken aspect to kernel development.
It's almost as though there needs to be a...I don't know...PROSPECTIVE branch that you have to go through before submitting to linus' branch.

[geearf]

Jens Axboe and Christoph Hellwig are terrible managers. They may be good programmers, but they are not doing a good job managing their part of the linux kernel project. They have tunnel vision, only seeing what they are currently concentrating on, and not wanting to divert any of their time or effort to anything else, even when a developer comes forward with ready-made useful code that many linux users want.

Well if they're right that was mq needs to support BFQ is weeks worth of effort, it may not be so bad.
If it's years now...