Announcement

Collapse
No announcement yet.

The Linux Kernel Seeing Backport Progress Finally For The "$1.5 Million Dollar Bug"

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

  • The Linux Kernel Seeing Backport Progress Finally For The "$1.5 Million Dollar Bug"

    Phoronix: The Linux Kernel Seeing Backport Progress Finally For The "$1.5 Million Dollar Bug"

    Several weeks ago we wrote about a kernel fix for Linux 5.4 to address performance issues for highly-threaded Linux software running under CFS quotas. The fix can yield up to a 30x improvement in performance and one company estimated the impact of the bug cost them at least $1.5 million USD in extra resources/hardware. But now it looks like it will soon appear in a Linux 5.3 point release and possible back-ports to earlier kernels...

    http://www.phoronix.com/scan.php?pag...r-CFS-Quota-IN

  • #2
    Wow that's pretty outrageous... $1.5 million dollars is way to much money, and the fact that kernel devs took this long to fix this issue is totally pathetic.

    Comment


    • #3
      Originally posted by r08z View Post
      Wow that's pretty outrageous... $1.5 million dollars is way to much money, and the fact that kernel devs took this long to fix this issue is totally pathetic.
      It's only that high because of the crazy scale of hardware that Indeed uses, where $1.5M really isn't as much as you think. The company is estimated to have revenue in the billions, this is like losing less than a dollar to them.

      In addition, I'm not sure why you think this is pathetic. It's how software works. If Indeed wanted to sponsor the work, then fine. They clearly didn't find it much of a priority hence the amount of time the bug stayed alive. I don't know why you think Linux kernel developers should feel immediately obligated to jump at the problems of any particular company over another.

      Comment


      • #4
        I think it is good that the bug got fixed, no matter what.

        But:
        > Our java applications are particularly hard

        This is where I stopped reading. Nah, seriously, they may have reasons to use Java, Java isn't all bad. But complaining about performance and using Java at the same time sounds a litte contradicting to me.
        Stop TCPA, stupid software patents and corrupt politicians!

        Comment


        • #5
          They have reason's for using java. Your opinions on the subject should end there, and not negatively (as most are pre-disposed to do) impact anything thereafter, as they themselves may well be stuck on java 'for reasons'. Or choose to use it. Do you know? I f you do, your opinion might carry weight if you extrapolated.

          Otherwise....


          i wish it would rain and fill my dam because , if it doesb't, I dont eat.

          Indeed were quoted as saying 'napkin maths'. THAT sgould have sounded bells, and the fact that was even mentioned qshows SOME modicum of honesty. Even if they do use java

          Comment


          • #6
            Originally posted by r08z View Post
            Wow that's pretty outrageous... $1.5 million dollars is way to much money, and the fact that kernel devs took this long to fix this issue is totally pathetic.
            The kernel devs won't get paid nearly as much for fixing this.

            Comment


            • #7
              Originally posted by Adarion View Post
              This is where I stopped reading. Nah, seriously, they may have reasons to use Java, Java isn't all bad. But complaining about performance and using Java at the same time sounds a litte contradicting to me.
              So, they should use Python or Ecmascript instead?

              Comment


              • #8
                Originally posted by Adarion View Post
                This is where I stopped reading. Nah, seriously, they may have reasons to use Java, Java isn't all bad. But complaining about performance and using Java at the same time sounds a litte contradicting to me.
                Java performance issues are mostly latency related. For throughput centered applications it's usually pretty good.

                Comment

                Working...
                X