sleepy linux

Heute 00:07:31

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:

Quoted 7 lines

Heute 00:07:31

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

IMHO you are making to many special cases. The system can be "sleepy" if all devices can be runtime suspended and all CPUs are idle.

Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:

Quoted 7 lines

Heute 00:07:31

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

IMHO you are making to many special cases. The system can be "sleepy" if all devices can be runtime suspended and all CPUs are idle.

Quoted 6 lines

Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:

Quoted 5 lines

Heute 00:07:31

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

Quoted 5 lines

Quoted 2 lines

I wonder if this is the right approach? What is right interface to the drivers?

IMHO you are making to many special cases. The system can be "sleepy" if all devices can be runtime suspended and all CPUs are idle.

Is there an easy way to tell if all the devices are runtime suspended?

I guess I need to know from atomic context :-(.

Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek:

Quoted 10 lines · Oliver Neukum

Quoted 9 lines

Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:

Quoted 7 lines

Heute 00:07:31

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

Quoted 4 lines

Quoted 2 lines

IMHO you are making to many special cases. The system can be "sleepy" if all devices can be runtime suspended and all CPUs are idle.

Is there an easy way to tell if all the devices are runtime suspended?

Do you really want to know whether they are suspended or whether they could be suspended?

Quoted 1 line

I guess I need to know from atomic context :-(.

Urgh. suspend() must be able to sleep and can fail.

Quoted 4 lines

Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek:

Quoted 1 line

Is there an easy way to tell if all the devices are runtime suspended?

Quoted 2 lines

Do you really want to know whether they are suspended or whether they could be suspended?

If they are suspended.

My plan is: let the drivers autosuspend on their own. If I see all of them are autosuspended, then it looks like great time to put whole system into s2ram...

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Is there an easy way to tell if all the devices are runtime suspended?

Do you really want to know whether they are suspended or whether they could be suspended?

If they are suspended.

Quoted 3 lines

My plan is: let the drivers autosuspend on their own. If I see all of them are autosuspended, then it looks like great time to put whole system into s2ram...

Your calculation of cost/benefit will be wrong. A driver will have timeouts based on the cost of a suspend/resume cycle of that device only. You'd have to calculate of keeping the whole system awake against that.

... I also don't need to call any suspend() routines, because all the drivers are already suspended, right?

And yes, I want device activity to prevent s2ram. If user is burning CD, machine should not sleep. If user is actively typing, machine

should not sleep. My vision is: screen saver tells kernel keyboard need not be very responsive, at that point keyboard driver can autosuspend the keyboard, and if that was the last device, whole system sleeps.

Quoted 2 lines

... I also don't need to call any suspend() routines, because all the drivers are already suspended, right?

Well, you have a number of devices which cannot do runtime pm. They can do suspend/resume with the whole system. For them these operations mean saving/restoring state.
So for these devices implementing autosuspend makes no sense. They would sensibly do only idle/busy detection.

Quoted 2 lines

And yes, I want device activity to prevent s2ram. If user is burning CD, machine should not sleep. If user is actively typing, machine

In these cases the devices involved should report themselves busy, shouldn't they?

Quoted 4 lines

should not sleep. My vision is: screen saver tells kernel keyboard need not be very responsive, at that point keyboard driver can autosuspend the keyboard, and if that was the last device, whole system sleeps.

We lack a notion of telling devices that they are opened only for detecting wakeups. Currently a driver has to assume that an opened device has to be fully functional.

Hi!

Quoted 8 lines

Quoted 2 lines

... I also don't need to call any suspend() routines, because all the drivers are already suspended, right?

Well, you have a number of devices which cannot do runtime pm. They can do suspend/resume with the whole system. For them these operations mean saving/restoring state.
So for these devices implementing autosuspend makes no sense. They would sensibly do only idle/busy detection.

Yep... Let's call busy/idle detection and save/restore state "autosuspend" for those devices. It does not save any power, but it can be viewed as "kind-of-suspend". (No, I do not have this kind of details ready).

Quoted 3 lines

We lack a notion of telling devices that they are opened only for detecting wakeups. Currently a driver has to assume that an opened device has to be fully functional.

Yes, we'll need to add some userland interfaces. No, this will not be easy.

Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek:

Quoted 11 lines

Hi!

Quoted 8 lines

Quoted 2 lines

... I also don't need to call any suspend() routines, because all the drivers are already suspended, right?

Well, you have a number of devices which cannot do runtime pm. They can do suspend/resume with the whole system. For them these operations mean saving/restoring state.
So for these devices implementing autosuspend makes no sense. They would sensibly do only idle/busy detection.

Quoted 4 lines

Yep... Let's call busy/idle detection and save/restore state "autosuspend" for those devices. It does not save any power, but it can be viewed as "kind-of-suspend". (No, I do not have this kind of details ready).

Well, you probably would have to walk through all devices and check all devices are either suspended or can be suspended. That would mean struct device has to be extended to show common attributes.

But what's wrong with calling suspend() the conventional way once you've decided to go into sleepy mode?

Quoted 3 lines

But what's wrong with calling suspend() the conventional way once you've decided to go into sleepy mode?

I'm not sure if it can be done in non-racy way. It is different from "conventional" suspend(): you can still have userland requests after this suspend(), and you should abort auto-sleep if you get one. (As opposed to blocking in system suspend case).

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

Quoted 7 lines · Pavel Machek

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.
I wonder if this is the right approach? What is right interface to the drivers?
3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3.

Yep... for the first version, I'll be very happy if it autosleeps when I'm traveling by bus or something. Working with ethernet plugged in is quite a distant goal.

(But I guess some cleverness could be done on the router or something. Automagically converting "interesting" packets into WoL enabled ones, or...?)
Pavel

Quoted 3 lines

3) Network card that is either down
   or can wake up system on any packet (and not loose too many packets)

This is the big crux I see.  You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3.

Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin:

Quoted 4 lines

Quoted 3 lines

3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3.

How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem.

Quoted 7 lines · Oliver Neukum

Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin:

Quoted 6 lines

Quoted 3 lines

3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3.

Quoted 2 lines

How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem.

A lot of them should. An inordinate amount of machines sit there burning power for no reason. You can argue that S3 isn't needed -- that nohz + C3/C4 + turning off the screen would be enough, and that might be
+ legit.

Quoted 10 lines · H. Peter Anvin

Quoted 7 lines · Oliver Neukum

Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin:

Quoted 4 lines

Quoted 3 lines

3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3.

How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem.

A lot of them should. An inordinate amount of machines sit there burning power for no reason. You can argue that S3 isn't needed -- that nohz + C3/C4 + turning off the screen would be enough, and that might be
+ legit.

NOHZ + C4 + turn off screen + turn off disk + turn off SATA is still ~8W on thinkpad x60.

S3 is ~1W.

That's quite significant difference.

(But yes, connected-to-ethernet is not most important use scenario.)
Pavel

Quoted 5 lines

NOHZ + C4 + turn off screen + turn off disk + turn off SATA is still ~8W on thinkpad x60.

S3 is ~1W.

Quoted 4 lines

That's quite significant difference.

(But yes, connected-to-ethernet is not most important use scenario.)
Pavel

Still... if we could get the desktops of the world down anywhere close to that range when not used, it would be a huge win.

This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration.

I wonder if this is the right approach? What is right interface to the drivers?

		Sleepy Linux
		~~~~~~~~~~~~

Copyright 2007 Pavel Machek <[email protected]>
GPLv2

Current Linux versions can enter suspend-to-RAM just fine, but only can do it on explicit request. But suspend-to-RAM is important, eating something like 10% of power needed for idle system. Starting suspend manually is not too convinient; it is not an option on multiuser machine, and even on single user machine, some things are not easy:

1) Download this big chunk in mozilla, then go to sleep

2) Compile this, then go to sleep

3) You can sleep now, but wake me up in 8:30 with mp3 player

Todays hardware is mostly capable of doing better: with correctly set up wakeups, machine can sleep and successfully pretend it is not sleeping -- by waking up whenever something interesting happens. Of course, it is easier on machines not connected to the network, and on notebook computers.

Requirements:

0) Working suspend-to-RAM, with kernel being able to bring video back.

1) RTC clock that can wake up system

2) Lid that can wake up a system,
or keyboard that can wake up system and does not loose keypress or special screensaver setup

3) Network card that is either down
or can wake up system on any packet (and not loose too many packets)

Todays hardware is mostly capable of doing better: with correctly set up wakeups, machine can sleep and successfully pretend it is not sleeping -- by waking up whenever something interesting happens. Of course, it is easier on machines not connected to the network, and on notebook computers.

Requirements:

0) Working suspend-to-RAM, with kernel being able to bring video back.

1) RTC clock that can wake up system

Quoted 11 lines · Pavel Machek

Todays hardware is mostly capable of doing better: with correctly set up wakeups, machine can sleep and successfully pretend it is not sleeping -- by waking up whenever something interesting happens. Of course, it is easier on machines not connected to the network, and on notebook computers.

Requirements:

0) Working suspend-to-RAM, with kernel being able to bring video back.

1) RTC clock that can wake up system

very nice approach! It might require smarter hardware to be really efficient, but the generic ability for Linux to utilize S3 automatically would _quickly_ drive the creation of smarter hardware i'm sure - so i'd propose to include this even if it wastes power in some cases.

a quick feature request: could you please make the wake-on-RTC capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config option (disabled by default) that does a short 1-second suspend-to-RAM sequence upon bootup? That way we could test s2ram automatically (which is a MUCH needed feature for automated regression testing and automatic bisection). In addition, some sort of 'suspend for N seconds' /sys or /dev/rtc capability would be nice as well.

btw., how far are you from having a working prototype?

Quoted 8 lines

a quick feature request: could you please make the wake-on-RTC capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config option (disabled by default) that does a short 1-second suspend-to-RAM sequence upon bootup? That way we could test s2ram automatically (which is a MUCH needed feature for automated regression testing and automatic bisection). In addition, some sort of 'suspend for N seconds' /sys or /dev/rtc capability would be nice as well.

Hmm, are you sure it is good idea to do this from kernel? I guess this is better done from script...

Quoted 1 line

btw., how far are you from having a working prototype?

SCSI/SATA issues stop me just now, but even if I get that to work, it will be extremely disgusting hack... and it is unclear how to do it nicely :-(.

Quoted 10 lines

Quoted 9 lines

a quick feature request: could you please make the wake-on-RTC capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config option (disabled by default) that does a short 1-second suspend-to-RAM sequence upon bootup? That way we could test s2ram automatically (which is a MUCH needed feature for automated regression testing and automatic bisection). In addition, some sort of 'suspend for N seconds' /sys or /dev/rtc capability would be nice as well.

Quoted 2 lines

Hmm, are you sure it is good idea to do this from kernel? I guess this is better done from script...

i have this low-prio effort to make all self-checks automatically available via 'make randconfig' as well, for all features that have no natural exposure during normal bootup. So far we've got rcutorture, kprobes-check, locking/lockdep-self-test and a handful of others. External scripts tend to go out of sync and LTP takes way too much time to finish.

Quoted 5 lines

Quoted 1 line

btw., how far are you from having a working prototype?

SCSI/SATA issues stop me just now, but even if I get that to work, it will be extremely disgusting hack... and it is unclear how to do it nicely :-(.

as long as the sleep periods are within say 10-20 seconds, and our s2ram cycle is fast and optimal enough, we could do this with networking enabled too, without dropping/stalling TCP connections left and right.

(Perhaps if we could notify routers that they should batch packets for N seconds and we could turn off PHY during that time, it would be even nicer - is there any such router extension in existence?)

but if it's nothing else but a s2ram debug/stress utility, that alone would be great too :-)