Announcement

Collapse
No announcement yet.

Con Kolivas Contemplates Ending Kernel Development, Retiring MuQSS & -ck Patches

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

  • Con Kolivas Contemplates Ending Kernel Development, Retiring MuQSS & -ck Patches

    Phoronix: Con Kolivas Contemplates Ending Kernel Development, Retiring MuQSS & -ck Patches

    Con Kolivas has worked on many patches for the Linux kernel over the past two decades and particularly focused on innovations around desktop performance/interactivity. For over a decade now he's primarily been focused on maintaining his work out-of-tree and not catering to mainline acceptance but now he is thinking of bowing out once more and ending his kernel development effort...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Sad day. I've used the -ck patches for the longest time. I wish you well, Con. Good luck with future endeavors.

    About two months ago I started using linux-pf because I was in a hurry, it had a Zen 2 optimized build, and had Paragon's NTFS3 driver built-in so I could use it to do file syncing between Windows and Linux because I was upgrading HDDs. Just a heads up for Archers in the market for a new kernel...or message perpetually high...he has a list a mile long if you want to use linux-ph.

    Comment


    • #3
      A really good idea Con.

      The kernel developers by turning your efforts down have made it abundantly clear that your open source work and effort are not welcome. There's no need to knock on a closed door. As much as open source sounds enticing as an idea, the reality of is far from stellar and at times it's simply ugly (let's remember all the ego clashes recently, a ffmpeg fork, an open office fork, a gnome fork - some say it's great, I'd say it's a ton of wasted effort and duplication of work). Technically there have been zero reasons not to mainline your code. Thank you for your work. It's been really appreciated. There's still a chance someone will step up and maintain your code, though given its complexity and the complexity of integrating it considering constant deep changes in the kernel I don't think there's much hope.

      Comment


      • #4
        I'm saddened by this, but happy for him as well if he's feeling worn down because of all of the work he has to do to keep up with kernel development, I bet a rest from it is well deserved. It must be crazy the amount of changes there are in that area from release to release, damn...

        I used to use his BFS first and MuQSS later on in the custom kernel for my daily machine, but nowadays things have gotten more complicated because I don't have a single machine I use and need to maintain so I resorted back to either use a kernel that has his patches integrated from the AUR in those running Arch and the stock, or stock-ish kernels in the others.

        I wonder though, how come his work was never mainlined? Did Con ever apply for it and it was rejected for some reason? It's intricate work that probably requires kernel-knowledgeable people to maintain it too, so it's even harder to find people to continue or help with his work.

        Comment


        • #5
          Thanks skeevy420. Hoping to make it less Ubuntu'ish in the future (just no incentive to do so), but arch users can definitely leverage that script. It's the patches that's really the heart of it, and xanmod and lucjan have made it super easy.

          Con had a really good run. Had no idea it was just a hobby for him. Have used his scheduler in the past, but never really got too knee-deep in it.

          CFS by Ingo Molnar is just so good, in my opinion. I think CacULE scheduler has had the best idea so far. Take the already-proven CFS and add to it. So he took a FreeBSD idea (ULE, based on interactivity scores), so that there won't be too many weird edge cases to worry about. It's easy to patch (important), and easy to test/benchmark. Wouldn't be surprised to see it mainlined eventually.

          Comment


          • #6
            Con Colivas must be some kind of genius, he works as anaesthetist and somehow on his free time manages to learn kernel development enough to make something this impressive.
            My profession is a software developer and I have no idea how to code C, how to do kernel development, and I am quite terrible at Git.

            With Intel's upcoming Alder Lake processor which have a heterogeneous architecture consisting of a mix of big and small cores maybe Intel will get involved in the scheduler.
            AMD is likely to follow suite and introducing something similar to Alder Lake so maybe they will get involved.

            Comment


            • #7
              I used ck patches back in the 2.4 and 2.6 days, way before BFS was a thing and I was running single and dual core systems. Happy using the default scheduler now I have beefier machines, I even think his patches made it into some custom android kernels on some of my nexus phones

              KaoDome I'm pretty sure that BFS was created after CK's last upstreaming attempt failed and renamed to MuQuss after it was subsequently redesigned to deal with ever growing number of cores in peoples machines

              Con your work was appreciated back in the day, if you do decide to down tools I hope you enjoy your next endeavour more

              Comment


              • #8
                there is only so far you can go on your own, maintaining your kernel patches. it's a lot of work, and likely a toll on your mental health.

                I am surprised that bfq developer made it until the final merge. but at least he intended to have the code merged.

                Comment


                • #9
                  Ah this is sad, but I understand where he's coming from, the QC of kernel releases seems to be getting worse and worse and worse with every passing release.

                  Kernel is just not as solid as it used to be and we've all been feeling the effects of it I imagine.

                  I really liked CK's schedulers, they were popular for a reason, and I wonder why they were never accepted into the mainline kernel. In a project as demanding as this passion is a critical part of getting it right, if the man has lost his passion for it, letting go is the most sensible choice for him to make, I agree.

                  I hope whatever he decides to do instead with his free time now will be fulfilling for him.

                  Comment


                  • #10
                    Originally posted by avem View Post
                    Technically there have been zero reasons not to mainline your code.
                    And you know this because...?
                    Are you a contributor to the Linux kernel process scheduler? Or at least very familiar with the current codebase on a technical level? Just curious.


                    Comment

                    Working...
                    X