Announcement

Collapse
No announcement yet.

Linux Scheduler Build Improvements From "Fast Kernel Headers" Queued, FKH v3 Posted

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

  • Linux Scheduler Build Improvements From "Fast Kernel Headers" Queued, FKH v3 Posted

    Phoronix: Linux Scheduler Build Improvements From "Fast Kernel Headers" Queued, FKH v3 Posted

    Published at the start of the new year was 2.3k patches providing "fast kernel headers" as a major speed-up to Linux kernel build times and addressing the dependency hell among all the header files in the Linux kernel source tree. It will likely take some time for that massive patch series to work its way to mainline in full, but at least for Linux 5.18 already the patches touching the kernel's scheduler area are ready to land...

    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
    And here I thought FKH was a mistype of GKH

    Comment


    • #3
      This patch set makes the kernel look like a tiny toy project. Shouldn't the kernel be one of the largest code bases that should take hours to compile? It's also harder to justify 128 core monster servers for building the kernel if it produces 60% less load.

      edit: btw there's a new Threadripper 5995WX now available for ESR. Does anyone know if it has enough cores, support for RAM and NMVe lanes to run repo surgeon?
      Last edited by caligula; 15 March 2022, 02:06 PM.

      Comment


      • #4
        modules would be cool. i mean honestly, this system of text preprocessing is so barbaric no matter how nice you try to make it. they are supposedly bringing modules to c++, i wonder if they would ever bring it to c? c itself is so barbaric too though. jfc can we just kill it with fire already and evolve to better things?

        Comment


        • #5
          Originally posted by atomsymbol

          In my opinion, this looks like a step towards programmers-to-serve-machines, instead of machines-helping-programmers-to-solve-problems. I haven't investigated the patches closely, so I might be wrong about this. But taking a look at, for example, https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/diff/include/linux/llist_api.h brings about questions.
          The whole process of using pre-processor directives for building a dep graph is broken by design. It can't be fixed in other ways.

          Comment


          • #6
            Originally posted by caligula View Post
            This patch set makes the kernel look like a tiny toy project. Shouldn't the kernel be one of the largest code bases that should take hours to compile?
            Not everyone can afford the be a fat walrus like chrome. xkcd.com/303 , for all the fun it embodies, carries a serious message. Manhours want to be paid.

            Comment


            • #7
              Originally posted by quaz0r View Post
              c itself is so barbaric too though. jfc can we just kill it with fire already and evolve to better things?
              Good luck rewriting those millions of lines of code. Don't get me wrong, I'm a big fan of moving to new, type- and memory-safe languages (ahem R*** ahem), but you can't simply kill C, not at least overnight. I pretty much like the approach some people are attempting that is adding optional support for Rust instead.

              Comment


              • #8
                is this hitting linux-next anytime soon ?

                Comment

                Working...
                X