Ubuntu Is Going After A New Linux Kernel API

[Kayden]

I'm surprised no one has mentioned this, yet...but based on the 30 second overview, this sounds a lot like the existing madvise() function. Programs can use that to tell the OS "If you're running low on memory, feel free to throw this away, and just give me zeroes later." It's existed on Linux since at least the 2.4 kernel, and also exists on BSD and MacOS X.

In the OpenGL world, this is exposed by the GL_APPLE_object_purgeable extension. As an example, a game might keep textures it doesn't need right away as "purgeable", rather than freeing them. When there's sufficient memory, this keeps them loaded for quick access. If the system starts running out of memory, the OS is free to throw them away - the game can always reload them from disk when it really needs them.

It's a really sensible idea.

[jrch2k8]

I'm surprised no one has mentioned this, yet...but based on the 30 second overview, this sounds a lot like the existing madvise() function. Programs can use that to tell the OS "If you're running low on memory, feel free to throw this away, and just give me zeroes later." It's existed on Linux since at least the 2.4 kernel, and also exists on BSD and MacOS X.

In the OpenGL world, this is exposed by the GL_APPLE_object_purgeable extension. As an example, a game might keep textures it doesn't need right away as "purgeable", rather than freeing them. When there's sufficient memory, this keeps them loaded for quick access. If the system starts running out of memory, the OS is free to throw them away - the game can always reload them from disk when it really needs them.

It's a really sensible idea.

yeah you are right, here some links for those interested http://linux.die.net/man/2/madvise

this is exactly my start point, this situation is really uncommon

[jayrulez]

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

QML is used for both presentation and logic in the Sailfish, Blackberry and Ubuntu app development paradigms.

The difference between using Qt+QML and Java or C#/.NET is neither here nor there with regards to performance.

The proposed API may not be useful in some phones but will be useful in the majority of low end phones sold.

P.S: Do you have any benchmark results comparing these techs?

[mrugiero]

QML is used for both presentation and logic in the Sailfish, Blackberry and Ubuntu app development paradigms.

The difference between using Qt+QML and Java or C#/.NET is neither here nor there with regards to performance.

The proposed API may not be useful in some phones but will be useful in the majority of low end phones sold.

P.S: Do you have any benchmark results comparing these techs?

To be fair to the argument, Ubuntu's convergence idea was supposed to target high end phones, so I don't see why do they care about lower end devices. Good of them by caring, but odd, too.

[Delgarde]

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.

When I say "costly to regenerate", I mean something that might take a few seconds, like re-calculating a page layout in a browser. No big deal if you *do* have to re-create it, but it may be the difference between a snappy responsive app, and one that feels sluggish to the user.

[Delgarde]

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

Not even close. All cgroups does is put a hard limit cap on how much memory can be used. What's proposed here is something more dynamic - the process marks certain memory as reclaimable, so the kernel can force it to be freed without killing the process. While jrch2k8 clearly disagrees, I think this would be an extremely useful feature, if somewhat specialised - you'd need to be very careful designing and coding an application that copes with having it's resources vanish in mid-use.

[rvdboom]

SATA 3 is about 6 MB/s , far from 8GB/s, which is about the transfer rate of DDR3-1066 RAM.

Make it 100 times faster (i.e. 600MB/s). 6MB/s would make it half as fast as Gigabit Ethernet. :-)
I guess you meant 6Gbits/s.

[GreatEmerald]

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.

Why would swapping be bad? Sure, that's some additional writes to the SSD, but if the SSD is proper, it shouldn't be a problem. Swapping doesn't happen all that often under normal use, and it should access the disk less than just doing regular every day tasks does.

Everyone on mobile is already flash based, everything on desktop is moving TO flash based. SATA 3 is what? 8GB/s? I get that not everything is on flash and SATA3 NOW, but moving forward... ya think will storage bandwidth really be an issue?

SATA III is 6 Gb/s theoretical, but due to the encoding used it's actually 4.8 Gb/s (600 MB/s).

I don't think it is about laziness (I mean the proposed API, GC is about being lazy, IMO)

Properly optimised garbage collectors can be better at memory management than typical manual memory management, much like compilers are typically better at their jobs than trying to do manual optimisations. Sure, you can code everything in Assembly and hand-optimise everything to get something more efficient than a compiler could do, but you'd be spending the time in which you could have coded several more applications for that small gain. So GC isn't about being lazy, it's about coding efficiency.

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

D, as a compiled GC language, would like to have a word with you.

[erendorn]

I'm surprised no one has mentioned this, yet...but based on the 30 second overview, this sounds a lot like the existing madvise() function. Programs can use that to tell the OS "If you're running low on memory, feel free to throw this away, and just give me zeroes later." It's existed on Linux since at least the 2.4 kernel, and also exists on BSD and MacOS X.

In the OpenGL world, this is exposed by the GL_APPLE_object_purgeable extension. As an example, a game might keep textures it doesn't need right away as "purgeable", rather than freeing them. When there's sufficient memory, this keeps them loaded for quick access. If the system starts running out of memory, the OS is free to throw them away - the game can always reload them from disk when it really needs them.

It's a really sensible idea.

That looks exactly like what they are looking for

[curaga]

i doubt you find a game that demanding running in ARM for a while, is not like battefiled 4 will run on ubuntu phone anytime soon

Have you checked the current Android top? Shadowgun is very good looking, taking about 1.2gb of space, and most certainly running in ARM native code to reach that kind of performance.

While it's for Android and not general Linux, porting it to general ARM Linux is much easier than a desktop game such as BF4 (as it's already on both ARM and GLES).