The 2005 Linux Kernel Developers' Summit

Posted Jul 20, 2005 8:09 UTC (Wed) by cborni (subscriber, #12949)
Parent article: The 2005 Linux Kernel Developers' Summit

I totally agree with Linus. I absolutely dont care about suspend to disk I
want suspend to ram. To make things worse, lots of new kernel features
like freeing memory before suspend or compression might be a good idea for
the first, but are useless for the latter.
Then there is ACPI, which is unfortunately not a simple design. Some month
ago I tried to fix some kernel warnings about sleeping functions, but I
was told that the right solution is much harder and requires some
redesign. So its a long way to go I guess.
Even if we are able to get the kernel code in shape, lots of users will
probably use the nvidia/ATI/whatever binary module which need to be fixed
as well.

to post comments

The 2005 Linux Kernel Developers' Summit

Posted Jul 20, 2005 10:13 UTC (Wed) by arafel (subscriber, #18557) [Link] (1 responses)

Unfortunately, I don't think Linus is right. I don't want suspend to RAM, I want suspend to disk.

Well, okay, both might be useful - but if I can only have one, it'll be disk.

The 2005 Linux Kernel Developers' Summit

Posted Jul 21, 2005 11:58 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Why not stage in RAM, and optionally store to disk? Might be a compression opportunity there. I don't grasp the OR here.

Suspend to Disk/RAM

Posted Jul 20, 2005 17:34 UTC (Wed) by danm628 (guest, #5995) [Link] (1 responses)

I suspect many people want what I can get from XP on my work notebook (IBM Thinkpad T40). When the lid is shut it does a suspend to RAM, when the lid is opened the system comes up within a couple of seconds. When the system stays in suspend to RAM for a period (I have it set to 15 minutes) it wakes up and does a suspend to disk. I go for weeks without shutting down and rebooting my work notebook. (Actually it can't go for weeks without a reboot, since there will be at least one patch pushed by IT which requires a reboot.)

My home notebook (Thinkpad T41) running Ubuntu isn't quite as flexible. I can do suspend to RAM but there is no option to automatically suspend to disk after staying in suspend to RAM for a period. (Or if there is an option I didn't find it -- which would be a GUI bug not a kernel issue.) Suspend to disk works and it is what I normally do, that way the system comes up fairly quickly when I want to use it. Windows is a *LOT* prettier to watch come out of suspend to disk. I don't mind the odd screen flashes, etc. while the display driver. But I'm sure my non-programmer friends would prefer a nice progress bar instead of kprintf messages.

So what I really want is both suspend to disk and RAM to work reliably. I want to be able to open my notebook and quickly get to work, the definition of quickly depends on how long the notebook has been off (couple of seconds for suspend to RAM or 10 to 20 seconds for suspend to disk). I like being able to shut the lid and know that the system will automatically go to the appropriate low power state. I don't want to have to decide how long I'm going to want it to suspend for and which type of suspend it should do.

Suspend to Disk/RAM

Posted Jul 22, 2005 20:44 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

If you have working suspend-to-RAM, suspend-to-disk, and ACPI wakeup (echo YYYY-MM-DD HH:MM:SS > /proc/acpi/alarm), it is possible to have the machine arrange to wake itself up in 15 minutes, then suspend to RAM. On resume from RAM, the machine checks the clock and decides to either finish resuming, or suspend to disk. I know this works because I've configured my ex-laptop to do it...but I stopped because the laptop was more often than not in a moving insulated laptop case 15 minutes after suspend, and the CPU would sometimes cook itself in the ~45 seconds required to suspend to disk, especially in summer.

I'd like to see an LVM with a snapshot feature combined with suspend-to-disk, to implement a checkpoint-restart system, with the option of reverting the entire system (RAM and disk) to where it was when it last suspended. The relatively minor data loss of reverting to last suspend before a crash is usually much less painful than reconstructing all the userspace state by hand (literally).

Once the suspend/resume problem is solved, the next most annoying thing about laptops is the game of Russian roulette that is played every time a PCMCIA or USB device is connected. It's especially bad for laptops since they are exposed to more devices per boot than a typical desktop in my experience. If a device with a buggy Linux driver crashes on load, it usually takes the system with it. A checkpoint/restart approach would allow the user to say "oops, guess I'll unplug that and try again" instead of "darn, now I have to spend 20 minutes getting all my user-space stuff put back together."