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

  • #91
    Originally posted by k1e0x View Post

    They don't know what they are talking about. A FreeBSD desktop does NOT suffer this problem. I was recently running 4GB of ram on a desktop and what would happen is the oom killer would just crash random programs. You can also tell it what programs you never want to kill so you can kill the query script killing a box but not the database for instance. The sluggish stuff is a Lunix only problem. Maybe they can look to see how BSD does it for guidence in how to do it right. Lol
    It does crap out and crash, FreeBSD is crap compared to Linux in low memory situations

    Comment


    • #92
      Why not use the excellent earlyoom project? It's a user-space highly configurable memory killer designed for the desktop use-case.
      I've tested it and it's good.

      meanwhile I run raspbian on a Pi 0 with 0.5GB ram, GUI & chrome and it shows little problems: it's on 24x7 (it shows constantly updating bus arrival and departure times for the stop nearest our house, via a web server and Chrome ... you can do that in 0.5 GB. 32 bit kernel is better maybe?
      Last edited by timrichardson; 08-07-2019, 08:00 AM.

      Comment


      • #93
        Originally posted by Rallos Zek View Post

        It does crap out and crash, FreeBSD is crap compared to Linux in low memory situations
        Mmmm well apparently not as bad as Linux. haha.

        But no actually I don't have that machine anymore. (thank god 4gigs?) but what would happen on FreeBSD 12 is (usually) either gnome or chrome would just vanish, the mouse wouldn't even stutter.. the app was just gone. I was left going.. "what where did it go...? ooooh right.. oom killer".. need to keep fewer tabs open. If gnome-shell died it would relaunch or gdm would pop up. Occasionally it would kill something important tho.. so ymmv it's not a good situation in any case.
        Last edited by k1e0x; 08-07-2019, 03:14 AM.

        Comment


        • #94
          Originally posted by timrichardson View Post
          Why not use the excellent earlyoom project? It's a user-space highly configurable memory killer designed for the desktop use-case.
          I've tested it and it's good.

          meanwhile I run raspbian on a Pi 0 with 0.5gb ram, GUI & chrChrom and it shows little problems. 32 bit kernel is better maybe?
          I've just installed it ;-)

          The issue we are arguing about is that (some of) its functionality must be built into the kernel itself to avoid complete stalls for up to hours.

          Comment


          • #95
            Originally posted by msotirov
            Mobile OSes don't behave this way.
            They also mostly only run a single application at a time

            Comment


            • #96
              Originally posted by F.Ultra View Post

              They also mostly only run a single application at a time
              Yes and isn't every application designed to gracefully exit at any time? This is not a viable model for server applications and scientific computing.

              Comment


              • #97
                Originally posted by CuriousTommy View Post

                I think [email protected] and elatllat are on to something. There should be a signal that tells the application to release some of its memory when the system is low on memory. The application knows what it needs to have on memory and what it can get rid of.
                The number of applications that could actually do some housecleaning in a low mem situation are probably in a single digit range. The few that can are the ones that use RAM as a cache like a DB (e.g MySQL) or a web browser, both of which would probably work better if they simply let the kernel do the caching anyway (with memory mapped files and the like) instead of building their own cache-system (something they often do in order to work on other operating systems).

                Another problem with such a signal would be for those applications that would want to flush their RAM content to disk in a low mem situation, in order to do that they would need to allocate even more memory (open a file, having a write buffer and so on).

                Comment


                • #98
                  Originally posted by down1 View Post

                  Yes and isn't every application designed to gracefully exit at any time? This is not a viable model for server applications and scientific computing.
                  AFAIK in Android the JVM can simply halt the application and flush it to disk, then later it can read it back and resume operation. Something that is not a problem for a majority of apps but would be quite problematic for say a network server...

                  Comment


                  • #99
                    Originally posted by benjamin545 View Post
                    this has been an issue with linux desktop for the past several years. it use to be that you could run linux on a quarter gig of ram with no risk of issue for most average tasks..
                    Parkinson's Law

                    Comment


                    • Swap only delays this issue, you will run into the same problems when the Swap gets compltely filled up.

                      Comment

                      Working...
                      X