One big difference that I’ve noticed between Windows and Linux is that Windows does a much better job ensuring that the system stays responsive even under heavy load.

For instance, I often need to compile Rust code. Anyone who writes Rust knows that the Rust compiler is very good at using all your cores and all the CPU time it can get its hands on (which is good, you want it to compile as fast as possible after all). But that means that for a time while my Rust code is compiling, I will be maxing out all my CPU cores at 100% usage.

When this happens on Windows, I’ve never really noticed. I can use my web browser or my code editor just fine while the code compiles, so I’ve never really thought about it.

However, on Linux when all my cores reach 100%, I start to notice it. It seems like every window I have open starts to lag and I get stuttering as the programs struggle to get a little bit of CPU that’s left. My web browser starts lagging with whole seconds of no response and my editor behaves the same. Even my KDE Plasma desktop environment starts lagging.

I suppose Windows must be doing something clever to somehow prioritize user-facing GUI applications even in the face of extreme CPU starvation, while Linux doesn’t seem to do a similar thing (or doesn’t do it as well).

Is this an inherent problem of Linux at the moment or can I do something to improve this? I’m on Kubuntu 24.04 if it matters. Also, I don’t believe it is a memory or I/O problem as my memory is sitting at around 60% usage when it happens with 0% swap usage, while my CPU sits at basically 100% on all cores. I’ve also tried disabling swap and it doesn’t seem to make a difference.

EDIT: Tried nice -n +19, still lags my other programs.

EDIT 2: Tried installing the Liquorix kernel, which is supposedly better for this kinda thing. I dunno if it’s placebo but stuff feels a bit snappier now? My mouse feels more responsive. Again, dunno if it’s placebo. But anyways, I tried compiling again and it still lags my other stuff.

  • crispy_kilt@feddit.de
    link
    fedilink
    arrow-up
    24
    arrow-down
    3
    ·
    6 months ago

    nice +5 cargo build

    nice is a program that sets priorities for the CPU scheduler. Default is 0. Goes from -19, which is max prio, to +19 which is min prio.

    This way other programs will get CPU time before cargo/rustc.

      • crispy_kilt@feddit.de
        link
        fedilink
        arrow-up
        3
        ·
        6 months ago

        No. This will wreak havoc. At most at -1 but I’d advise against that. Just spawn the lesser-prioritised programs with a positive value.

          • crispy_kilt@feddit.de
            link
            fedilink
            arrow-up
            5
            ·
            edit-2
            6 months ago

            Critical operating system tasks run at -19. If they don’t get priority it will create all kinds of problems. Audio often runs below 0 as well, at perhaps -2, so music doesn’t stutter under load. Stuff like that.

              • crispy_kilt@feddit.de
                link
                fedilink
                arrow-up
                5
                ·
                6 months ago

                Default is 0. Also, processes inherit the priority of their parent.

                This is another reason why starting the desktop environment as a whole with a different prio won’t work: the compiler is started as a child of the editor or shell which is a child of the DE so it will also have the changed prio.

    • SorteKanin@feddit.dkOP
      link
      fedilink
      arrow-up
      11
      arrow-down
      14
      ·
      6 months ago

      It’s more of a workaround than a solution. I don’t want to have to do this for every intensive program I run. The desktop should just be responsive without any configuration.

      • vxx@lemmy.world
        link
        fedilink
        arrow-up
        14
        arrow-down
        3
        ·
        edit-2
        6 months ago

        You could give your compiler a lower priority instead of upping everything else.

        • SorteKanin@feddit.dkOP
          link
          fedilink
          arrow-up
          5
          arrow-down
          2
          ·
          6 months ago

          I’d still need to lower the priority of my C++ compiler or whatever else intensive stuff I’d be running. I would like a general solution, not a patch just for running my Rust compiler.

          • crispy_kilt@feddit.de
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            6 months ago

            How do you expect the system to know what program is important to you and which isn’t?

            The windows solution is to switch tasks very often and to do a lot of accounting to ensure fair distribution. This results in a small but significant performance degradation. If you want your system to perform worse overall you can achieve this by setting the default process time slice value very low - don’t come back complaining if your builds suddently take 10-20% longer though.

            The correct solution is for you to tell the system what’s important and what is not so it can do what you want properly.

            You might like to configure and use the auto nice deamon: https://and.sourceforge.net/

            • FizzyOrange@programming.dev
              link
              fedilink
              arrow-up
              5
              arrow-down
              1
              ·
              6 months ago

              How do you expect the system to know what program is important to you and which isn’t?

              Hmm

              The windows solution is to switch tasks very often and to do a lot of accounting to ensure fair distribution.

              Sounds like you have a good idea already!

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        6 months ago

        Yes, this is a bad solution. No program should have that privilege, it needs to be an allowlist and not a blocklist.