Tux-On-Ice Vs. Uswsusp

[cosurgi]

Hi,

Pandora of course will have a hibernate capability. I have been benchmarking on my PC the two options that we have at hand: tux-on-ice & uswsusp, here's a short summary:

The tux-on-ice is better, but it is not built into vanilla kernel. I have no idea if it works on ARM, you guys with ARM CPUs at hand would need to check this.

Why it is better: the hibernation time is roughly twice faster (eg. 4 minutes with uswsusp vs. 2 minutes with tux-on-ice on my PC). The resume time of tux-on-ice is about twice slower than uswsusp (about 2 minutes with tux-on-ice vs. 1 minutes with uswsusp), but after resume the amount of used swap with tux-on-ice is exactly the same as before hibernation. On the contrary with uswsusp after you resume ALL your stuff is on swap, and you end up with a very unresponsive OS, since it needs to read everything from swap, when you click on anything to do anything, this kind of defeats the point of "fast" resume time of about 1 minute.

I suppose that on Pandora the hibernate time would be about 15 seconds with tux-on-ice, assuming that your SDHC card is 20MB/sec write speed. And probably 30 seconds with uswsusp.

I'll be using tux-on-ice on my pandora, if it turns out to be working on ARM. Mostly doe to resume problems with swapping in uswsup. That's what I wanted to say, thanks for reading my blurb

 

[dflemstr]

I don't think that a lot of people will be using suspend-to-disk at all, but rather just suspend-to-RAM. People won't have the need to keep the Pandora away from some kind of power source for more than 2 weeks, which I approximate will be the absolute minimum time (in reality probably more like multiple months) that the Pandora will survive in its suspend-to-RAM state.

 

[cosurgi]

I don't think that a lot of people will be using suspend-to-disk at all, but rather just suspend-to-RAM.

I haven't thought of that, you are right.

 

[Butterman]

Corsurgi, my computer boots in about 20 seconds. Yours is taking 2 minutes to start with hybernation? You need an upgrade bad.

Either way ARM is built around powersaving and power usage while in S3 will be insignificant.

 

[torpor]

A better option would be to integrate the use of "cryopid" into the Pandora shell/interface manager.

What is cryopid? Its a process freezer for Linux.

When the user hits suspend, all that needs to happen is that cryopid is called on the Process ID for the main shell and/or the currently running application .. then when un-suspend, the shell checks for the frozen file, and if it exists, runs it.

If this works, its a lot nicer because it means that the Games themselves can be frozen - i.e. not just at the main hybernation point, but in general .. and of course that then becomes *very* interesting .. imagine being able to freeze and resume any game, whenever you like. Save-states become *also* very interesting - games themselves don't have to support save-state, if the primary Pandora shell supports it well enough.

The question though, of course, is whether we can get cryopid running on the Pandora kernel. Probably. Not sure yet. Will have to wait for my Pandora to arrive before I can investigate this, but I would be very happy if we could get it working ..

 

[dflemstr]

A better option would be to integrate the use of "cryopid" into the Pandora shell/interface manager.

What is cryopid? Its a process freezer for Linux.

When the user hits suspend, all that needs to happen is that cryopid is called on the Process ID for the main shell and/or the currently running application .. then when un-suspend, the shell checks for the frozen file, and if it exists, runs it.

If this works, its a lot nicer because it means that the Games themselves can be frozen - i.e. not just at the main hybernation point, but in general .. and of course that then becomes *very* interesting .. imagine being able to freeze and resume any game, whenever you like. Save-states become *also* very interesting - games themselves don't have to support save-state, if the primary Pandora shell supports it well enough.

The question though, of course, is whether we can get cryopid running on the Pandora kernel. Probably. Not sure yet. Will have to wait for my Pandora to arrive before I can investigate this, but I would be very happy if we could get it working ..

What about the STOP/CONT process signals that the kernel uses? They should work equally well, shouldn't they? I don't think that you'll gain performance using cryopid compared to the kernel suspend. Now, freezing processes; that's another story entirely.

 

[torpor]

What about the STOP/CONT process signals that the kernel uses? They should work equally well, shouldn't they? I don't think that you'll gain performance using cryopid compared to the kernel suspend. Now, freezing processes; that's another story entirely.

STOP/CONT process signals are just signals .. sure, an app can trap them and then do something about it, but this is not a suspend mechanism. Its just a signal.

Cyropid *IS* process freezing - please verify you understand what cyropid is doing .. which is *exactly* process freezing, and without question it will be much, much faster to just freeze the current foreground application to disk and then shut down than it will be to do a full system hybernation. No question about it, freezing a single process to disk is always going to be faster than doing a system suspend. With the method I recommend, the system does its own low-power hybernation (init level 2 or something) -or- a full and complete (and faster) shutdown to power off state after freezing the main user processes. This will be faster. Then, when it boots up again it checks for the existence of freeze files (in /usr/freeze ??) and if they are there, the main user shell starts them up directly .. resulting in a restoration of the main user app/game.

We have to investigate this .. if I had a developer board or Pandora itself, I'd try to port cryopid immediately and see how it works with some of the other user apps, and if its useful and functions properly, try to integrated this into the main user shell of the Pandora release. It'd be such a great thing to be able to suspend games back and forth, also .. definitely worth investigation. Maybe some of the other devs can have a try with this, and since I work with cryopid every day professionally, I can help if there are any snags with using it on the Pandora kernel/ARM architecture ..

 

[Vorporeal]

There's one problem. You're not going to want to freeze files to NAND for obvious reasons. Therefore, they have to be frozen to SD. The issue with this is that a user might hibernate to SD, remove the SD, not un-hibernate, then later put the SD back in and un-hibernate then. (Did that make any sense?)

It's not a real issue from the standpoint of the device booting badly, but it is a minor usability issue.