From: Pavel Machek <pavel@...>
Subject: [RFC] sleepy linux
Date: Dec 25, 7:07 pm 2007

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

	  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 = 50000;

 	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

 #include

 #include 
+#include

+

 #include "power.h"
 BLOCKING_NOTIFIER_HEAD(pm_chain_head);

@@ -145,6 +147,8 @@ static int suspend_enter(suspend_state_t

  *	suspend_devices_and_enter - suspend devices and enter the desired system sleep

  *			  state.

  *	@state:		  state to enter

+ *

+ *	Needs to be called from process state and may sleep.

  */

 int suspend_devices_and_enter(suspend_state_t state)

 {

@@ -224,6 +228,8 @@ static inline int valid_state(suspend_st

  *	happen when we wake up.

  *	Then, do the setup for suspend, enter the state, and cleaup (after

  *	we've woken up).

+ *

+ *	Needs to be called from process context, and may sleep.

  */

 static int enter_state(suspend_state_t state)

 {

@@ -253,6 +259,40 @@ static int enter_state(suspend_state_t s

 	return error;

 }
+/* Returns how long it waited in ms */

+//extern long (*panic_blink)(long time);

+

+int slept;

+

+int

+do_auto_sleep(void)

+{

+	int error,i;

+	int state = PM_SUSPEND_MEM;

+

+	if (slept)

+		return;

+	slept++;

+	suspend_enter(state);

+

+	for (i=0; i<10; i++) {

+		panic_blink(10);

+		mdelay(100);

+	}

+

+//	if (suspend_ops->finish)

+//		suspend_ops->finish();

+

+	return 0;

+}

+

+void

+enter_auto_sleep(void)

+{

+	int error = do_auto_sleep();

+	if (error)

+		printk("enter auto sleep failed: %d\n", error);

+}
 /**

  *	pm_suspend - Externally visible function for suspending system.

@@ -321,6 +361,30 @@ #endif

 	p = memchr(buf, '\n', n);

 	len = p ? p - buf : n;
+	if (len == 4 && !strncmp(buf, "auto", len)) {

+		static int acpi_ready = 0;

+		if (!acpi_ready) {

+			int error;

+			int state = PM_SUSPEND_MEM;

+

+			if (suspend_ops->set_target) {

+				error = suspend_ops->set_target(state);

+				if (error)

+					return error;

+			}

+

+			if (suspend_ops->prepare) {

+				error = suspend_ops->prepare();

+				if (error)

+					return error;

+			}

+			acpi_ready = 1;

+		}

+		atomic_dec(&cpu_needed);

+		error = 0;

+  goto Exit;

+	}

+

 	/* First, check if we are requested to hibernate */

 	if (len == 4 && !strncmp(buf, "disk", len)) {

 		error = hibernate();

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c

index cb89fa8..456a662 100644

--- a/kernel/time/tick-sched.c

+++ b/kernel/time/tick-sched.c

@@ -9,7 +9,7 @@

  *

  *  Started by: Thomas Gleixner and Ingo Molnar

  *

- *  For licencing details see kernel-base/COPYING

+ *  Distribute under GPLv2.

  */

 #include

 #include

@@ -502,7 +508,7 @@ #endif /* NO_HZ */

  */

 #ifdef CONFIG_HIGH_RES_TIMERS

 /*

- * We rearm the timer until we get disabled by the idle code

+ * We rearm the timer until we get disabled by the idle code.

  * Called with interrupts disabled and timer->base->cpu_base->lock held.

  */

 static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)

diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c

index 12c5f4c..645ec51 100644

--- a/kernel/time/timer_list.c

+++ b/kernel/time/timer_list.c

@@ -65,9 +65,9 @@ #ifdef CONFIG_TIMER_STATS

 	SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);

 #endif

 	SEQ_printf(m, "\n");

-	SEQ_printf(m, " # expires at %Lu nsecs [in %Lu nsecs]\n",

+	SEQ_printf(m, " # expires at %Lu nsecs [in %Ld nsecs]\n",

 		(unsigned long long)ktime_to_ns(timer->expires),

-		(unsigned long long)(ktime_to_ns(timer->expires) - now));

+		(long long)(ktime_to_ns(timer->expires) - now));

 }
 static void

@@ -285,3 +285,82 @@ static int __init init_timer_list_procfs

 	return 0;

 }

 __initcall(init_timer_list_procfs);

+

+/*

+ * Sleepy linux support

+ */

+

+#include

+#include

+

+atomic_t cpu_needed = ATOMIC_INIT(1);

+

+static s64

+detect_active_timers(struct hrtimer_clock_base *base, s64 first_timer)

+{

+	struct hrtimer *timer, tmp;

+	unsigned long next = 0, i;

+	struct rb_node *curr;

+	unsigned long flags;

+

+next_one:

+	i = 0;

+	spin_lock_irqsave(&base->cpu_base->lock, flags);

+

+	curr = base->first;

+	/*

+	 * Crude but we have to do this O(N*N) thing, because

+	 * we have to unlock the base when printing:

+	 */

+	while (curr && i < next) {

+		curr = rb_next(curr);

+		i++;

+	}

+

+	if (curr) {

+		timer = rb_entry(curr, struct hrtimer, node);

+		tmp = *timer;

+		spin_unlock_irqrestore(&base->cpu_base->lock, flags);

+

+//		printk("[%Ld]", ktime_to_ns(tmp.expires));

+		first_timer = min_t(s64, first_timer, ktime_to_ns(tmp.expires));

+

+		next++;

+		goto next_one;

+	}

+	spin_unlock_irqrestore(&base->cpu_base->lock, flags);

+	return first_timer;

+}

+

+void detect_idle(void)

+{

+	int i;

+	s64 first_timer = (3600ULL*NSEC_PER_SEC);

+	int cpu;

+	s64 now;

+

+	if (num_online_cpus() != 1)

+		return;

+

+	for_each_online_cpu(cpu) {

+		struct hrtimer_cpu_base *cpu_base = &per_cpu(hrtimer_bases, cpu);

+		for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {

+//			printk("_");

+			first_timer = detect_active_timers(cpu_base->clock_base + i, first_timer);

+		}

+	}

+	now = ktime_to_ns(ktime_get());

+	if (first_timer ==3600ULL*NSEC_PER_SEC) {

+		printk("nohz: No timers at all?!\n");

+		if (!atomic_read(&cpu_needed)) {

+			printk("Auto sleep\n");

+			enter_auto_sleep();

+		}

+	} else if (first_timer > (now + 3ULL*NSEC_PER_SEC)) {

+		printk("nohz: Ready for ~ %Ld msec wait, %d\n", (long long) first_timer - (long long) now, atomic_read(&cpu_needed));

+		if (!atomic_read(&cpu_needed)) {

+			printk("Auto sleep\n");

+			enter_auto_sleep();

+		}

+	}

+}

diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c

index c36bb7e..417da8c 100644

--- a/kernel/time/timer_stats.c

+++ b/kernel/time/timer_stats.c

@@ -26,7 +26,7 @@

  * the pid and cmdline from the owner process if applicable.

  *

  * Start/stop data collection:

- * # echo 1[0] >/proc/timer_stats

+ * # echo [1|0] >/proc/timer_stats

  *

  * Display the information collected so far:

  * # cat /proc/timer_stats

diff --git a/kernel/workqueue.c b/kernel/workqueue.c

index 52d5e7c..dc7f748 100644

--- a/kernel/workqueue.c

+++ b/kernel/workqueue.c

@@ -220,6 +220,7 @@ int queue_delayed_work_on(int cpu, struc

 	struct timer_list *timer = &dwork->timer;

 	struct work_struct *work = &dwork->work;
+	timer_stats_timer_set_start_info(&dwork->timer);

 	if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {

 		BUG_ON(timer_pending(timer));

 		BUG_ON(!list_empty(&work->entry));

@@ -581,6 +582,7 @@ EXPORT_SYMBOL(schedule_delayed_work);

 int schedule_delayed_work_on(int cpu,

 			struct delayed_work *dwork, unsigned long delay)

 {

+	timer_stats_timer_set_start_info(&dwork->timer);

 	return queue_delayed_work_on(cpu, keventd_wq, dwork, delay);

 }

 EXPORT_SYMBOL(schedule_delayed_work_on);

diff --git a/mm/slab.c b/mm/slab.c

index 2e338a5..8a5d988 100644

--- a/mm/slab.c

+++ b/mm/slab.c

@@ -945,7 +945,7 @@ static void __cpuinit start_cpu_timer(in

 		init_reap_node(cpu);

 		INIT_DELAYED_WORK(reap_work, cache_reap);

 		schedule_delayed_work_on(cpu, reap_work,

-					__round_jiffies_relative(HZ, cpu));

+					 __round_jiffies_relative(HZ*10000, cpu)); /* FIXME !*/

 	}

 }
diff --git a/mm/vmstat.c b/mm/vmstat.c

index e8d846f..7fd3dbb 100644

--- a/mm/vmstat.c

+++ b/mm/vmstat.c

@@ -794,7 +794,7 @@ #endif /* CONFIG_PROC_FS */
 #ifdef CONFIG_SMP

 static DEFINE_PER_CPU(struct delayed_work, vmstat_work);

-int sysctl_stat_interval __read_mostly = HZ;

+int sysctl_stat_interval __read_mostly = 10000 * HZ;
 static void vmstat_update(struct work_struct *w)

 {
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

From: H. Peter Anvin <hpa@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 2:56 pm 2007

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

--



From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:08 pm 2007

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
--



From: H. Peter Anvin <hpa@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:43 pm 2007

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

--



From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:51 pm 2007

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

--



From: H. Peter Anvin <hpa@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:54 pm 2007

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

--

From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 3:00 pm 2007

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

--



From: H. Peter Anvin <hpa@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 3:22 pm 2007

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

--

From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 1:28 pm 2007

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
--



From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:17 pm 2007

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

--



From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:23 pm 2007

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

--



From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 26, 4:32 pm 2007

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

--



From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 27, 5:41 am 2007

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

--



From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 29, 7:51 pm 2007

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

--



From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 30, 12:39 pm 2007

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

--



From: Pavel Machek <pavel@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 31, 10:44 am 2007

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

--



From: Oliver Neukum <oliver@...>
Subject: Re: [RFC] sleepy linux
Date: Jan 2, 6:52 am 2008

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

--

From: Ingo Molnar <mingo@...>
Subject: Re: [RFC] sleepy linux
Date: Dec 30, 7:15 am 2007

* Pavel Machek  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

--