Page 1 of 3 123 LastLast
Results 1 to 10 of 80

Thread: Ubuntu Is Going After A New Linux Kernel API

Hybrid View

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

    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
    331

    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
    Jul 2007
    Posts
    256

    Default

    Quote Originally Posted by Vistaus View Post
    Ah well, what does it matter? Half of Phoronix will find a way to bash this idea anyway just because it comes from Canonical.
    Nope, if they work with upstream, this would be a very useful and welcome feature. And yes, I did bash Unity and Mir.

  7. #7
    Join Date
    Sep 2007
    Posts
    331

    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.

  8. #8
    Join Date
    Jun 2009
    Posts
    1,185

    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]

  9. #9
    Join Date
    Apr 2010
    Posts
    777

    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.

  10. #10
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    257

    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:

    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]
    Can anybody confirm this? Is it possible to do something like what the proposed kernel API wants to do with systemd + cgroups alone?

Posting Permissions

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