CFQ In Linux Gets BFQ Characteristics 65
jones_supa writes: Paolo Valente from University of Modena has submitted a Linux kernel patchset which replaces CFQ (Completely Fair Queueing) I/O scheduler with the last version of BFQ (Budget Fair Queuing, a proportional-share scheduler). This patchset first brings CFQ back to its state at the time when BFQ was forked from CFQ. Paolo explains: "Basically, this reduces CFQ to its engine, by removing every heuristic and improvement that has nothing to do with any heuristic or improvement in BFQ, and every heuristic and improvement whose goal is achieved in a different way in BFQ. Then, the second part of the patchset starts by replacing CFQ's engine with BFQ's engine, and goes on by adding current BFQ improvements and extra heuristics." He provides a link to the thread in which it is agreed on this idea, and a direct link to the e-mail describing the steps.
Re: (Score:1)
Only with "DFQ?"
In other news Batman Arkham Knight _won't_ be ported to Linux.
Why? (Score:3)
Sorry, but I just don't understand what the purpose is, and it isn't stated in the thread linked -- other than a few ... (maybe) benchmarks that don't cover many real-world use cases.
Re:Why? (Score:4, Insightful)
I just don't understand what the purpose is, and it isn't stated in the thread linked -- other than a few ... (maybe) benchmarks that don't cover many real-world use cases.
How can you complain that you don't have any benchmarks to judge it by and then claim that if those benchmarks existed they do not cover real-world use cases? If your claim is true, this sounds unnecessary. But my gut trusts the kernel devs more than some close-minded Slashdot commenter afraid of change.
Re: (Score:1)
[...] some close-minded Slashdot commenter afraid of change.
New here, are you?
Re: (Score:1)
why is that a problem? are you claiming that we already found the 'one-true-algorithm' for doing this, and that it's impossible to do any better, and these guys are just screwing around with the code because they have commit rights?
Actually, if anything, it's possible that making it a configuration option would be useful, as computers used for specific tasks, one algorithm would work better than others. Or you would just build the distribution to use that algorithm.
Re: (Score:1)
But my gut trusts the kernel devs more than some close-minded Slashdot commenter afraid of change.
Just call him racist and be done with it.
Re: (Score:1)
Probably is an active ISIS combatant.
Re: (Score:2)
I don't think he is complaining about benchmarks but about not being able to derive the point from the article or the benchmarks.
I too suffer the same ignorance as i wasn't aware that there was an issue needing fixed or why this fix seems to be address it. Anyone have a idiots guide to the back story on this?
Re:Why? (Score:5, Informative)
Scheduling is an area many people don't really understand, as it is mostly behind the scenes.
It's also a very debated topic, as the optimal scheduling configuration often depends on what exactly a given machine is doing.
A server, for instance, may have many more processes running than a desktop, but they are largely the same type of processes. For this, a completely 'fair' type of scheduler may be the best choice.
A desktop however might be running far less processes at once, but they are vastly different. A mix of background processes and real-time applications, who's timing requirements vary between processes and possibly within a process at different times or situations. For this, a more heuristic based scheduler might be more appropriate, providing an overall 'more responsive' feeling experience.
Re: (Score:2)
Thank you; that's what I meant by 'I don't understand', not some sort of half-arsed attack against the 'trusted linux developers' (whoever decides that particular subset, anyway).
Re: (Score:2)
There is already a choice of schedulers in the kernel. Why not just make an addition one named BFQ?
That seems much safer than mucking with the current default scheduler and potentially breaking performance for a type of workload.
Chain of authorship (Score:4, Interesting)
And why are they going thorough the trouble of removing improvements from CFQ?
My guess is to establish a chain of authorship, so that that those things that BFQ shares with CFQ can be correctly attributed to the author of CFQ. Chain of authorship is very important to the Linux project. It dates back to the SCO lawsuit, which ends up being why Git has the --signoff option [stackoverflow.com].
Why not just make an addition one named BFQ?
That might be the ultimate plan: duplicate CFQ, producing a second scheduler identical to CFQ, then apply the heuristic removal patch and the BFQ patch to "Copy of CFQ".
Re:Why? (Score:5, Informative)
And why are they going thorough the trouble of removing improvements from CFQ?
CFQ was never very good, Lots of quirky behaviour, often being worse than the NOOP scheduler and sometimes stuffing up completely. This is a nice polite way of taking it out behind the barn and shooting it. The new one turns in massive improvements in read latency, respectable improvement in other loads, and little to no regression on any load, besides being thought through and 1,000,000 times better documented than the old steaming pile.
Re: Why? (Score:1)
NOOP is a good scheduler, it proves just focusing on minimizing overhead is often better than trying to manage things.
Re: (Score:1)
"Low latency for interactive applications
According to our results, regardless of the actual background
workload, for interactive tasks the storage device is virtually as
responsive as if it was idle. For example, even if one or more of the
following background workloads are being executed:
- one or more large files are being read or written,
- a tree of source files is being compiled,
- one or more virtual machines are performing I/O,
- a software update is in progress,
- indexing daemons are scanning filesystems a
Re: (Score:2)
Thank goodness. It's embarrassing how long my desktop machines have had the habit of looking completely locked up whenever they're asked to copy a large file in the background. It's especially bad when a slow-ish NAS server is involved. I've tried the existing optional IO schedulers, and they don't fix the problem.
Re: (Score:2, Informative)
This video shows the improvement [youtu.be]
Re:Why? (Score:4, Interesting)
Sorry, but what it shows is that gnome terminal sucks.
I know it's slow. And the startup time is not the biggest problem. It has tabs, if you want to.
But let some text scroll fastly there and look at the cpu usage.
Then use urxvt and compare startup time (instant) and text scrolling (almost no additional cpu, the program producing the text dominates).
Thats the reason against gnome-terminal. When a low cpu program occupies a whole cpu core, because the terminal drawing the output sucks, youre doing it wrong.
Re: (Score:2)
Enjoy. [unimo.it]
Re: (Score:3)
With CFQ, an high disk-IO task will block every other process on the system from getting any time. This can be a big file cp, but I see it most often when writing to slow USB thumb drives... Queue up a copy/rsync/etc. of a few GBytes of data to a slow thumb drive, and after your RAM/buffer cache is filled, your system will be
CFQ gets BFQy (Score:1)
WTF title? (Score:5, Insightful)
The title says: "CFQ In Linux Gets BFQ Characteristics"
CFQ is not getting BFQ characteristics, it is simply being replaced by BFQ in this patchset, in several steps.
This is nothing new, BFQ has been proposed for the kernel before.
LOL ... WTF? (Score:5, Funny)
Yeah, well I'm taking my AFQ, combining it with my DFQ, and I'm going to EFQ the FFQ out of here.
Take that.
Re: (Score:1)
Yeah, well I'm taking my AFQ, combining it with my DFQ, and I'm going to EFQ the FFQ out of here.
Take that.
Re: (Score:2)
Use of heuristics (Score:2)
Is that admission that original algorithm does not work (in some cases) ?
Re: (Score:2)
Pretty much.
PDQ and ASAP (Score:2)
Stupendous! Get the ECN on this sent PDQ so the IUB can patch the IRQ DMOB and regain the benefits of CSR ASAP!!
BFQ is AWESOME... (Score:5, Informative)
Been running PF-Kernel [natalenko.name] for a few years, which has a bunch of patches, including BFQ, ck patch set with BFS, Tux in ice, UKSM, and grayskys gcc kernel patch. I normally just use the PF Github repo [github.com]
Love it. With BFQ, you no longer get system pauses on your desktop. I can listen to music or play a video, run a few vms, while a compiler runs in the background, and x-windows doesn't pause, typing doesn't pause, its how a system should act. Your system seems more fluid with no pausing.
PF-Kernel seems to be for Arch/Gentoo/Rpm based, but I've used it on Ubuntu systems. Pf-Kernel isn't the only one, there are other kernels out there that include more performance patches, Xanmod [xanmod.org] and Liquorix [liquorix.net]
Re: (Score:2)
mobile != desktop workload.