Pandora Quite Realistic Chance To Have About 400Mb Of Ram In Pandora

[cosurgi]

Well, the title says it all, see an article on lwn: http://lwn.net/Articles/334649/

Then let's start thinking if we can (and want) put that into Pandora linux kernel

EDIT: they are planning it for 2.6.32 kernel

 

[lulzfish]

It sounds like they suggest using the RAM as a swap device by compressing swap pages.

So basically, you have 256MB of RAM, but an application that isn't running much gets swapped out into the compressed portion.
This might be useful since I usually have a couple random background applications running that could easily be suspended and compressed.

It's not the same as having 400MB of working RAM, though. Since it's a swap device, any usage requires the page to be decompressed... It's just a slightly better usage of available RAM.

 

[dflemstr]

I don't know if this would actually be useful, because I don't usually use apps that run in such a "low CPU mode" that they can be swapped, and that at the same time use loads of RAM. I mean sure, if I am a guy who uses a CAD-file viewer and have the need to just view portions of a 300 MB CAD file every now and then, or if I want to use raycasting rendering systems, or if I want to start a web server on the Pandora that needs loads of caching, or maybe load gitk to view a tree with 155116 tracked commits (certain kernel developers might do this ), then this might be useful to me...

I still voted yes, because if this goes into the mainline kernel, we WILL get it sooner or later, so saying "no" here would mean that I wouldn't want the Pandora to have the latest kernels, which is why I don't.

 

[javaJake]

I don't know about the rest of you, but for me, the more RAM, the better, and I don't mind the CPU costs (if they even exist?) myself.

One issue that may hurt some is the lack of hibernation support. Since this essentially reserves a segment of RAM as swap, and since the kernel wouldn't dare try and touch the swap for fear of running into a loop (as far as I could gather from the comments), you'd have to first shut down this compressed swap before it went into hibernation.

Nevertheless, this project gets my vote

 

[Username]

Very nice, did well to soothe my irateness (turns out that is a real word).

 

[greendots]

It might be any easy way to support ports that require more ram too.

 

[dflemstr]

It might be any easy way to support ports that require more ram too.

True, wasn't there a discussion about porting some engine a couple of months ago that had ~200 MB of statics in it? In such situations, paging might help immensely.

 

[Trip]

Sounds like it could be very useful.
Wouldn't the user be able to by pass it with a command on boot anyway if it's not wanted or needed?

EDIT: Once these modules are loaded, one can just enable the ramzswap swap device:

swapon /dev/ramzswap0

Take that as a yes

EDIT 2: Wouldn't this be more useful for the people wanting to write and compile software directly on the Pandora itself?

 

[multiplex]

It certainly shouldn't hurt to have as an option when it hits the mainline kernel, but you'd have to benchmark it and see how it pans out on real Pandora workloads.

Claiming this could give you 400MB of RAM is highly misleading (where did you extrapolate that from?). It steals free RAM to use as swap memory. Fast swap memory, yes, but not even comparable to direct memory access, and for data with low compressibility it adds nothing but overhead.

Various forms of suspend are vital to portables like the Pandora. That will have to work.

I don't think it would be productive to have Pandora devs working on this right now unless they're sitting around twiddling thumbs somewhere. It's worth a shot later on.

Next up: Quite Realistic Chance To Have About 1GB Of Flash In Pandora... With DriveSpace!

 

[Kramy]

I voted no. It would be handy to have the option available, but I feel it should be turned off by default, and enabled on a case by case basis.

If I can make a Java app use less memory than a C app, then the developer of that C app clearly doesn't care about optimization very much. This is a crutch, which could be handy, but is still a crutch.

If it could be enabled per-application, that might also be okay. It would be handy for Firefox, but not for games.

 

[dflemstr]

I voted no. It would be handy to have the option available, but I feel it should be turned off by default, and enabled on a case by case basis.

Why's that? It's not like you lose any significant power by having it turned on.

If I can make a Java app use less memory than a C app, then the developer of that C app clearly doesn't care about optimization very much. This is a crutch, which could be handy, but is still a crutch.

The day I see any Java app, no matter how small, that consumes less memory than a C program performing the same task; that day only exists in a parallel universe. (It might be FASTER, yes, but not use less memory)

And I don't think that devs will be relying on the feature being there. People have more sense than that, and I don't think that there are developers unskilled enough to rely on there being more RAM than there actually is in a machine around here. (← Wow, that could have been a German sentence based on the sentence's structure, heh)

If it could be enabled per-application, that might also be okay. It would be handy for Firefox, but not for games.

Don't know if it could be "enabled" on a per-application basis, but you can most certainly set priorities amongst running applications so that some don't get swapped that easily.

Also, I would see an use in having it turned on for circumstances when you want to run multiple memory-hungry applications in tandem.

 

[Kramy]

I voted no. It would be handy to have the option available, but I feel it should be turned off by default, and enabled on a case by case basis.

Why's that? It's not like you lose any significant power by having it turned on.

Prove it?

I'd believe it on a desktop CPU, but how will the OMAP3530 fare? Isn't it already memory bandwidth starved? Now you want to compress and decompress stuff on the fly?

If I can make a Java app use less memory than a C app, then the developer of that C app clearly doesn't care about optimization very much. This is a crutch, which could be handy, but is still a crutch.

The day I see any Java app, no matter how small, that consumes less memory than a C program performing the same task; that day only exists in a parallel universe. (It might be FASTER, yes, but not use less memory)

How about Azureus, Transmission? Azureus 2.5.0.4 (the last version I used, before it finally turned into the bloat of today) consumed less memory with the same torrents than Transmission. Since then I've flipped to qBittorrent, which beats both of them.

I recall from an old GP2X thread, someone was trying to port something(Zelda clone?) which cached an entire game world in memory rather than using dynamic loading. (streaming with small buffers) Java pushes you towards a smarter design, even if the JVM and all running code has extra overhead.

And I don't think that devs will be relying on the feature being there. People have more sense than that, and I don't think that there are developers unskilled enough to rely on there being more RAM than there actually is in a machine around here. (← Wow, that could have been a German sentence based on the sentence's structure, heh)

If it could be enabled per-application, that might also be okay. It would be handy for Firefox, but not for games.

Don't know if it could be "enabled" on a per-application basis, but you can most certainly set priorities amongst running applications so that some don't get swapped that easily.

Also, I would see an use in having it turned on for circumstances when you want to run multiple memory-hungry applications in tandem.

I already said I thought it'd be handy to have the option, but I still think it should be off by default - at least until it gets tested/benched on an actual Pandora, and we get some numbers.

 

[lulzfish]

The compressed RAM is only swap space. If your programs can fit in the normal 256MB comfortably, it won't be compressing anything.
It might lower the 256MB limit to 254 or 255 since it will need a few empty pages available, but having it enabled won't use any extra CPU / memory until you start to run low on memory.

 

[pelrun]

Wow, they're bothering to do this again? I remember this tech from fifteen-odd years ago... good old RamDoubler.

 

[dflemstr]

Wow, they're bothering to do this again? I remember this tech from fifteen-odd years ago... good old RamDoubler.

Well, if it works well and is a good idea, then why not use it? But cool to hear that it isn't a new idea.

BTW, congrats to the epic gravedig.

 

[Mithrildor]

Why not? If it helps some apps, why dont give to option for some apps to use it. And for others that wont help it not.

 

[grasshoppir]

it makes even less sense on a portable device with a small screen.

 

[pelrun]

BTW, congrats to the epic gravedig.

I didn't gravedig this, it was in my "New Content" list!

...ah, looks like whoever did gravedig it deleted their post. :S

 

[Alec]

Well, if it works well and is a good idea, then why not use it? But cool to hear that it isn't a new idea.

BTW, congrats to the epic gravedig.

Actually, it's pretty timely since 2.6.33 is going to come out in a few weeks.

 

[kmob]

Given that this is now mainlined, this looks very interesting. Looking at the worst case figures on their wiki this would seem a no brainer for us?