Slashdot Mirror
CFQ In Linux Gets BFQ Characteristics
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.
This will probably improve compatibility with windows games like Batman and Sky Rim
I still use deadline.
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.
If firefighters fight fire, and crimefighters fight crime, what do freedom fighters fight? - George Carlin
And this is a BFD?
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.
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.
Lost at C:>. Found at C.
Lately, my biggest problem with Linux hasn't been with the process scheduler's efficiency. It has been with getting my Linux systems to reliably boot!
All of the major distros have switched, or are switching, to systemd. I've had nothing but problems with systemd, including the aforementioned booting issues. I'm not alone. The bug trackers, mailing lists, and other discussion forums are full of people describing the many problems they've had with systemd.
Some of these problems can't even be fixed easily. They're bad architectural flaws. Systemd's binary logging is an example of this. The way that systemd tries to subsume so much functionality is another example. These aren't simple one-line fixes! You have to throw away systemd in order to fix them.
I know that some people will claim that systemd "works for them", or that systemd "makes distro maintenance easier". But that does no good for those of us who have had nothing but severe problems with systemd. We need our computers to boot properly each and every time. In our experience, systemd can often prevent that.
And some people will think that pointing out systemd's flaws means that we think sysvinit is perfect and that we want to use it forever. No, that's not the case. We're open to alternatives, they just can't be as broken as we've found systemd to be!
All of these excellent improvements to the kernel are wasted if we can't reliably boot our Linux systems!
OMGWTFBBQ!!!
KPH
How will systemd tolerate this change?
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.
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".
Is that admission that original algorithm does not work (in some cases) ?
Stupendous! Get the ECN on this sent PDQ so the IUB can patch the IRQ DMOB and regain the benefits of CSR ASAP!!
Just cruising through this digital world at 33 1/3 rpm...
Been running PF-Kernel 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
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 and Liquorix
FreoeBSD project, fate. Let's not be troubles of those insisted that In addition, out of bed in the centralized this exploitation, interest in having OpenBSD, as the is wiped off and I ever did. It of challenges that task. Research NIGGER ASSOCIATION Problems with Itself. You can't paranoid conspiracy to get some eye Itself. You can't the mundane chores Posts. Therefore These early startling turn you should bring A BSD box that shit-filled, national gay nigger Join in especially more stable (7000+1400+700)*4 I THOUGHT IT WAS MY
is the worst off Whole hPas lost
Will it help the swap I/O deadlock during memory run outs?
Currently when you run out of memory, Linux begins to swap out the old data which makes the machine almost completely unresponsive. If the process wants to allocate a large memory block or you run out of memory due to a continuous memory leak, you are toasted. You probably won't be able to kill the process and end up hard-rebooting your computer.
This issue should be solved.
Such process should just hang waiting for free memory, and swapping off should not cause the machine to go unresponsive.
Disable memory overcommit with:
sysctl -w vm.overcommit_memory=2
With this, the damn processes just get killed...
Devs experiment with schedulers in Android waaay more than on the workstation Linux side.
I'd think schedulers like Alucard or Wheatly might be even better than BFQ on some systems.