Announcement

Collapse
No announcement yet.

Ubuntu Is Going After A New Linux Kernel API

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

  • #11
    Originally posted by oleid View Post
    Probably some IPC mechanism will be used to inform the program, that the memory is taken. Probably DBUS.
    The kernel is *not* going to be using something as heavy as an IPC mechanism to tell applications that they're using too much memory. Most likely, it's just going to yank it out from under the application, and expect the application to deal with it - because by marking the memory as revocable, that's what the application said it was prepared to do.

    Comment


    • #12
      it is often said that swapping is turned off on phones/tablets because it degrades the SSDs. if so, why are SSDs used with regular swapping techniques on personal computers with no problems?

      Comment


      • #13
        Originally posted by garegin View Post
        it is often said that swapping is turned off on phones/tablets because it degrades the SSDs. if so, why are SSDs used with regular swapping techniques on personal computers with no problems?
        Well depends on what you mean by "Regular swapping techniques" For example on my SSD I have swappiness set to 1 to make sure it doesn't swap until the last possible second. Also Cyanogenmod has zRAM support available if you enable developer mode so it doesn't TOTALLY get rid of swapping, it just adjusts the usage patterns for it.

        Comment


        • #14
          Hmm, I wonder if they don't get their API in, will they fork the kernel...?

          Comment


          • #15
            Typical phoronix...

            Originally posted by dee. View Post
            Hmm, I wonder if they don't get their API in, will they fork the kernel...?
            Nice try...

            Comment


            • #16
              mmap()

              hmm .. as this can only be used with static or regenerateable data, whats the benefit over using a mmap()'ed file (readonly) and let the kernel cache do the magic?

              Comment


              • #17
                Originally posted by Delgarde View Post
                On, the contrary - the benefit is about caching. Lots of apps benefit from loading stuff into memory and keeping it there in case it's needed again - if the memory is available, it's a good tradeoff to avoid the cost of loading it from disk next time you need it. This mechanism is a way for the kernel to tell a process "hey, we're running short of memory... get rid of that stuff you were caching".

                Currently, the only options are to prevent processes from using that memory at all, or to kill them when memory runs out. This is a middle ground, letting them use memory if it's available, but avoiding the need for a hard kill when it's not.
                i do know this, my point is you need a real great number of concurrent applications or a very bad coding to starve the memory, specially since default this days is at least 1gb, i mean my full gentoo system with kde-4.11 + akonadi+nepomuk+ zram + ramdisk for everything + firefox 10tabs+ calligra + kernel caches don't hit the 1gb barrier and we are talking about a full fledged x86 desktop system with a bazillion deps and entire set of libraries preloaded on ram.

                i can understand this predicament with java/gavik or .NET garbage collectors eating ram to optimize real crappy loops but ubuntu phone will be using c++ and QML with qt5 right? which both are very ram lightweight if coded right. so base on this i can only imagine those 3 posibilities in my previous posts to actually need something like this.

                Comment


                • #18
                  vmpressure_fd

                  Sounds like the want the inverse of vmpressure_fd

                  Comment


                  • #19
                    Originally posted by Delgarde View Post
                    On, the contrary - the benefit is about caching. Lots of apps benefit from loading stuff into memory and keeping it there in case it's needed again - if the memory is available, it's a good tradeoff to avoid the cost of loading it from disk next time you need it. This mechanism is a way for the kernel to tell a process "hey, we're running short of memory... get rid of that stuff you were caching".
                    Why not just read from disk every time? If there's lots of free RAM, it will be in the disk cache, if not, the operating system can drop it from the disk cache automatically to make space.

                    Comment


                    • #20
                      Originally posted by jrch2k8 View Post
                      i mean my full gentoo system with kde-4.11 + akonadi+nepomuk+ zram + ramdisk for everything + firefox 10tabs+ calligra + kernel caches don't hit the 1gb barrier and we are talking about a full fledged x86 desktop system with a bazillion deps and entire set of libraries preloaded on ram.
                      You don't play games, do you?

                      Comment

                      Working...
                      X