Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Open Source Operating Systems Software Upgrades Linux

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.
This discussion has been archived. No new comments can be posted.

CFQ In Linux Gets BFQ Characteristics

Comments Filter:
  • by cephalien ( 529516 ) <benjaminlungerNO@SPAMgmail.com> on Friday February 05, 2016 @01:55PM (#51447673)

    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)

      by slacka ( 713188 ) on Friday February 05, 2016 @02:06PM (#51447777)

      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.

      • by Anonymous Coward

        [...] some close-minded Slashdot commenter afraid of change.

        New here, are you?

      • by aliquis ( 678370 )

        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.

      • 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)

      by Anonymous Coward on Friday February 05, 2016 @02:12PM (#51447849)

      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.

      • 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).

    • 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.
      • Chain of authorship (Score:4, Interesting)

        by tepples ( 727027 ) <tepples@ g m a i l .com> on Friday February 05, 2016 @02:53PM (#51448259) Homepage Journal

        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)

        by Tough Love ( 215404 ) on Friday February 05, 2016 @03:26PM (#51448585)

        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.

        • by Anonymous Coward

          NOOP is a good scheduler, it proves just focusing on minimizing overhead is often better than trying to manage things.

    • by Anonymous Coward

      "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

      • by Foresto ( 127767 )

        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)

      by Anonymous Coward
      • Re:Why? (Score:4, Interesting)

        by allo ( 1728082 ) on Sunday February 07, 2016 @11:14AM (#51456765)

        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.

    • Enjoy. [unimo.it]

    • 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

  • by Anonymous Coward
    And this is a BFD?
  • WTF title? (Score:5, Insightful)

    by paulpach ( 798828 ) on Friday February 05, 2016 @02:08PM (#51447799)

    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.

  • by gstoddart ( 321705 ) on Friday February 05, 2016 @02:15PM (#51447887) Homepage

    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.

    • by TimSSG ( 1068536 )
      I hope you did all that PDQ. Tim S.

      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.

  • 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!!

  • BFQ is AWESOME... (Score:5, Informative)

    by BrookHarty ( 9119 ) on Friday February 05, 2016 @03:54PM (#51448857) Homepage Journal

    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]

Retirement means that when someone says "Have a nice day", you actually have a shot at it.

Working...