Announcement

Collapse
No announcement yet.

MGLRU Patches Merged To "mm-stable" Ahead Of Linux 6.1 - New Benchmarks Look Good

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

  • #11
    If this gets taken for 6.1, is it unlikely to get backported to 6.0?

    Comment


    • #12
      Originally posted by kozman View Post
      If this gets taken for 6.1, is it unlikely to get backported to 6.0?
      Big changes usually don't get backported to stable kernels, so very unlikely.

      Comment


      • #13
        Originally posted by sinepgib View Post

        Big changes usually don't get backported to stable kernels, so very unlikely.
        That's too bad but understandable. Those before/after perf numbers sure make a great case though.

        Comment


        • #14
          Originally posted by kozman View Post

          That's too bad but understandable. Those before/after perf numbers sure make a great case though.
          It would be great to backport. A part of the appeal to older kernels is that they have a process of minimizing changes except those that fix regressions, security, or large issues. This is how you minimize risk.

          MGLRU is more of a major performance enhancement than a fix, so even if it would be amazing for older kernels, their priority is to minimize changes unless strictly necessary and they accept that older kernels are often behind in performance compared to the newest kernels.
          Last edited by Mitch; 27 September 2022, 04:50 PM.

          Comment


          • #15
            Originally posted by sinepgib View Post
            But you don't get to choose. Nobody uses it by choice, but by imposition by their employers.
            True, but my employer also mandates Windows. I will not bastardize my home Linux install like that.

            Originally posted by sinepgib View Post
            For what matters here they are both the same thing. The spyware telemetry is not the main source of bloat there.
            It would be, if it was my primary browser. It isn't, Firefox is.

            Originally posted by sinepgib View Post
            While nobody says it's your particular case (and being fair, you were talking about your own workstation and nobody else's), take into account there's not much artificiality in the example, except maybe for the php stuff. A lot of people, possibly a majority, deal with those programs due to their employers' policies.
            That is correct. My comment wasn't specifically about the scenario you described, but more aimed at people thinking how would they bloat RAM usage, just to see MGLRU in action.

            Comment


            • #16
              Originally posted by kozman View Post
              If this gets taken for 6.1, is it unlikely to get backported to 6.0?
              The xanmod kernel has mglru already, if you want to try it. They will likely provide a patched 6.0 kernel too.

              Comment


              • #17
                Feel free to cherry pick from my repo in case you want to build your own kernels: https://github.com/yuzhaogoogle/linux/ mglru-6.0 (or mglru-5.19 or mglru-5.18).​

                Comment


                • #18
                  Originally posted by [email protected] View Post
                  Feel free to cherry pick from my repo in case you want to build your own kernels: https://github.com/yuzhaogoogle/linux/ mglru-6.0 (or mglru-5.19 or mglru-5.18).​
                  I'm on Archlinux using linux-mainline kernel with mglru 6.0 patches applied. My system has 32 threads and 32G of RAM; no file or swap partition is used, just a 6G ZRAM ZSTD device acting as swap. I tried to compile Firefox entirely on RAM using Archlinux PKGBUILD and my system crashed hard 4 of 6 times after a few minutes. Only in 2 of the 6 attempts systemd oomd service had time to kill the process that was choking my machine. On four occasions my system became totally unrecoverable forcing me into a hard reboot. I don't know if MGRLU is, or could be, helpful in these situations. Increasing ZRAM size from 6 to 16G could be helpful?

                  Comment


                  • #19
                    Originally posted by HD7950 View Post

                    I'm on Archlinux using linux-mainline kernel with mglru 6.0 patches applied. My system has 32 threads and 32G of RAM; no file or swap partition is used, just a 6G ZRAM ZSTD device acting as swap. I tried to compile Firefox entirely on RAM using Archlinux PKGBUILD and my system crashed hard 4 of 6 times after a few minutes. Only in 2 of the 6 attempts systemd oomd service had time to kill the process that was choking my machine. On four occasions my system became totally unrecoverable forcing me into a hard reboot. I don't know if MGRLU is, or could be, helpful in these situations. Increasing ZRAM size from 6 to 16G could be helpful?
                    Have you successfully compiled Firefox with 32GB RAM and 6GB ZRAM before? From my experience, this configuration should be enough to complete the compilation with or without MGLRU.

                    Was MGLRU on or off? Toggle it and see if it makes any difference: echo [y/n] >/sys/kernel/mm/lru_gen/enabled.

                    And try increasing ZRAM size from 6 to 16G as well please.

                    Comment


                    • #20
                      Originally posted by [email protected] View Post

                      Have you successfully compiled Firefox with 32GB RAM and 6GB ZRAM before? From my experience, this configuration should be enough to complete the compilation with or without MGLRU.

                      Was MGLRU on or off? Toggle it and see if it makes any difference: echo [y/n] >/sys/kernel/mm/lru_gen/enabled.

                      And try increasing ZRAM size from 6 to 16G as well please.
                      No, never tried before. This was an attempt to experiment with ZRAM & MGLRU and check if hard reboots could finally be avoided on Linux. As i said before, Firefox tarball and related files were uncompressed on RAM too, so it was a hardcore test to pass considering that my CPU has 32 threads.

                      Of course, MGLRU was enabled.

                      I increased ZRAM size to 16G with no success. My system crashed hard, twice. At some point, ld.lld​ process starts to consume large amounts of memory and systemd-oomd can´t kill it in time in most cases.

                      If more memory is needed to finish the compilation, MGLRU cannot do much more than it already does. Miracles do not exist. Maybe I should look for other alternatives than systemd-oomd to do their job better.​

                      Comment

                      Working...
                      X