Page 1 of 8 123 ... LastLast
Results 1 to 10 of 80

Thread: Ubuntu Is Going After A New Linux Kernel API

  1. #1
    Join Date
    Jan 2007
    Posts
    15,126

    Default 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...

    http://www.phoronix.com/vr.php?view=MTQ0ODk

  2. #2
    Join Date
    Sep 2007
    Posts
    329

    Default

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

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

  3. #3
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,601

    Default

    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.

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote 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.

  5. #5
    Join Date
    Jul 2013
    Posts
    17

    Default

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

  6. #6
    Join Date
    Sep 2007
    Posts
    329

    Default

    Quote 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.

  7. #7
    Join Date
    Jun 2009
    Posts
    1,184

    Default

    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]

  8. #8
    Join Date
    Apr 2010
    Posts
    772

    Default

    Quote 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.

  9. #9
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,601

    Default

    Quote 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".

  10. #10
    Join Date
    Apr 2010
    Posts
    772

    Default

    Quote 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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •