Announcement

Collapse
No announcement yet.

Ubuntu Is Going After A New Linux Kernel API

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

  • Ubuntu Is Going After A New Linux Kernel API

    Phoronix: Ubuntu Is Going After A New Linux Kernel API

    In large part because of Canonical's new focus around Ubuntu Touch on phone/tablet devices, the Ubuntu developers are wanting a new revocable memory API for the Linux kernel to help in low-memory scenarios...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    A brief smile lit up my face when reading this very part of the article:

    Originally posted by phoronix View Post
    [...]one of their work items is, "Check with upstream [...]

    Comment


    • #3
      Hmm, how does the program know whether its variables are still allocated, or have been freed by the kernel, then? Either way that sounds like adding some processing overhead.

      Comment


      • #4
        Originally posted by GreatEmerald View Post
        Hmm, how does the program know whether its variables are still allocated, or have been freed by the kernel, then? Either way that sounds like adding some processing overhead.
        Might do it instead with assets. Variables are PROBABLY cheap most of the time, what might be the real hog is if they are loading all graphics / pictures / icons / etc into memory, then mark those are purge-able. Data the user has entered isn't static, program needs to know about that. But its assets however are static, unchanging. No big deal if it has to wipe the slate clean of those and reload them.

        Just off the top of my head.
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Ah well, what does it matter? Half of Phoronix will find a way to bash this idea anyway just because it comes from Canonical.

          Comment


          • #6
            Originally posted by GreatEmerald View Post
            Hmm, how does the program know whether its variables are still allocated, or have been freed by the kernel, then? Either way that sounds like adding some processing overhead.
            Probably some IPC mechanism will be used to inform the program, that the memory is taken. Probably DBUS.

            Comment


            • #7
              i don't see point of workaround this, only few cases will ever hit such a problem and the cause will probably be crappy apps, for example:

              case 1: map images or other datasets bigger than the ram itself
              case 2: infinite loops putting data on memory
              case 3: very long sequential algorithms putting lot of data in ram

              solution 1: use slices and threads don't be an lazy bum
              solution 2: bug, use valgrind
              solution 3: use OOP and memory smartly, clipper age ended years ago

              solution to all 3: Cgroups memory restrictions per process which is already on kernel and usable from systemd[nih though so prolly won't happen]

              Comment


              • #8
                Originally posted by jrch2k8 View Post
                i don't see point of workaround this, only few cases will ever hit such a problem and the cause will probably be crappy apps, for example:
                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.

                Comment


                • #9
                  Originally posted by oleid View Post
                  Probably some IPC mechanism will be used to inform the program, that the memory is taken. Probably DBUS.
                  Fair enough. I assume there will be a way to delay reallocating memory, too, because if the resources in memory are being used at the moment when they are remapped, and the message hasn't reached the program yet or the program doesn't have enough time to clean it, you'd still hit undefined behaviour. On the other hand, if memory is needed that badly, the system may not have the luxury of time for cleanups... Or even enough memory to generate a D-Bus message.

                  I get the feeling that this marking is going to be less of "you can take this if you really need to" and more of "this is no longer allocated, but please try not to reallocate if you can so I can quickly reuse this again later".

                  Comment


                  • #10
                    Originally posted by GreatEmerald View Post
                    Hmm, how does the program know whether its variables are still allocated, or have been freed by the kernel, then? Either way that sounds like adding some processing overhead.
                    Well, they've not designed an API yet, but I assume it would involve a new function in glibc that allows the program to mark a particular block of allocated memory as 'revokable', e.g because they're using that block for cached data that can be re-created if needed. When a revocation actually occurs in the kernel, the kernel can simply reallocate the memory, and ensure that when the application tries to access that memory, it gets a signal that says the memory has been revoked (instead of the usual SIGSEGV). The app should then respond safely to that signal by cleaning up any references it had to the lost memory, and then continuing (perhaps by allocating a newer, smaller cache).

                    Comment

                    Working...
                    X