Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
posted by janrinok on Wednesday June 10 2015, @01:45PM   Printer-friendly
from the Budget-Fair-Queueing-AKA-getting-in-line-at-a-cheap-carnival? dept.

For years the BFQ (Budget Fair Queueing) I/O scheduler has been trying to get in the mainline kernel and it looks like they have an action plan for getting accepted upstream.

BFQ is a proportional-share I/O scheduler that shares a lot of code with the CFQ scheduler. The Completely Fair Queuing (CFQ) scheduler has long been part of the mainline tree but BFQ hasn't been pulled yet even after many revisions and code reviews. Despite that, it is used as a default I/O scheduler on several Linux distributions, such as Manjaro, OpenMandriva, Sabayon, or CyanoGenMod, for some devices.

While it doesn't look like it will be ready for the upcoming Linux 4.2 cycle, it appears BFQ getting accepted is becoming quite close (a Google Groups link).

A direct link to relevant lkml thread is http://lkml.org/lkml/2015/6/5/822.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by HiThere on Wednesday June 10 2015, @06:43PM

    by HiThere (866) Subscriber Badge on Wednesday June 10 2015, @06:43PM (#194625) Journal

    Go tos are a lot less harmful if they are used only sparsely. The "Go to considered harmful" paper was written before constructs like blocks following a test were added to languages.

    Similarly, the rule about single returns (except for failing validity checks) is more important if your functions are long. For something less than around 30 lines long it hardly matters, because you can see the whole thing at once.

    (I haven't checked this particular case, and I do reflexively avoid gotos, but then I also don't use much C any more. I consider unrestricted pointer use as dangerous, or more, than unrestricted "go to" use.)

    IIRC, the paper about "Go to considered harmful" was written about Fortran IV, advocating a more structured approach, subsequently adopted by all languages (except assembler). When I remember the spaghetti code I used to deal with I agree with it completely, but wild pointers are just as bad.

    All that said, sometimes you just need to use the best tool available even if it is dangerous. But if it's dangerous you should strictly limit your use.

    --
    Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by frojack on Wednesday June 10 2015, @08:09PM

    by frojack (1554) on Wednesday June 10 2015, @08:09PM (#194654) Journal

    IIRC, the paper about "Go to considered harmful" was written about Fortran IV,

    As I read it, Dijkstra was using pseudo code to make his point, and I don't believe there was any intentional language reference.

    At the time it was written (1968) the structure of code segments in source code was already starting to get attention because the tools for handling large code collections were primitive at best, and carrying a concept of the structure in one's head was becoming increasingly difficult. As well, the hardware of the day had limitations making rampant branching really inefficient.

    But it didn't matter, as It really affected ALL code regardless of language once you got beyond some very small size of programs.
    As usual, the no GO TO mantra was followed far too religiously, more or less to get people to think about what they were doing.

    The inevitable result was the tongue in cheek recommendation of the COME FROM statement.

    --
    No, you are mistaken. I've always had this sig.