Slashdot Mirror

← Back to Stories (view on slashdot.org)

CFQ In Linux Gets BFQ Characteristics

Posted by timothy on from the omfg dept.

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.

12 of 65 comments (clear)

  1. Why? by cephalien · · Score: 2

    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
    1. Re:Why? by slacka · · Score: 3, 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.

    2. Re:Why? by Anonymous Coward · · 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.

    3. Re:Why? by Allasard · · Score: 2

      And why are they going thorough the trouble of removing improvements from CFQ?
      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.

    4. Re:Why? by Anonymous Coward · · Score: 2, Informative

      This video shows the improvement

    5. Re:Why? by Tough+Love · · 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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    6. Re:Why? by evilviper · · Score: 2

      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.

      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 almost completely unresponsive.

      Change your scheduler from CFQ to deadline and your system will spring back to life. I don't specifically know that BFQ does any better, but it couldn't possibly be worse... CFQ is crap.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    7. Re:Why? by allo · · Score: 3, 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.

  2. WTF title? by paulpach · · Score: 4, 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.

  3. LOL ... WTF? by gstoddart · · Score: 4, 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.

    --
    Lost at C:>. Found at C.
  4. Chain of authorship by tepples · · Score: 3, 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.

    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".

  5. BFQ is AWESOME... by BrookHarty · · Score: 5, Informative

    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