[demo patch/RFC] sleepy linux
Sleepy linux support, demo version, but it works on my thinkpad x60 ;-).
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/Documentation/power/sleepy.txt b/Documentation/power/sleepy.txt
new file mode 100644
index 000..a9caf05
--- /dev/null
+++ b/Documentation/power/sleepy.txt
@@ -0,0 +1,55 @@
+ 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)
+
+How to use it
+~
+
+First, make sure your config is tiny enough that cpu sleeps at least
+five or so seconds between wakeups. You'll probably need to disable
+USB, make some kernel timers way longer than default and boot with
+init=/bin/bash.
+
+Then, enable SCSI powersave by something like:
+
+mount /sys
+echo auto >
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/level
+echo 3 >
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/autosuspend
+echo adisk > /sys/power/state
+mount / -oremount,commit=900
+
+Then, echo auto > /sys/power/state should enable sleepy support. Do it
+twice, and it will ignore open lid and sleep anyway.
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a7d50a5..4c25613 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -187,6 +187,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -32,6 +32,7 @@
*
*/
+#define DEBUG
#include
#include
#include
@@ -259,8 +260,8 @@ static void ahci_fill_cmd_slot(struct ah
u32 opts);
#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
-static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
-static int ahci_pci_device_resume(struct pci_dev *pdev);
+int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
+int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
static struct class_device_attribute *ahci_shost_attrs[] = {
@@ -268,6 +269,41 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+struct sleep_disabled_reason ahci_active = {
+"ahci"
+};
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autosuspend\n");
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ enable_auto_sleep(_active);
+ return 0;
+ }
+ printk("ahci: autosuspend disabled\n");
+ return -EINVAL;
+}
+
+/* The host needs to be autoresumed */
+static int autoresume(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autoresume\n");
+ disable_auto_sleep(_active);
+ ahci_pci_device_resume(my_pdev);
+ return 0;
+ }
+ printk("ahci: autoresume disabled\n");
+ return -EINVAL;
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -286,6 +322,8 @@ static struct scsi_host_template ahci_sh
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
.shost_attrs= ahci_shost_attrs,
+ .autosuspend= autosuspend,
+ .autoresume =
Re: [linux-pm] [demo patch/RFC] sleepy linux
On Tue, 26 Feb 2008 11:26:53 +0100 Pavel Machek wrote:
Hi Pavel,
Is this limited to UP and only one disk?
[comments below]
> Sleepy linux support, demo version, but it works on my thinkpad x60 ;-).
>
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
> diff --git a/Documentation/power/sleepy.txt b/Documentation/power/sleepy.txt
> new file mode 100644
> index 000..a9caf05
> --- /dev/null
> +++ b/Documentation/power/sleepy.txt
> @@ -0,0 +1,55 @@
> + 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
Usually "can only do it" AFAIK.
> +something like 10% of power needed for idle system. Starting suspend
> +manually is not too convinient; it is not an option on multiuser
convenient;
> +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
Today's
> +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
lose
> + 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)
lose
> +
> +How to use it
> +~
> +
> +First, make sure your config is tiny enough that cpu sleeps at least
CPU (please)
> +five or so seconds between wakeups. You'll probably need to disable
> +USB, make some kernel timers way longer than default and boot with
> +init=/bin/bash.
> +
> +Then, enable SCSI powersave by something like:
> +
> +mount /sys
Isn't /sys auto-mounted by kernel?
> +echo auto >
> /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/level
> +echo 3 >
> /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/autosuspend
> +echo adisk > /sys/power/state
> +mount / -oremount,commit=900
> +
> +Then, echo auto > /sys/power/state should enable sleepy support. Do it
> +twice, and it will ignore open lid and sleep anyway.
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 29e71bd..0197b1f 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -268,6 +269,41 @@ static struct class_device_attribute *ah
> NULL
> };
>
> +struct pci_dev *my_pdev;
> +int autosuspend_enabled;
> +
> +struct sleep_disabled_reason ahci_active = {
> +"ahci"
> +};
> +
> +/* The host and its devices are all idle so we can autosuspend */
> +static int autosuspend(struct Scsi_Host *host)
> +{
> + if (my_pdev && autosuspend_enabled) {
> + printk("ahci: should autosuspend\n");
Use printk() KERN_* levels (multiple places).
> + ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
> + enable_auto_sleep(_active);
> + return 0;
> + }
> + printk("ahci: autosuspend disabled\n");
> + return -EINVAL;
> +}
> +
...
> +}
> +
> +
> +
> static struct scsi_host_template ahci_sht = {
> .module = THIS_MODULE,
> .name = DRV_NAME,
> @@ -1820,6 +1858,10 @@ static void ahci_thaw(struct ata_port *a
>
> static void ahci_error_handler(struct ata_port *ap)
> {
> + struct ata_host *host = ap->host;
> + int rc;
> + extern int slept;
Eh?
> +
> if (!(ap->pflags & ATA_PFLAG_FROZEN)) {
> /* restart engine */
> ahci_stop_engine(ap);
General comment: Lots of the comment fixes in libata should be part
of a standalone patch, not part of this patch.
> diff --git a/include/linux/ata.h b/include/linux/ata.h
> index 78bbaca..df2dd4f 100644
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -298,6 +298,13 @@ enum {
> SCR_ACTIVE = 3,
> SCR_NOTIFICATION= 4,
>
> + /* SControl subfields, each field is 4 bit wide */
bits
> + ATA_SCTL_DET= 0, /* lsb */
> + ATA_SCTL_SPD= 1,
> + ATA_SCTL_IPM= 2,
> + ATA_SCTL_SPM= 3,
> + ATA_SCTL_PMP= 4,
> +
> /* SError bits */
> SERR_DATA_RECOVERED
Re: [linux-pm] [demo patch/RFC] sleepy linux
On Tue, 26 Feb 2008 11:26:53 +0100 Pavel Machek wrote:
Hi Pavel,
Is this limited to UP and only one disk?
[comments below]
Sleepy linux support, demo version, but it works on my thinkpad x60 ;-).
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/Documentation/power/sleepy.txt b/Documentation/power/sleepy.txt
new file mode 100644
index 000..a9caf05
--- /dev/null
+++ b/Documentation/power/sleepy.txt
@@ -0,0 +1,55 @@
+ 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
Usually can only do it AFAIK.
+something like 10% of power needed for idle system. Starting suspend
+manually is not too convinient; it is not an option on multiuser
convenient;
+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
Today's
+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
lose
+ 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)
lose
+
+How to use it
+~
+
+First, make sure your config is tiny enough that cpu sleeps at least
CPU (please)
+five or so seconds between wakeups. You'll probably need to disable
+USB, make some kernel timers way longer than default and boot with
+init=/bin/bash.
+
+Then, enable SCSI powersave by something like:
+
+mount /sys
Isn't /sys auto-mounted by kernel?
+echo auto
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/level
+echo 3
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/autosuspend
+echo adisk /sys/power/state
+mount / -oremount,commit=900
+
+Then, echo auto /sys/power/state should enable sleepy support. Do it
+twice, and it will ignore open lid and sleep anyway.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -268,6 +269,41 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+struct sleep_disabled_reason ahci_active = {
+ahci
+};
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev autosuspend_enabled) {
+ printk(ahci: should autosuspend\n);
Use printk() KERN_* levels (multiple places).
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ enable_auto_sleep(ahci_active);
+ return 0;
+ }
+ printk(ahci: autosuspend disabled\n);
+ return -EINVAL;
+}
+
...
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -1820,6 +1858,10 @@ static void ahci_thaw(struct ata_port *a
static void ahci_error_handler(struct ata_port *ap)
{
+ struct ata_host *host = ap-host;
+ int rc;
+ extern int slept;
Eh?
+
if (!(ap-pflags ATA_PFLAG_FROZEN)) {
/* restart engine */
ahci_stop_engine(ap);
General comment: Lots of the comment fixes in libata should be part
of a standalone patch, not part of this patch.
diff --git a/include/linux/ata.h b/include/linux/ata.h
index 78bbaca..df2dd4f 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -298,6 +298,13 @@ enum {
SCR_ACTIVE = 3,
SCR_NOTIFICATION= 4,
+ /* SControl subfields, each field is 4 bit wide */
bits
+ ATA_SCTL_DET= 0, /* lsb */
+ ATA_SCTL_SPD= 1,
+ ATA_SCTL_IPM= 2,
+ ATA_SCTL_SPM= 3,
+ ATA_SCTL_PMP= 4,
+
/* SError bits */
SERR_DATA_RECOVERED = (1 0), /* recovered data error */
SERR_COMM_RECOVERED = (1 1), /* recovered comm failure */
diff --git a/kernel/power/main.c
[demo patch/RFC] sleepy linux
Sleepy linux support, demo version, but it works on my thinkpad x60 ;-).
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/Documentation/power/sleepy.txt b/Documentation/power/sleepy.txt
new file mode 100644
index 000..a9caf05
--- /dev/null
+++ b/Documentation/power/sleepy.txt
@@ -0,0 +1,55 @@
+ 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)
+
+How to use it
+~
+
+First, make sure your config is tiny enough that cpu sleeps at least
+five or so seconds between wakeups. You'll probably need to disable
+USB, make some kernel timers way longer than default and boot with
+init=/bin/bash.
+
+Then, enable SCSI powersave by something like:
+
+mount /sys
+echo auto
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/level
+echo 3
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/autosuspend
+echo adisk /sys/power/state
+mount / -oremount,commit=900
+
+Then, echo auto /sys/power/state should enable sleepy support. Do it
+twice, and it will ignore open lid and sleep anyway.
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a7d50a5..4c25613 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -187,6 +187,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -32,6 +32,7 @@
*
*/
+#define DEBUG
#include linux/kernel.h
#include linux/module.h
#include linux/pci.h
@@ -259,8 +260,8 @@ static void ahci_fill_cmd_slot(struct ah
u32 opts);
#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
-static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
-static int ahci_pci_device_resume(struct pci_dev *pdev);
+int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
+int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
static struct class_device_attribute *ahci_shost_attrs[] = {
@@ -268,6 +269,41 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+struct sleep_disabled_reason ahci_active = {
+ahci
+};
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev autosuspend_enabled) {
+ printk(ahci: should autosuspend\n);
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ enable_auto_sleep(ahci_active);
+ return 0;
+ }
+ printk(ahci: autosuspend disabled\n);
+ return -EINVAL;
+}
+
+/* The host needs to be autoresumed */
+static int autoresume(struct Scsi_Host *host)
+{
+ if (my_pdev autosuspend_enabled) {
+ printk(ahci: should autoresume\n);
+ disable_auto_sleep(ahci_active);
+ ahci_pci_device_resume(my_pdev);
+ return 0;
+ }
+ printk(ahci: autoresume disabled\n);
+ return -EINVAL;
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -286,6 +322,8 @@ static struct scsi_host_template ahci_sh
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
.shost_attrs= ahci_shost_attrs,
+ .autosuspend= autosuspend,
+
Re: [RFC] sleepy linux
Hi! > > > > 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... > > 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. Well, I can give you a three liner, and if it stops working, I'll treat is as a regression, because userland ABI changed...? Or you can get about 10 lines of C, no problem, but I do not think that should be merged to Linus. > > > 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. I do not think TCP would survive "10 seconds sleep, 1 second up". But... > (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?) ...yes, we should probably play with the routers. > but if it's nothing else but a s2ram debug/stress utility, that alone > would be great too :-) I expect to stress s2ram way too much ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
* Pavel Machek <[EMAIL PROTECTED]> wrote: > > 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... 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. > > 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 :-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
* Pavel Machek [EMAIL PROTECTED] wrote: 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... 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. 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 :-) Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! 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... 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. Well, I can give you a three liner, and if it stops working, I'll treat is as a regression, because userland ABI changed...? Or you can get about 10 lines of C, no problem, but I do not think that should be merged to Linus. 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. I do not think TCP would survive 10 seconds sleep, 1 second up. But... (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?) ...yes, we should probably play with the routers. but if it's nothing else but a s2ram debug/stress utility, that alone would be great too :-) I expect to stress s2ram way too much ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Sun 2007-12-30 12:15:52, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > 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. Hmm, are you sure it is good idea to do this from kernel? I guess this is better done from script... > 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 :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Sun 2007-12-30 12:15:52, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: 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. Hmm, are you sure it is good idea to do this from kernel? I guess this is better done from script... 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 :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Montag, 31. Dezember 2007 15:44:47 schrieb Pavel Machek: > On Sun 2007-12-30 17:39:42, Oliver Neukum wrote: > > 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). But we are always racing against hardware in these cases. Strictly speaking you cannot have pure userland request. If no task is runnable and no timer about to fire any activity will require kernel activity unless you are doing direct hardware access from user space which in the generic case precludes suspension anyway. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Montag, 31. Dezember 2007 15:44:47 schrieb Pavel Machek: On Sun 2007-12-30 17:39:42, Oliver Neukum wrote: 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). But we are always racing against hardware in these cases. Strictly speaking you cannot have pure userland request. If no task is runnable and no timer about to fire any activity will require kernel activity unless you are doing direct hardware access from user space which in the generic case precludes suspension anyway. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Sun 2007-12-30 17:39:42, Oliver Neukum wrote: > Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek: > > Hi! > > > > > > ... 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). > > 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? 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). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Sun 2007-12-30 17:39:42, Oliver Neukum wrote: Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek: Hi! ... 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). 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? 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). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek: > Hi! > > > > ... 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). 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? [..] > > 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. This mainly means input devices. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
* Pavel Machek <[EMAIL PROTECTED]> wrote: > 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? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
* Pavel Machek [EMAIL PROTECTED] wrote: 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? Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek: Hi! ... 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). 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? [..] 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. This mainly means input devices. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! > > ... 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). > > 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? Yes. > > 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. Yes, we'll need to add some userland interfaces. No, this will not be easy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! > > > > 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. > > > > 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. Hmm, right. Driver probably should have chance to autosuspend but tell the core that whole system probably should not sleep... Hmm Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! > >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 > > 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. Plus, it is probably mandatory if you want EnergyStar logo ... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! 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 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. Plus, it is probably mandatory if you want EnergyStar logo ... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! 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. 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. Hmm, right. Driver probably should have chance to autosuspend but tell the core that whole system probably should not sleep... Hmm Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Hi! ... 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). 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? Yes. 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. Yes, we'll need to add some userland interfaces. No, this will not be easy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:32:58 schrieb Pavel Machek: > ... 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. > 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? > 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. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:32:58 schrieb Pavel Machek: ... 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. 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? 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. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:32:58 schrieb Pavel Machek: > On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: > > Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > > > 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. > > 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. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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 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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: > Oliver Neukum wrote: >> Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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. Heck, I'm constantly frustrated by every distro upgrade breaking power management for my monitor. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > > > 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. > > > > 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. 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... > > I guess I need to know from atomic context :-(. > > Urgh. suspend() must be able to sleep and can fail. That's ok. ... 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [RFC] sleepy linux
Hi, On Wed, 2007-12-26 at 00:07 +0100, ext Pavel Machek wrote: > 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 Why can't these cases be based on CPUIdle? > 3) You can sleep now, but wake me up in 8:30 with mp3 player This is about setting up properly the wakeup sources which means: - the wakeup source is really capable of generating wakeups for the target idle state - the wakeup source is not actually capable of genrating wakeups from the target idle state, which can be solved in 2 ways: - if the duration of the activity is known, set up an alarm (assuming alarms are proper wakeup sources) so that the system is ready just in time, in a less efficient but more responsive power saving state - if the duration of the activity is unknown choose the more efficient amongst the following solutions: - go to deep sleep state and periodically wakeup and poll, with a period compatible with the timing of the event source - prevent too deep sleep states till the event happens > 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. It might be that some hw doesn't provide deep power saving state for some devices, but if the only missing feature is the wakeup capability, it could be effectively replaced by some HW timer. > 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) These are just few system specific case, but if you start including USB devices, the situation is going to get quite complicated very soon, if you explicitly include certain HW devices in your model. -- Cheers, Igor Igor Stoppa <[EMAIL PROTECTED]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > > 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. > > 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? > I guess I need to know from atomic context :-(. Urgh. suspend() must be able to sleep and can fail. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > 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. Is there an easy way to tell if all the devices are runtime suspended? I guess I need to know from atomic context :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: > > 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. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: 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 You've just eliminated 90%+ of the available Ethernet infrastructure. However, there may be Ethernet controllers which can do something smart with incoming packets, and perhaps more importantly, we can always write a spec and try to push it to Intel, Broadcom, Realtek and Nvidia. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > 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. Pretty much, except that "timer device" needs to be runtime suspended, too... We probably should not sleep if wakeup is scheduled 1 second in future. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 10:56:59, H. Peter Anvin wrote: > Pavel Machek wrote: >> 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: 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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > 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. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: 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. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: 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. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 10:56:59, H. Peter Anvin wrote: Pavel Machek wrote: 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: 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. Pretty much, except that timer device needs to be runtime suspended, too... We probably should not sleep if wakeup is scheduled 1 second in future. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: 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 You've just eliminated 90%+ of the available Ethernet infrastructure. However, there may be Ethernet controllers which can do something smart with incoming packets, and perhaps more importantly, we can always write a spec and try to push it to Intel, Broadcom, Realtek and Nvidia. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: 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. Is there an easy way to tell if all the devices are runtime suspended? I guess I need to know from atomic context :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: 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. 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? I guess I need to know from atomic context :-(. Urgh. suspend() must be able to sleep and can fail. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [RFC] sleepy linux
Hi, On Wed, 2007-12-26 at 00:07 +0100, ext Pavel Machek wrote: 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 Why can't these cases be based on CPUIdle? 3) You can sleep now, but wake me up in 8:30 with mp3 player This is about setting up properly the wakeup sources which means: - the wakeup source is really capable of generating wakeups for the target idle state - the wakeup source is not actually capable of genrating wakeups from the target idle state, which can be solved in 2 ways: - if the duration of the activity is known, set up an alarm (assuming alarms are proper wakeup sources) so that the system is ready just in time, in a less efficient but more responsive power saving state - if the duration of the activity is unknown choose the more efficient amongst the following solutions: - go to deep sleep state and periodically wakeup and poll, with a period compatible with the timing of the event source - prevent too deep sleep states till the event happens 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. It might be that some hw doesn't provide deep power saving state for some devices, but if the only missing feature is the wakeup capability, it could be effectively replaced by some HW timer. 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) These are just few system specific case, but if you start including USB devices, the situation is going to get quite complicated very soon, if you explicitly include certain HW devices in your model. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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. Heck, I'm constantly frustrated by every distro upgrade breaking power management for my monitor. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 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 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. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: 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. 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. 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... I guess I need to know from atomic context :-(. Urgh. suspend() must be able to sleep and can fail. That's ok. ... 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:32:58 schrieb Pavel Machek: On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: 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. 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. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] sleepy linux
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)
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 9663c2a..0f65aa9 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -178,6 +178,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/input/input-polldev.c b/drivers/input/input-polldev.c
index 92b3598..83a8046 100644
--- a/drivers/input/input-polldev.c
+++ b/drivers/input/input-polldev.c
@@ -151,7 +151,7 @@ int input_register_polled_device(struct
INIT_DELAYED_WORK(>work, input_polled_device_work);
if (!dev->poll_interval)
- dev->poll_interval = 500;
+ dev->poll_interval = 5;
input->private = dev;
input->open = input_open_polled_device;
input->close = input_close_polled_device;
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 307c7b5..2deca60 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -263,8 +263,14 @@ void input_event(struct input_dev *dev,
{
unsigned long flags;
- if (is_event_supported(type, dev->evbit, EV_MAX)) {
+ if ((type == EV_SW) && (code == SW_LID)) {
+ int is_closed = value;
+ printk("LID: %d\n", value);
+ if (is_closed) atomic_dec(_needed);
+ else atomic_inc(_needed);
+ }
+ if (is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(>event_lock, flags);
add_input_randomness(type, code, value);
input_handle_event(dev, type, code, value);
@@ -1575,6 +1581,8 @@ static int __init input_init(void)
goto fail2;
}
+ /* FIXME: should only inc it if LID is open */
+ atomic_inc(_needed);
return 0;
fail2:input_proc_exit();
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 2ae0e83..ba5e806 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -149,16 +149,6 @@ rtc_sysfs_set_wakealarm(struct device *d
alarm = simple_strtoul(buf, NULL, 0);
if (alarm > now) {
- /* Avoid accidentally clobbering active alarms; we can't
-* entirely prevent that here, without even the minimal
-* locking from the /dev/rtcN api.
-*/
- retval = rtc_read_alarm(rtc, );
- if (retval < 0)
- return retval;
- if (alm.enabled)
- return -EBUSY;
-
alm.enabled = 1;
} else {
alm.enabled = 0;
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 09a309b..991af06 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -246,6 +246,10 @@ #define device_init_wakeup(dev,val) \
device_set_wakeup_enable(dev,val); \
} while(0)
+void detect_idle(void);
+void enter_auto_sleep(void);
+extern atomic_t cpu_needed;
+
#endif /* __KERNEL__ */
#endif /* _LINUX_PM_H */
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 3cdf95b..fc1c7c1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -22,6 +22,8 @@ #include
#include
#include
+#include
+
#include "power.h"
BLOCKING_NOTIFIER_HEAD(pm_chain_head);
@@ -145,6 +147,8 @@
[RFC] sleepy linux
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)
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 9663c2a..0f65aa9 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -178,6 +178,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/input/input-polldev.c b/drivers/input/input-polldev.c
index 92b3598..83a8046 100644
--- a/drivers/input/input-polldev.c
+++ b/drivers/input/input-polldev.c
@@ -151,7 +151,7 @@ int input_register_polled_device(struct
INIT_DELAYED_WORK(dev-work, input_polled_device_work);
if (!dev-poll_interval)
- dev-poll_interval = 500;
+ dev-poll_interval = 5;
input-private = dev;
input-open = input_open_polled_device;
input-close = input_close_polled_device;
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 307c7b5..2deca60 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -263,8 +263,14 @@ void input_event(struct input_dev *dev,
{
unsigned long flags;
- if (is_event_supported(type, dev-evbit, EV_MAX)) {
+ if ((type == EV_SW) (code == SW_LID)) {
+ int is_closed = value;
+ printk(LID: %d\n, value);
+ if (is_closed) atomic_dec(cpu_needed);
+ else atomic_inc(cpu_needed);
+ }
+ if (is_event_supported(type, dev-evbit, EV_MAX)) {
spin_lock_irqsave(dev-event_lock, flags);
add_input_randomness(type, code, value);
input_handle_event(dev, type, code, value);
@@ -1575,6 +1581,8 @@ static int __init input_init(void)
goto fail2;
}
+ /* FIXME: should only inc it if LID is open */
+ atomic_inc(cpu_needed);
return 0;
fail2:input_proc_exit();
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 2ae0e83..ba5e806 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -149,16 +149,6 @@ rtc_sysfs_set_wakealarm(struct device *d
alarm = simple_strtoul(buf, NULL, 0);
if (alarm now) {
- /* Avoid accidentally clobbering active alarms; we can't
-* entirely prevent that here, without even the minimal
-* locking from the /dev/rtcN api.
-*/
- retval = rtc_read_alarm(rtc, alm);
- if (retval 0)
- return retval;
- if (alm.enabled)
- return -EBUSY;
-
alm.enabled = 1;
} else {
alm.enabled = 0;
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 09a309b..991af06 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -246,6 +246,10 @@ #define device_init_wakeup(dev,val) \
device_set_wakeup_enable(dev,val); \
} while(0)
+void detect_idle(void);
+void enter_auto_sleep(void);
+extern atomic_t cpu_needed;
+
#endif /* __KERNEL__ */
#endif /* _LINUX_PM_H */
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 3cdf95b..fc1c7c1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -22,6 +22,8 @@ #include linux/freezer.h
#include linux/vmstat.h
#include linux/syscalls.h
+#include asm/percpu.h
+
#include power.h
