Announcement

Collapse
No announcement yet.

BFQ Is One Step Closer To Being Merged Into The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by uid313 View Post
    BFQ vs CFQ?
    Which is better? Which is better for what? Which is better under what conditions?
    How do they differ?
    How do they conceptually work?

    Basically:
    Better for maximum bandwidth: CFQ
    Better for minimum latency: BFQ

    Pick whichever one your system needs more: High Bandwidth, or Low Latency.

    Comment


    • #12
      Originally posted by gamerk2 View Post


      Basically:
      Better for maximum bandwidth: CFQ
      Better for minimum latency: BFQ

      Pick whichever one your system needs more: High Bandwidth, or Low Latency.
      If you check the benchmarks there is almost no throughput differences between CFQ and BFQ, so this isn't really true.

      Comment


      • #13
        BFQ is one of the biggest pieces of shit/snake oil out here today. BFQ has no speed or latency benefits over CFQ or Deadline. BFQ is just the work of script kiddies trying to make a name for themselves.

        Comment


        • #14
          Originally posted by Rallos Zek View Post
          BFQ is one of the biggest pieces of shit/snake oil out here today. BFQ has no speed or latency benefits over CFQ or Deadline. BFQ is just the work of script kiddies trying to make a name for themselves.
          Just in your opinion. Please link some tests/benchmarks to prove it as we did before.

          Comment


          • #15
            It's hard to benchmark what most people care about (responsiveness)--most benchmarks test only raw performance, not how quickly each individual task is completed. Yes, there is a difference.

            Comment


            • #16
              Originally posted by Nobu View Post
              It's hard to benchmark what most people care about (responsiveness)--most benchmarks test only raw performance, not how quickly each individual task is completed. Yes, there is a difference.
              The two are still related. Same thing goes for horsepower and torque. While one is considered more 'responsive' they are both related to each other.

              Regardless, I don't see any signs that this would show issues with responsiveness.

              Comment


              • #17
                Originally posted by jwilliams View Post
                Unfortunately, no. Steps 2 and 3 basically amount to the BFQ developers coming up with a patch set to turn CFQ into BFQ, and this is a big job. Jens Axboe has unreasonably stated that BFQ will never be accepted as an alternate I/O scheduler in the linux kernel. His demand is that BFQ replace CFQ, even though the two schedulers are quite different. The reasonable thing to do would be to accept BFQ as an additional I/O scheduler, and then as people use it and it continues to be developed, if it obsoletes CFQ then CFQ could be removed at a later date. It makes no sense to force BFQ to replace CFQ from the start, when linux already has an architecture that supports multiple I/O schedulers.
                AIUI, the real issue is that the CFQ codebase is a mess. BFQ worked around that by doing a clean implementation, but the underlying theory is loosely based on CFQ. The kernel maintainers have notoriously high (and arguably justified) standards for code quality, and think that since CFQ and BFQ are so similar, they should use as much of the same code as possible (which could potentially reduce BFQ to some new settings and default values for CFQ). Basically, they've made the refactoring of CFQ a pre-requisite for the merge.

                As an aside, I've been using BFQ for a while (it's the default scheduler in Sabayon), and it seems to work quite well.

                Comment


                • #18
                  Originally posted by rdnetto View Post

                  AIUI, the real issue is that the CFQ codebase is a mess. BFQ worked around that by doing a clean implementation, but the underlying theory is loosely based on CFQ. The kernel maintainers have notoriously high (and arguably justified) standards for code quality, and think that since CFQ and BFQ are so similar, they should use as much of the same code as possible (which could potentially reduce BFQ to some new settings and default values for CFQ). Basically, they've made the refactoring of CFQ a pre-requisite for the merge.
                  Which is unreasonable. Why should the BFQ developers be penalized and forced to work with the messy CFQ codebase? It makes no sense. They have already spent years developing BFQ. They should not be forced to now clean up CFQ.

                  Comment


                  • #19
                    Has anyone ever benchmarked BFQ alone (without other patchsets, bfs, etc.) on a desktop, for everyday tasks (multimedia, archiving, compiling...) ?

                    Comment

                    Working...
                    X