Announcement

Collapse
No announcement yet.

Yes, Linux Does Bad In Low RAM / Memory Pressure Situations On The Desktop

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

  • #41
    The problem is that the oomkiller sucks at doing what it's supposed to. Kill the browser I'm using when I run out of memory for all I care, just do something rather than wasting 30 minutes constantly moving the binary in and out of memory before the kernel decides to kill something.

    Comment


    • #42
      Originally posted by milkylainen View Post

      While you can tune it, Linux by default does lazy overcommit memory allocation. It will happily give you your malloc:ed pointer while it tries to sort shit out on the actual page faults...
      If it fails it will probably shoot itself to bits or some program it thinks is offending.
      In reality, with normal overcommit behavior, applications have more or less zero chance of resolving a memory pressure situation unless probing the OS for more information.

      Otoh, not overcommiting memory will result in big fat crashes as applications are usually worthless at handling memory pressure situations gracefully.

      Out of memory is a shitty situation whichever way you look at it.
      The big question is if the default heuristic overcommit should land in an "this is bull" conclusion and kill the offending program instead of fragging itself to bits.
      Overcommiting is harmful, and it has done nothing but made things miserable. Because of it's existence you end up with applications such as GHC, which allocate insane amounts of memory at start, and in that case its one tebibyte. There would be no problem if the kernel tried to only allocate what actually available.

      Comment


      • #43
        Originally posted by slavko321 View Post

        If you run out of RAM, the OOM killer should be called immediately. Right now there is a long period of disk trashing even if you have NO swap enabled.

        This is obviously a bug.

        And alt-sysrq-f is a lifesaver
        In my opinion, this is not a bug.
        Evidence. Millions of Android devices, laptops with ChromeOS are fully functional (with Linux kernel). The manufacturer and supplier of the operating system care about this. GNU/Linux distributions no.
        The administrator (you) must correctly configure the system according to your needs.

        Comment


        • #44
          Open a few tabs in a web browser and you crash 4GB of RAM? What kind of crap system does that? I've been using GNU/Linux distros over 20 years, and never seen that behavior. Never been a Ubuntu user - is this a Ubuntu problem? Not a problem on a sane distro like opensuse or Debian.

          Maybe it's a Chrome problem - Chrome on Windows is a memory disaster if I recall correctly. Even after closed it used to keep running 5-6 orphaned processes that would hog as much available memory as possible. Friends should not let friends use Chrome.

          Comment


          • #45
            Originally posted by kpedersen View Post
            In the RHEL4 / Fedora Core 4 days, it was quite common for a laptop to only have 512M of RAM; Fedora Core 4 ran terribly. Then Fedora Core 5's installer didn't even work on 512M, just uncompressing the package data caused it to run out and abort.
            I actually have a PC with 256MB of RAM running Fedora 8 quite acceptably. I think I did have to use the text-based installer though.

            Comment


            • #46
              Originally posted by latalante View Post

              In my opinion, this is not a bug.
              Evidence. Millions of Android devices, laptops with ChromeOS are fully functional (with Linux kernel). The manufacturer and supplier of the operating system care about this. GNU/Linux distributions no.
              The administrator (you) must correctly configure the system according to your needs.
              Android has used a non-mainline LMK (low memory killer) and is now using PSI monitoring for OOM killer heuristics.

              Chrome/ChromiumOS also uses additional tooling to avoid dealing with the mainline OOM detection.

              Comment


              • #47
                Pages get evicted fairly randomly under pressure, so you have things that are actually used sent out to the swap partition only to be brought back and this could happen multiple times. The LRU doesn't have the information needed to intelligently make decisions about this.

                Comment


                • #48
                  Originally posted by dimko View Post

                  Because your machine can not possibly have issues of it's own. Also, swap is not substitute for proper hardware.
                  Please don't bring the Windows mentality of "if it doesn't work well, bring better hardware" to the Linux world.
                  As an example, Linux makes an HDD look fast, while Windows needs an SSD to be fast.

                  Also, please note that this was in 2015 when I only had 8GB RAM in my system. I then upgraded to 16.
                  (This still occurs with my dad's 1GB laptop, however, and we'd love to fix it but sometimes we have fights and not enough money which distances us from the solution)

                  Comment


                  • #49
                    Originally posted by Space Heater View Post

                    Android has used a non-mainline LMK (low memory killer) and is now using PSI monitoring for OOM killer heuristics.

                    Chrome/ChromiumOS also uses additional tooling to avoid dealing with the mainline OOM detection.
                    After all, nothing prevents GNU/Linux distributions from using PSI. I will repeat the default behavior of OOM killer heuristics will not satisfy everyone. Not all of them are firefox and chrome users, they use the system for various applications.

                    Comment


                    • #50
                      IMO linux should do something like that: Have something like zram with a high performance / lower compression algo (lz4?) stand by... when memory starts approaching critical levels, start compressing the ram incrementally to prevent the "huge stall".

                      In terms of dealing with memory offenders, perhaps there should be something like a service that monitors apps that eat up memory aggressively. When it predicts that they will be OOM in the next few miliseconds, kill the offending app.

                      Comment

                      Working...
                      X