Announcement

Collapse
No announcement yet.

Systemd Will Be Working To Improve Out-Of-Memory Linux Handling With Facebook OOMD

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

  • #21
    Originally posted by NotMine999 View Post
    It would be nice to see the Fedora code used and not the systemd code.

    It would be one of those times when some of us can when a Redhat product quietly says to Lennart: "Hold my beer. We got this. Go off and write a systemd replacement for /dev/null"
    it will be nice when redhat will show you and other idiots middle finger and switch to oomd (which is written by facebook, not by lennart, you moron)

    Comment


    • #22
      So what, systemd-oomd is actually going to be a thing?

      Comment


      • #23
        lol called it.

        https://www.phoronix.com/forums/foru...ory-situations

        "Oh no, the kernel oom killer hangs the system, quick lets just make sure the kernel oom killer is never called.. *whew* glad we fixed that kernel oom killer!"

        Well done Linux team : clap : good job avoiding the problem.

        While I'm giving you guys bad suggestions.. how about a systemd daemon that monitors disk usage and and messages you on facebook when your drive is 90% full.. we wouldn't want users to have full space... hey maybe it could automatically delete your chrome cache too.. and we could make an alexa skill for it also.

        No please.. don't credit me.. you can take all the "honor" yourself.
        Last edited by k1e0x; 09 January 2020, 03:24 AM.

        Comment


        • #24
          Originally posted by NotMine999 View Post

          Good question.

          It would be nice to see the Fedora code used and not the systemd code.

          It would be one of those times when some of us can when a Redhat product quietly says to Lennart: "Hold my beer. We got this. Go off and write a systemd replacement for /dev/null"
          I personally couldn't care less which implementation is used as long as it provides the same API consistency and tight coupling with the rest of the systemd ecosystem.

          Comment


          • #25
            Originally posted by pal666 View Post
            because only for facebook developers fixing it is important enough?
            Yes, unfortunately. Despite shitloads of money, all corporations involved in Linux ecosystem sucks.

            They just care about big iron, don't give a shit to desktop.

            It's extremely pathetic the OOM/ memory management has been so crap in Linux for so many years.

            Does nobody noticed the OOM issue so many years ago? I even noticed it tons of years ago. It's like a bad joke.

            Comment


            • #26
              Originally posted by FPScholten View Post

              To find out which files it is choking on, use lsof
              something like
              Code:
              sudo lsof -c tracker-miner-fs
              should give you a list.
              Also check out the other processes tracker uses. (not using tracker myself so not sure about the names of the daemons, check them first!
              Thnx, but it's kind of hard to find out which processes are running, when the system pushes the mouse cursor pixel by pixel and keytypes need up to 10 minutes to get registered which makes debugging really hard, even if I were more capable at it, which I am not. And it could also be just a very convoluted directory structure (MAXPATH is greeting). With gnome being written in pure C, there's probably tons of memory management issues in the code.

              IMHO this is a systematic software design failure and there's enough options that gnome-tracker and or / Linux could do without each and every affected user having to reverse engineer these complex systems:

              1. Log and avoid critical files (gnome-tracker)
              2. Use sane cgroups defaults for memory and time limits (gnome-tracker and distros).
              3. Have a memory management infrastructure with OOM-killer as a first class citizen, that actually works in a somwhat reliable way. (Linux kernel and glibc?)

              From what I read in the mailing lists, we have settled for one or two poor tracker devs doing the ungrateful busywork of trying to "fix" one of the 10000 bugs in the tracker codebase and ask somewhat helplessly if "everything is ok now?" -.-

              Sooooo, if systemd manages to improve this in a systematic way, all hail to Lennart and friends :-)

              Comment


              • #27
                Originally posted by pal666 View Post
                it can be fixed by assigning memory limit to one process
                In theory you are right, but there's three types of people involved:

                1. gnome-tracker devs, who know about gnome-tracker, but very little about process memory limits, cgroups, system-management in general,
                2. distro managers and systemd gurus, which don't know or care about gnome-tracker,
                3. end users, which don't know about neither.

                So, in praxis, this will not happen ;-)

                Comment


                • #28
                  Originally posted by fkoehler View Post

                  In theory you are right, but there's three types of people involved:

                  1. gnome-tracker devs, who know about gnome-tracker, but very little about process memory limits, cgroups, system-management in general,
                  2. distro managers and systemd gurus, which don't know or care about gnome-tracker,
                  3. end users, which don't know about neither.

                  So, in praxis, this will not happen ;-)
                  This makes me think about using qemu and going back to DOS.

                  Do we need lots of features with one basic one failing such as proper memory management? Just sayin'...

                  Comment


                  • #29
                    Originally posted by timofonic View Post
                    Yes, unfortunately. Despite shitloads of money, all corporations involved in Linux ecosystem sucks.

                    They just care about big iron, don't give a shit to desktop.
                    there is one large linux desktop vendor. google should sound familliar. i guess chromebooks do not suffer from this and the only option to kill chrome isn't very appealing anyway
                    Originally posted by timofonic View Post
                    It's extremely pathetic the OOM/ memory management has been so crap in Linux for so many years.

                    Does nobody noticed the OOM issue so many years ago? I even noticed it tons of years ago. It's like a bad joke.
                    i notice it rarely enough to be offended by "fixes" which just reduce available memory (like recent fedora article, i have no idea what oomd does)

                    Comment


                    • #30
                      Originally posted by Shiba View Post
                      This obviously needs to be fixed
                      Not going to lie, that got a chuckle out from me.

                      Comment

                      Working...
                      X