Ubuntu Is Going After A New Linux Kernel API

[gufide]

Canonical present: Lin32 API

[mrugiero]

garbage collector are an aberration of nature and they normally waste more memory than they save but allow all sort of lazyness in the name "easy of use". don't believe me? try to make 2 programs one in C/C++ and other in .Net/java/JS that fill lots of ram and then clean it, the result will show you why something like that is not very welcomed since the kernel is not the place to solve lazyness

I don't think it is about laziness (I mean the proposed API, GC is about being lazy, IMO), but about being able to cache and preprocess data to use later, but allow it to be freed if really needed. Mostly caching, since if it's costly to regenerate, it shouldn't be marked as revocable, and if it isn't, then there's almost no benefit on processing it ahead of its use.

[jrch2k8]

I don't think it is about laziness (I mean the proposed API, GC is about being lazy, IMO), but about being able to cache and preprocess data to use later, but allow it to be freed if really needed. Mostly caching, since if it's costly to regenerate, it shouldn't be marked as revocable, and if it isn't, then there's almost no benefit on processing it ahead of its use.

i agree, my deep point is in an GC'ed language fill memory is a swift but in a compiled language you need the actual data ahead, i mean if my C++ app is gonna eat 512mb i need 512mb of hard data forcibly stored/generated in my procedures/code/assets outside my objects or keep many of may objects alive for a long time.

so such scenario in ARM is void, you will do that in your fat X86 server otherwise will take forever, so the only logical explanation is external data like images[and i mean a lot of them] or videos or very huge datafiles/databases that again is void to do so in ARM it will take forever[you fetch partial/sliced data from a server], games could be but you need flash based very crappy engines otherwise the framebuffer is not wide enough to process that much texturization in realtime.

so in resume with proper usage of a compiled language is really really hard to fill that much memory and keep it so long enough to starve the kernel before it get sigkill'ed.

so the point would be "give me a valid scenario where this can actually happen that deserves to be done in the kernel", so if they fail to do so, kernel devs will give an appropiate "make 3rd party devs fix their crap in userspace this is not windows"

[mrugiero]

SNIP

Well, this is a good argument, IMO. I think it would be good for Firefox (or similar) on low memory desktops, however, since they cache a lot of things, and being able to ditch this cache if the memory is required somewhere else (I'm not aware, though, if there is already a mechanism to know this currently in use, which I guess is likely to be).

[fscan]

Why would you want to write it to a file, if it's just a bunch of data you're keeping in memory? It's not like you want it persisted... it's just state that you can re-create, but which is cheaper to leave in memory. And serializing a few GB of complex structures (some of which may be unpersistable) is a hell of a lot of complexity, compared to the ability to just flag that block of memory as reclaimable and being careful about how you access it.

I'm really not seeing why people seem so resistant to this proposal... it seems like a really good idea, not to mention already available in garbage-collected languages (the GC taking the role of the kernel).

Did you read the text you quoted? there's nothing persistent about it. Just because you access it as a file does not mean it has to be persisted on disk. Also, in my last sentence i was agreeing that such a feature could be useful.

And this has NOTHING to do with garbage collection. I don't think you would be happy if your garbage collector would throw away memory you are still using.

[Alejandro Nova]

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?

[jayrulez]

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.

Just pointing it out: QML is also a garbage collected language.

[garegin]

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.

holy crap I want this on my mac or windows! just put 32gb of ram and never have to swap.

[jrch2k8]

Can anybody confirm this? Is it possible to do something like what the proposed kernel API wants to do with systemd + cgroups alone?

no like the article, cgroups can put limits on how much resources a process can access, so you can force apps to never grow beyond certain sane limit

see http://0pointer.de/blog/projects/resources.html memory limit section for systemd +cgroups

[jrch2k8]

Just pointing it out: QML is also a garbage collected language.

yeap you right, is partially garbage collected since the js part handle many operations thorugh c++ the library and other part is just regular js heap

some explanation here http://qt.developpez.com/doc/5.0-sna...2-performance/

QML is for UI design[that is as far as im willing to use it] and the logic is for Qt in c++ but well at least in QML the GC is not as bad as in Java in case devs wanna take the easy route