[PATCH 0/8] Suspend block api (version 8)

[PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

This patch series adds a suspend-block api that provides the same
functionality as the android wakelock api. This version adds a
delay before suspending again if no suspend blockers were used
during the last suspend attempt.

--
Arve Hjønnevåg <arve@android.com>

[PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android.  The problem is that to save maximum amount of energy
all system hardware components need to be in the lowest-power states
available for as long as reasonably possible, but at the same time the
system must always respond to certain events, regardless of the
current state of the hardware.

The first goal can be achieved either by using device runtime PM and
cpuidle to put all hardware into low-power states, transparently from
the user space point of view, or by suspending the whole system.
However, system suspend, in its current form, does not guarantee that
the events of interest will always be responded to, since wakeup
events (events that wake the CPU from idle and the system from
suspend) that occur right after initiating suspend will not be
processed until another possibly unrelated event wakes the system up
again.

On hardware where idle can enter the same power state as suspend, idle
combined with runtime PM can be used, but periodic wakeups increase
the average power consumption. Suspending the system also reduces the
harm caused by apps that never go idle. There also are systems where
some devices cannot be put into low-power states without suspending
the entire system (or the low-power states available to them without
suspending the entire system are substantially shallower than the
low-power states they are put into when the entire system is
suspended), so the system has to be suspended as a whole to achieve
the maximum energy savings.

To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, introduce a mechanism by
which the system is automatically suspended (i.e. put into a
system-wide sleep state) whenever it's not doing work that's
immediately useful to the user, called opportunistic suspend.

For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to
suspend the system (i.e. when the system is not doing anything the
user really cares about at the moment and therefore it may be
suspended). Add an API that that drivers can use to block
opportunistic suspend. This is needed to avoid losing wakeup events
that occur right after suspend is initiated.

Add /sys/power/policy that selects the behavior of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/opportunistic-suspend.txt |  129 +++++++++++
 include/linux/suspend.h                       |    1 +
 include/linux/suspend_blocker.h               |   74 ++++++
 kernel/power/Kconfig                          |   16 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/main.c                           |  128 ++++++++++-
 kernel/power/opportunistic_suspend.c          |  298 +++++++++++++++++++++++++
 kernel/power/power.h                          |    9 +
 kernel/power/suspend.c                        |    3 +-
 9 files changed, 651 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/power/opportunistic-suspend.txt
 create mode 100755 include/linux/suspend_blocker.h
 create mode 100644 kernel/power/opportunistic_suspend.c

diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
new file mode 100644
index 0000000..4bee7bc
--- /dev/null
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -0,0 +1,129 @@
+Opportunistic Suspend
+=====================
+
+Opportunistic suspend is a feature allowing the system to be suspended (ie. put
+into one of the available sleep states) automatically whenever it is regarded
+as idle.  The suspend blockers framework described below is used to determine
+when that happens.
+
+The /sys/power/policy sysfs attribute is used to switch the system between the
+opportunistic and "forced" suspend behavior, where in the latter case the
+system is only suspended if a specific value, corresponding to one of the
+available system sleep states, is written into /sys/power/state.  However, in
+the former, opportunistic, case the system is put into the sleep state
+corresponding to the value written to /sys/power/state whenever there are no
+active suspend blockers. The default policy is "forced". Also, suspend blockers
+do not affect sleep states entered from idle.
+
+When the policy is "opportunisic", there is a special value, "on", that can be
+written to /sys/power/state. This will block the automatic sleep request, as if
+a suspend blocker was used by a device driver. This way the opportunistic
+suspend may be blocked by user space whithout switching back to the "forced"
+mode.
+
+A suspend blocker is an object used to inform the PM subsystem when the system
+can or cannot be suspended in the "opportunistic" mode (the "forced" mode
+ignores suspend blockers).  To use it, a device driver creates a struct
+suspend_blocker that must be initialized with suspend_blocker_init(). Before
+freeing the suspend_blocker structure or its name, suspend_blocker_unregister()
+must be called on it.
+
+A suspend blocker is activated using suspend_block(), which prevents the PM
+subsystem from putting the system into the requested sleep state in the
+"opportunistic" mode until the suspend blocker is deactivated with
+suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
+the system will not suspend as long as at least one of them is active.
+
+If opportunistic suspend is already in progress when suspend_block() is called,
+it will abort the suspend, unless suspend_ops->enter has already been
+executed. If suspend is aborted this way, the system is usually not fully
+operational at that point. The suspend callbacks of some drivers may still be
+running and it usually takes time to restore the system to the fully operational
+state.
+
+Here's an example showing how a cell phone or other embedded system can handle
+keystrokes (or other input events) in the presence of suspend blockers. Use
+set_irq_wake or a platform specific API to make sure the keypad interrupt wakes
+up the cpu. Once the keypad driver has resumed, the sequence of events can look
+like this:
+
+- The Keypad driver gets an interrupt. It then calls suspend_block on the
+  keypad-scan suspend_blocker and starts scanning the keypad matrix.
+- The keypad-scan code detects a key change and reports it to the input-event
+  driver.
+- The input-event driver sees the key change, enqueues an event, and calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should be ignored, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.
+
+If the key that was pressed instead should preform a simple action (for example,
+adjusting the volume), this action can be performed right before calling
+suspend_unblock on the process_input_events suspend_blocker. However, if the key
+triggers a longer-running action, that action needs its own suspend_blocker and
+suspend_block must be called on that suspend blocker before calling
+suspend_unblock on the process_input_events suspend_blocker.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block API by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init(). For instance:
+
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, name);
+}
+
+If the suspend_blocker variable is allocated statically,
+DEFINE_SUSPEND_BLOCKER() should be used to initialize it, for example:
+
+static DEFINE_SUSPEND_BLOCKER(blocker, name);
+
+and suspend_blocker_register(&blocker) has to be called to make the suspend
+blocker usable.
+
+Before freeing the memory in which a suspend_blocker variable is located,
+suspend_blocker_unregister() must be called, for instance:
+
+uninit() {
+	suspend_blocker_unregister(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block():
+
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock():
+
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block() when the suspend blocker is active or suspend_unblock()
+when it is not active has no effect (i.e., these functions don't nest). This
+allows drivers to update their state and call suspend suspend_block() or
+suspend_unblock() based on the result. For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..07023d3 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -6,6 +6,7 @@
 #include <linux/init.h>
 #include <linux/pm.h>
 #include <linux/mm.h>
+#include <linux/suspend_blocker.h>
 #include <asm/errno.h>
 
 #if defined(CONFIG_PM_SLEEP) && defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE)
diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
new file mode 100755
index 0000000..8788302
--- /dev/null
+++ b/include/linux/suspend_blocker.h
@@ -0,0 +1,74 @@
+/* include/linux/suspend_blocker.h
+ *
+ * Copyright (C) 2007-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_SUSPEND_BLOCKER_H
+#define _LINUX_SUSPEND_BLOCKER_H
+
+#include <linux/list.h>
+
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @link: List entry for active or inactive list.
+ * @flags: Tracks initialized and active state.
+ * @name: Suspend blocker name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * opportunistic suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
+ */
+struct suspend_blocker {
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct list_head link;
+	int flags;
+	const char *name;
+#endif
+};
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+#define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
+	{ .name = #blocker_name, }
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker = __SUSPEND_BLOCKER_INITIALIZER(name)
+
+extern void suspend_blocker_register(struct suspend_blocker *blocker);
+extern void suspend_blocker_init(struct suspend_blocker *blocker,
+				 const char *name);
+extern void suspend_blocker_unregister(struct suspend_blocker *blocker);
+extern void suspend_block(struct suspend_blocker *blocker);
+extern void suspend_unblock(struct suspend_blocker *blocker);
+extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
+extern bool suspend_is_blocked(void);
+
+#else
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker
+
+static inline void suspend_blocker_register(struct suspend_blocker *bl) {}
+static inline void suspend_blocker_init(struct suspend_blocker *bl,
+					const char *n) {}
+static inline void suspend_blocker_unregister(struct suspend_blocker *bl) {}
+static inline void suspend_block(struct suspend_blocker *bl) {}
+static inline void suspend_unblock(struct suspend_blocker *bl) {}
+static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
+{
+	return false;
+}
+static inline bool suspend_is_blocked(void) { return false; }
+#endif
+
+#endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5c36ea9..6d11a45 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -130,6 +130,22 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config OPPORTUNISTIC_SUSPEND
+	bool "Opportunistic suspend"
+	depends on SUSPEND
+	select RTC_LIB
+	default n
+	---help---
+	  Opportunistic sleep support.  Allows the system to be put into a sleep
+	  state opportunistically, if it doesn't do any useful work at the
+	  moment. The PM subsystem is switched into this mode of operation by
+	  writing "opportunistic" into /sys/power/policy, while writing
+	  "forced" to this file turns the opportunistic suspend feature off.
+	  In the "opportunistic" mode suspend blockers are used to determine
+	  when to suspend the system and the value written to /sys/power/state
+	  determines the sleep state the system will be put into when there are
+	  no active suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4319181..95d8e6d 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
+obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/main.c b/kernel/power/main.c
index b58800b..afbb4dd 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -20,6 +20,58 @@ DEFINE_MUTEX(pm_mutex);
 unsigned int pm_flags;
 EXPORT_SYMBOL(pm_flags);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+struct pm_policy {
+	const char *name;
+	bool (*valid_state)(suspend_state_t state);
+	int (*set_state)(suspend_state_t state);
+};
+
+static struct pm_policy policies[] = {
+	{
+		.name		= "forced",
+		.valid_state	= valid_state,
+		.set_state	= enter_state,
+	},
+	{
+		.name		= "opportunistic",
+		.valid_state	= opportunistic_suspend_valid_state,
+		.set_state	= opportunistic_suspend_state,
+	},
+};
+
+static int policy;
+
+static inline bool hibernation_supported(void)
+{
+	return !strncmp(policies[policy].name, "forced", 6);
+}
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && policies[policy].valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return policies[policy].set_state(state_idx);
+}
+
+#else
+
+static inline bool hibernation_supported(void) { return true; }
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return enter_state(state_idx);
+}
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_SLEEP
 
 /* Routines for PM-transition notifications */
@@ -146,6 +198,12 @@ struct kobject *power_kobj;
  *
  *	store() accepts one of those strings, translates it into the 
  *	proper enumerated value, and initiates a suspend transition.
+ *
+ *	If policy is set to opportunistic, store() does not block until the
+ *	system resumes, and it will try to re-enter the state until another
+ *	state is requested. Suspend blockers are respected and the requested
+ *	state will only be entered when no suspend blockers are active.
+ *	Write "on" to disable.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
@@ -155,12 +213,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 
 	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
+		if (pm_state_valid(i))
 			s += sprintf(s,"%s ", pm_states[i]);
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (hibernation_supported())
+		s += sprintf(s, "%s\n", "disk");
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
@@ -173,7 +232,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_ON;
 	const char * const *s;
 #endif
 	char *p;
@@ -185,8 +244,9 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 	/* First, check if we are requested to hibernate */
 	if (len == 4 && !strncmp(buf, "disk", len)) {
-		error = hibernate();
-  goto Exit;
+		if (hibernation_supported())
+			error = hibernate();
+		goto Exit;
 	}
 
 #ifdef CONFIG_SUSPEND
@@ -195,7 +255,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
-		error = enter_state(state);
+		error = pm_enter_state(state);
 #endif
 
  Exit:
@@ -204,6 +264,56 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/**
+ *	policy - set policy for state
+ */
+static ssize_t policy_show(struct kobject *kobj,
+			   struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		if (i == policy)
+			s += sprintf(s, "[%s] ", policies[i].name);
+		else
+			s += sprintf(s, "%s ", policies[i].name);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t policy_store(struct kobject *kobj,
+			    struct kobj_attribute *attr,
+			    const char *buf, size_t n)
+{
+	const char *s;
+	char *p;
+	int len;
+	int i;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		s = policies[i].name;
+		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
+			mutex_lock(&pm_mutex);
+			policies[policy].set_state(PM_SUSPEND_ON);
+			policy = i;
+			mutex_unlock(&pm_mutex);
+			return n;
+		}
+	}
+	return -EINVAL;
+}
+
+power_attr(policy);
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -236,6 +346,9 @@ static struct attribute * g[] = {
 #endif
 #ifdef CONFIG_PM_SLEEP
 	&pm_async_attr.attr,
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	&policy_attr.attr,
+#endif
 #ifdef CONFIG_PM_DEBUG
 	&pm_test_attr.attr,
 #endif
@@ -247,7 +360,7 @@ static struct attribute_group attr_group = {
 	.attrs = g,
 };
 
-#ifdef CONFIG_PM_RUNTIME
+#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
 struct workqueue_struct *pm_wq;
 EXPORT_SYMBOL_GPL(pm_wq);
 
@@ -266,6 +379,7 @@ static int __init pm_init(void)
 	int error = pm_start_workqueue();
 	if (error)
 		return error;
+	opportunistic_suspend_init();
 	power_kobj = kobject_create_and_add("power", NULL);
 	if (!power_kobj)
 		return -ENOMEM;
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
new file mode 100644
index 0000000..cc90b60
--- /dev/null
+++ b/kernel/power/opportunistic_suspend.c
@@ -0,0 +1,298 @@
+/*
+ * kernel/power/opportunistic_suspend.c
+ *
+ * Copyright (C) 2005-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/rtc.h>
+#include <linux/suspend.h>
+
+#include "power.h"
+
+extern struct workqueue_struct *pm_wq;
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static int unknown_wakeup_delay_msecs = 500;
+module_param_named(unknown_wakeup_delay_msecs, unknown_wakeup_delay_msecs, int,
+		   S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
+
+static DEFINE_SPINLOCK(list_lock);
+static DEFINE_SPINLOCK(state_lock);
+static LIST_HEAD(inactive_blockers);
+static LIST_HEAD(active_blockers);
+static int current_event_num;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+static DEFINE_SUSPEND_BLOCKER(unknown_wakeup, unknown_wakeups);
+
+#define pr_info_time(fmt, args...) \
+	do { \
+		struct timespec ts; \
+		struct rtc_time tm; \
+		getnstimeofday(&ts); \
+		rtc_time_to_tm(ts.tv_sec, &tm); \
+		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+			args, \
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+	} while (0);
+
+static void print_active_suspend_blockers(void)
+{
+	struct suspend_blocker *blocker;
+
+	list_for_each_entry(blocker, &active_blockers, link)
+		pr_info("PM: Active suspend blocker %s\n", blocker->name);
+}
+
+/**
+ * suspend_is_blocked - Check if there are active suspend blockers.
+ *
+ * Return true if suspend blockers are enabled and there are active suspend
+ * blockers, in which case the system cannot be put to sleep opportunistically.
+ */
+bool suspend_is_blocked(void)
+{
+	return enable_suspend_blockers && !list_empty(&active_blockers);
+}
+
+static void expire_unknown_wakeup(unsigned long data)
+{
+	suspend_unblock(&unknown_wakeup);
+}
+static DEFINE_TIMER(expire_unknown_wakeup_timer, expire_unknown_wakeup, 0, 0);
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = true;
+
+	if (suspend_is_blocked()) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: Automatic suspend aborted\n");
+		goto abort;
+	}
+
+	entry_event_num = current_event_num;
+
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("PM: Automatic suspend\n");
+
+	ret = pm_suspend(requested_suspend_state);
+
+	if (debug_mask & DEBUG_EXIT_SUSPEND)
+		pr_info_time("PM: Automatic suspend exit, ret = %d ", ret);
+
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: pm_suspend() returned with no event\n");
+		suspend_block(&unknown_wakeup);
+		mod_timer(&expire_unknown_wakeup_timer,
+			  msecs_to_jiffies(unknown_wakeup_delay_msecs));
+	}
+
+abort:
+	enable_suspend_blockers = false;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+/**
+ * suspend_blocker_register - Prepare a suspend blocker for being used.
+ * @blocker: Suspend blocker to handle.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_register(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags = 0;
+
+	WARN_ON(!blocker->name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Registering %s\n", __func__, blocker->name);
+
+	blocker->flags = SB_INITIALIZED;
+	INIT_LIST_HEAD(&blocker->link);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&blocker->link, &inactive_blockers);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_register);
+
+/**
+ * suspend_blocker_init - Initialize a suspend blocker's name and register it.
+ * @blocker: Suspend blocker to initialize.
+ * @name:    The name of the suspend blocker to show in debug messages.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	blocker->name = name;
+	suspend_blocker_register(blocker);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_unregister - Unregister a suspend blocker.
+ * @blocker: Suspend blocker to handle.
+ */
+void suspend_blocker_unregister(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags &= ~SB_INITIALIZED;
+	list_del(&blocker->link);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Unregistered %s\n", __func__, blocker->name);
+}
+EXPORT_SYMBOL(suspend_blocker_unregister);
+
+/**
+ * suspend_block - Block system suspend.
+ * @blocker: Suspend blocker to use.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	blocker->flags |= SB_ACTIVE;
+	list_move(&blocker->link, &active_blockers);
+
+	current_event_num++;
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock - Allow system suspend to happen.
+ * @blocker: Suspend blocker to unblock.
+ *
+ * If no other suspend blockers are active, schedule suspend of the system.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	list_move(&blocker->link, &inactive_blockers);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	blocker->flags &= ~(SB_ACTIVE);
+
+	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
+		print_active_suspend_blockers();
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * suspend_blocker_is_active - Test if a suspend blocker is blocking suspend
+ * @blocker: Suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
+ */
+bool suspend_blocker_is_active(struct suspend_blocker *blocker)
+{
+	WARN_ON(!(blocker->flags & SB_INITIALIZED));
+
+	return !!(blocker->flags & SB_ACTIVE);
+}
+EXPORT_SYMBOL(suspend_blocker_is_active);
+
+bool opportunistic_suspend_valid_state(suspend_state_t state)
+{
+	return (state == PM_SUSPEND_ON) || valid_state(state);
+}
+
+int opportunistic_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+
+	if (!opportunistic_suspend_valid_state(state))
+		return -ENODEV;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+
+	if (debug_mask & DEBUG_USER_STATE)
+		pr_info_time("%s: %s (%d->%d) at %lld ", __func__,
+			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			     requested_suspend_state, state,
+			     ktime_to_ns(ktime_get()));
+
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+
+	spin_unlock_irqrestore(&state_lock, irqflags);
+
+	return 0;
+}
+
+void __init opportunistic_suspend_init(void)
+{
+	suspend_blocker_register(&main_suspend_blocker);
+	suspend_block(&main_suspend_blocker);
+	suspend_blocker_register(&unknown_wakeup);
+}
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46c5a26..2e9cfd5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/* kernel/power/opportunistic_suspend.c */
+extern int opportunistic_suspend_state(suspend_state_t state);
+extern bool opportunistic_suspend_valid_state(suspend_state_t state);
+extern void __init opportunistic_suspend_init(void);
+#else
+static inline void opportunistic_suspend_init(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..9eb3876 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -20,6 +20,7 @@
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_ON]		= "on",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -157,7 +158,7 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
 			error = suspend_ops->enter(state);
 		sysdev_resume();
 	}
-- 
1.6.5.1

[PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

Power management features present in the current mainline kernel are
insufficient to get maximum possible energy savings on some platforms,
such as Android.  The problem is that to save maximum amount of energy
all system hardware components need to be in the lowest-power states
available for as long as reasonably possible, but at the same time the
system must always respond to certain events, regardless of the
current state of the hardware.

The first goal can be achieved either by using device runtime PM and
cpuidle to put all hardware into low-power states, transparently from
the user space point of view, or by suspending the whole system.
However, system suspend, in its current form, does not guarantee that
the events of interest will always be responded to, since wakeup
events (events that wake the CPU from idle and the system from
suspend) that occur right after initiating suspend will not be
processed until another possibly unrelated event wakes the system up
again.

On hardware where idle can enter the same power state as suspend, idle
combined with runtime PM can be used, but periodic wakeups increase
the average power consumption. Suspending the system also reduces the
harm caused by apps that never go idle. There also are systems where
some devices cannot be put into low-power states without suspending
the entire system (or the low-power states available to them without
suspending the entire system are substantially shallower than the
low-power states they are put into when the entire system is
suspended), so the system has to be suspended as a whole to achieve
the maximum energy savings.

To allow Android and similar platforms to save more energy than they
currently can save using the mainline kernel, introduce a mechanism by
which the system is automatically suspended (i.e. put into a
system-wide sleep state) whenever it's not doing work that's
immediately useful to the user, called opportunistic suspend.

For this purpose introduce the suspend blockers framework allowing the
kernel's power management subsystem to decide when it is desirable to
suspend the system (i.e. when the system is not doing anything the
user really cares about at the moment and therefore it may be
suspended). Add an API that that drivers can use to block
opportunistic suspend. This is needed to avoid losing wakeup events
that occur right after suspend is initiated.

Add /sys/power/policy that selects the behavior of /sys/power/state.
After setting the policy to opportunistic, writes to /sys/power/state
become non-blocking requests that specify which suspend state to enter
when no suspend blockers are active. A special state, "on", stops the
process by activating the "main" suspend blocker.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/power/opportunistic-suspend.txt |  129 +++++++++++
 include/linux/suspend.h                       |    1 +
 include/linux/suspend_blocker.h               |   74 ++++++
 kernel/power/Kconfig                          |   16 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/main.c                           |  128 ++++++++++-
 kernel/power/opportunistic_suspend.c          |  298 +++++++++++++++++++++++++
 kernel/power/power.h                          |    9 +
 kernel/power/suspend.c                        |    3 +-
 9 files changed, 651 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/power/opportunistic-suspend.txt
 create mode 100755 include/linux/suspend_blocker.h
 create mode 100644 kernel/power/opportunistic_suspend.c

diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
new file mode 100644
index 0000000..4bee7bc
--- /dev/null
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -0,0 +1,129 @@
+Opportunistic Suspend
+=====================
+
+Opportunistic suspend is a feature allowing the system to be suspended (ie. put
+into one of the available sleep states) automatically whenever it is regarded
+as idle.  The suspend blockers framework described below is used to determine
+when that happens.
+
+The /sys/power/policy sysfs attribute is used to switch the system between the
+opportunistic and "forced" suspend behavior, where in the latter case the
+system is only suspended if a specific value, corresponding to one of the
+available system sleep states, is written into /sys/power/state.  However, in
+the former, opportunistic, case the system is put into the sleep state
+corresponding to the value written to /sys/power/state whenever there are no
+active suspend blockers. The default policy is "forced". Also, suspend blockers
+do not affect sleep states entered from idle.
+
+When the policy is "opportunisic", there is a special value, "on", that can be
+written to /sys/power/state. This will block the automatic sleep request, as if
+a suspend blocker was used by a device driver. This way the opportunistic
+suspend may be blocked by user space whithout switching back to the "forced"
+mode.
+
+A suspend blocker is an object used to inform the PM subsystem when the system
+can or cannot be suspended in the "opportunistic" mode (the "forced" mode
+ignores suspend blockers).  To use it, a device driver creates a struct
+suspend_blocker that must be initialized with suspend_blocker_init(). Before
+freeing the suspend_blocker structure or its name, suspend_blocker_unregister()
+must be called on it.
+
+A suspend blocker is activated using suspend_block(), which prevents the PM
+subsystem from putting the system into the requested sleep state in the
+"opportunistic" mode until the suspend blocker is deactivated with
+suspend_unblock(). Multiple suspend blockers may be active simultaneously, and
+the system will not suspend as long as at least one of them is active.
+
+If opportunistic suspend is already in progress when suspend_block() is called,
+it will abort the suspend, unless suspend_ops->enter has already been
+executed. If suspend is aborted this way, the system is usually not fully
+operational at that point. The suspend callbacks of some drivers may still be
+running and it usually takes time to restore the system to the fully operational
+state.
+
+Here's an example showing how a cell phone or other embedded system can handle
+keystrokes (or other input events) in the presence of suspend blockers. Use
+set_irq_wake or a platform specific API to make sure the keypad interrupt wakes
+up the cpu. Once the keypad driver has resumed, the sequence of events can look
+like this:
+
+- The Keypad driver gets an interrupt. It then calls suspend_block on the
+  keypad-scan suspend_blocker and starts scanning the keypad matrix.
+- The keypad-scan code detects a key change and reports it to the input-event
+  driver.
+- The input-event driver sees the key change, enqueues an event, and calls
+  suspend_block on the input-event-queue suspend_blocker.
+- The keypad-scan code detects that no keys are held and calls suspend_unblock
+  on the keypad-scan suspend_blocker.
+- The user-space input-event thread returns from select/poll, calls
+  suspend_block on the process-input-events suspend_blocker and then calls read
+  on the input-event device.
+- The input-event driver dequeues the key-event and, since the queue is now
+  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
+- The user-space input-event thread returns from read. If it determines that
+  the key should be ignored, it calls suspend_unblock on the
+  process_input_events suspend_blocker and then calls select or poll. The
+  system will automatically suspend again, since now no suspend blockers are
+  active.
+
+If the key that was pressed instead should preform a simple action (for example,
+adjusting the volume), this action can be performed right before calling
+suspend_unblock on the process_input_events suspend_blocker. However, if the key
+triggers a longer-running action, that action needs its own suspend_blocker and
+suspend_block must be called on that suspend blocker before calling
+suspend_unblock on the process_input_events suspend_blocker.
+
+                 Key pressed   Key released
+                     |             |
+keypad-scan          ++++++++++++++++++
+input-event-queue        +++          +++
+process-input-events       +++          +++
+
+
+Driver API
+==========
+
+A driver can use the suspend block API by adding a suspend_blocker variable to
+its state and calling suspend_blocker_init(). For instance:
+
+struct state {
+	struct suspend_blocker suspend_blocker;
+}
+
+init() {
+	suspend_blocker_init(&state->suspend_blocker, name);
+}
+
+If the suspend_blocker variable is allocated statically,
+DEFINE_SUSPEND_BLOCKER() should be used to initialize it, for example:
+
+static DEFINE_SUSPEND_BLOCKER(blocker, name);
+
+and suspend_blocker_register(&blocker) has to be called to make the suspend
+blocker usable.
+
+Before freeing the memory in which a suspend_blocker variable is located,
+suspend_blocker_unregister() must be called, for instance:
+
+uninit() {
+	suspend_blocker_unregister(&state->suspend_blocker);
+}
+
+When the driver determines that it needs to run (usually in an interrupt
+handler) it calls suspend_block():
+
+	suspend_block(&state->suspend_blocker);
+
+When it no longer needs to run it calls suspend_unblock():
+
+	suspend_unblock(&state->suspend_blocker);
+
+Calling suspend_block() when the suspend blocker is active or suspend_unblock()
+when it is not active has no effect (i.e., these functions don't nest). This
+allows drivers to update their state and call suspend suspend_block() or
+suspend_unblock() based on the result. For instance:
+
+if (list_empty(&state->pending_work))
+	suspend_unblock(&state->suspend_blocker);
+else
+	suspend_block(&state->suspend_blocker);
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..07023d3 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -6,6 +6,7 @@
 #include <linux/init.h>
 #include <linux/pm.h>
 #include <linux/mm.h>
+#include <linux/suspend_blocker.h>
 #include <asm/errno.h>
 
 #if defined(CONFIG_PM_SLEEP) && defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE)
diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
new file mode 100755
index 0000000..8788302
--- /dev/null
+++ b/include/linux/suspend_blocker.h
@@ -0,0 +1,74 @@
+/* include/linux/suspend_blocker.h
+ *
+ * Copyright (C) 2007-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_SUSPEND_BLOCKER_H
+#define _LINUX_SUSPEND_BLOCKER_H
+
+#include <linux/list.h>
+
+/**
+ * struct suspend_blocker - the basic suspend_blocker structure
+ * @link: List entry for active or inactive list.
+ * @flags: Tracks initialized and active state.
+ * @name: Suspend blocker name used for debugging.
+ *
+ * When a suspend_blocker is active it prevents the system from entering
+ * opportunistic suspend.
+ *
+ * The suspend_blocker structure must be initialized by suspend_blocker_init()
+ */
+struct suspend_blocker {
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct list_head link;
+	int flags;
+	const char *name;
+#endif
+};
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+#define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
+	{ .name = #blocker_name, }
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker = __SUSPEND_BLOCKER_INITIALIZER(name)
+
+extern void suspend_blocker_register(struct suspend_blocker *blocker);
+extern void suspend_blocker_init(struct suspend_blocker *blocker,
+				 const char *name);
+extern void suspend_blocker_unregister(struct suspend_blocker *blocker);
+extern void suspend_block(struct suspend_blocker *blocker);
+extern void suspend_unblock(struct suspend_blocker *blocker);
+extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
+extern bool suspend_is_blocked(void);
+
+#else
+
+#define DEFINE_SUSPEND_BLOCKER(blocker, name) \
+	struct suspend_blocker blocker
+
+static inline void suspend_blocker_register(struct suspend_blocker *bl) {}
+static inline void suspend_blocker_init(struct suspend_blocker *bl,
+					const char *n) {}
+static inline void suspend_blocker_unregister(struct suspend_blocker *bl) {}
+static inline void suspend_block(struct suspend_blocker *bl) {}
+static inline void suspend_unblock(struct suspend_blocker *bl) {}
+static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
+{
+	return false;
+}
+static inline bool suspend_is_blocked(void) { return false; }
+#endif
+
+#endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5c36ea9..6d11a45 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -130,6 +130,22 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config OPPORTUNISTIC_SUSPEND
+	bool "Opportunistic suspend"
+	depends on SUSPEND
+	select RTC_LIB
+	default n
+	---help---
+	  Opportunistic sleep support.  Allows the system to be put into a sleep
+	  state opportunistically, if it doesn't do any useful work at the
+	  moment. The PM subsystem is switched into this mode of operation by
+	  writing "opportunistic" into /sys/power/policy, while writing
+	  "forced" to this file turns the opportunistic suspend feature off.
+	  In the "opportunistic" mode suspend blockers are used to determine
+	  when to suspend the system and the value written to /sys/power/state
+	  determines the sleep state the system will be put into when there are
+	  no active suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4319181..95d8e6d 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
+obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/main.c b/kernel/power/main.c
index b58800b..afbb4dd 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -20,6 +20,58 @@ DEFINE_MUTEX(pm_mutex);
 unsigned int pm_flags;
 EXPORT_SYMBOL(pm_flags);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+struct pm_policy {
+	const char *name;
+	bool (*valid_state)(suspend_state_t state);
+	int (*set_state)(suspend_state_t state);
+};
+
+static struct pm_policy policies[] = {
+	{
+		.name		= "forced",
+		.valid_state	= valid_state,
+		.set_state	= enter_state,
+	},
+	{
+		.name		= "opportunistic",
+		.valid_state	= opportunistic_suspend_valid_state,
+		.set_state	= opportunistic_suspend_state,
+	},
+};
+
+static int policy;
+
+static inline bool hibernation_supported(void)
+{
+	return !strncmp(policies[policy].name, "forced", 6);
+}
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && policies[policy].valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return policies[policy].set_state(state_idx);
+}
+
+#else
+
+static inline bool hibernation_supported(void) { return true; }
+
+static inline bool pm_state_valid(int state_idx)
+{
+	return pm_states[state_idx] && valid_state(state_idx);
+}
+
+static inline int pm_enter_state(int state_idx)
+{
+	return enter_state(state_idx);
+}
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_SLEEP
 
 /* Routines for PM-transition notifications */
@@ -146,6 +198,12 @@ struct kobject *power_kobj;
  *
  *	store() accepts one of those strings, translates it into the 
  *	proper enumerated value, and initiates a suspend transition.
+ *
+ *	If policy is set to opportunistic, store() does not block until the
+ *	system resumes, and it will try to re-enter the state until another
+ *	state is requested. Suspend blockers are respected and the requested
+ *	state will only be entered when no suspend blockers are active.
+ *	Write "on" to disable.
  */
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
@@ -155,12 +213,13 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 
 	for (i = 0; i < PM_SUSPEND_MAX; i++) {
-		if (pm_states[i] && valid_state(i))
+		if (pm_state_valid(i))
 			s += sprintf(s,"%s ", pm_states[i]);
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (hibernation_supported())
+		s += sprintf(s, "%s\n", "disk");
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
@@ -173,7 +232,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_ON;
 	const char * const *s;
 #endif
 	char *p;
@@ -185,8 +244,9 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 	/* First, check if we are requested to hibernate */
 	if (len == 4 && !strncmp(buf, "disk", len)) {
-		error = hibernate();
-  goto Exit;
+		if (hibernation_supported())
+			error = hibernate();
+		goto Exit;
 	}
 
 #ifdef CONFIG_SUSPEND
@@ -195,7 +255,7 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
-		error = enter_state(state);
+		error = pm_enter_state(state);
 #endif
 
  Exit:
@@ -204,6 +264,56 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(state);
 
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/**
+ *	policy - set policy for state
+ */
+static ssize_t policy_show(struct kobject *kobj,
+			   struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		if (i == policy)
+			s += sprintf(s, "[%s] ", policies[i].name);
+		else
+			s += sprintf(s, "%s ", policies[i].name);
+	}
+	if (s != buf)
+		/* convert the last space to a newline */
+		*(s-1) = '\n';
+	return (s - buf);
+}
+
+static ssize_t policy_store(struct kobject *kobj,
+			    struct kobj_attribute *attr,
+			    const char *buf, size_t n)
+{
+	const char *s;
+	char *p;
+	int len;
+	int i;
+
+	p = memchr(buf, '\n', n);
+	len = p ? p - buf : n;
+
+	for (i = 0; i < ARRAY_SIZE(policies); i++) {
+		s = policies[i].name;
+		if (s && len == strlen(s) && !strncmp(buf, s, len)) {
+			mutex_lock(&pm_mutex);
+			policies[policy].set_state(PM_SUSPEND_ON);
+			policy = i;
+			mutex_unlock(&pm_mutex);
+			return n;
+		}
+	}
+	return -EINVAL;
+}
+
+power_attr(policy);
+#endif /* CONFIG_OPPORTUNISTIC_SUSPEND */
+
 #ifdef CONFIG_PM_TRACE
 int pm_trace_enabled;
 
@@ -236,6 +346,9 @@ static struct attribute * g[] = {
 #endif
 #ifdef CONFIG_PM_SLEEP
 	&pm_async_attr.attr,
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	&policy_attr.attr,
+#endif
 #ifdef CONFIG_PM_DEBUG
 	&pm_test_attr.attr,
 #endif
@@ -247,7 +360,7 @@ static struct attribute_group attr_group = {
 	.attrs = g,
 };
 
-#ifdef CONFIG_PM_RUNTIME
+#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_OPPORTUNISTIC_SUSPEND)
 struct workqueue_struct *pm_wq;
 EXPORT_SYMBOL_GPL(pm_wq);
 
@@ -266,6 +379,7 @@ static int __init pm_init(void)
 	int error = pm_start_workqueue();
 	if (error)
 		return error;
+	opportunistic_suspend_init();
 	power_kobj = kobject_create_and_add("power", NULL);
 	if (!power_kobj)
 		return -ENOMEM;
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
new file mode 100644
index 0000000..cc90b60
--- /dev/null
+++ b/kernel/power/opportunistic_suspend.c
@@ -0,0 +1,298 @@
+/*
+ * kernel/power/opportunistic_suspend.c
+ *
+ * Copyright (C) 2005-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/rtc.h>
+#include <linux/suspend.h>
+
+#include "power.h"
+
+extern struct workqueue_struct *pm_wq;
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_USER_STATE = 1U << 2,
+	DEBUG_SUSPEND = 1U << 3,
+	DEBUG_SUSPEND_BLOCKER = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP | DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static int unknown_wakeup_delay_msecs = 500;
+module_param_named(unknown_wakeup_delay_msecs, unknown_wakeup_delay_msecs, int,
+		   S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define SB_INITIALIZED            (1U << 8)
+#define SB_ACTIVE                 (1U << 9)
+
+DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
+
+static DEFINE_SPINLOCK(list_lock);
+static DEFINE_SPINLOCK(state_lock);
+static LIST_HEAD(inactive_blockers);
+static LIST_HEAD(active_blockers);
+static int current_event_num;
+static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static bool enable_suspend_blockers;
+static DEFINE_SUSPEND_BLOCKER(unknown_wakeup, unknown_wakeups);
+
+#define pr_info_time(fmt, args...) \
+	do { \
+		struct timespec ts; \
+		struct rtc_time tm; \
+		getnstimeofday(&ts); \
+		rtc_time_to_tm(ts.tv_sec, &tm); \
+		pr_info(fmt "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n" , \
+			args, \
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, \
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); \
+	} while (0);
+
+static void print_active_suspend_blockers(void)
+{
+	struct suspend_blocker *blocker;
+
+	list_for_each_entry(blocker, &active_blockers, link)
+		pr_info("PM: Active suspend blocker %s\n", blocker->name);
+}
+
+/**
+ * suspend_is_blocked - Check if there are active suspend blockers.
+ *
+ * Return true if suspend blockers are enabled and there are active suspend
+ * blockers, in which case the system cannot be put to sleep opportunistically.
+ */
+bool suspend_is_blocked(void)
+{
+	return enable_suspend_blockers && !list_empty(&active_blockers);
+}
+
+static void expire_unknown_wakeup(unsigned long data)
+{
+	suspend_unblock(&unknown_wakeup);
+}
+static DEFINE_TIMER(expire_unknown_wakeup_timer, expire_unknown_wakeup, 0, 0);
+
+static void suspend_worker(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	enable_suspend_blockers = true;
+
+	if (suspend_is_blocked()) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: Automatic suspend aborted\n");
+		goto abort;
+	}
+
+	entry_event_num = current_event_num;
+
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("PM: Automatic suspend\n");
+
+	ret = pm_suspend(requested_suspend_state);
+
+	if (debug_mask & DEBUG_EXIT_SUSPEND)
+		pr_info_time("PM: Automatic suspend exit, ret = %d ", ret);
+
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("PM: pm_suspend() returned with no event\n");
+		suspend_block(&unknown_wakeup);
+		mod_timer(&expire_unknown_wakeup_timer,
+			  msecs_to_jiffies(unknown_wakeup_delay_msecs));
+	}
+
+abort:
+	enable_suspend_blockers = false;
+}
+static DECLARE_WORK(suspend_work, suspend_worker);
+
+/**
+ * suspend_blocker_register - Prepare a suspend blocker for being used.
+ * @blocker: Suspend blocker to handle.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_register(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags = 0;
+
+	WARN_ON(!blocker->name);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Registering %s\n", __func__, blocker->name);
+
+	blocker->flags = SB_INITIALIZED;
+	INIT_LIST_HEAD(&blocker->link);
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&blocker->link, &inactive_blockers);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_blocker_register);
+
+/**
+ * suspend_blocker_init - Initialize a suspend blocker's name and register it.
+ * @blocker: Suspend blocker to initialize.
+ * @name:    The name of the suspend blocker to show in debug messages.
+ *
+ * The suspend blocker struct and name must not be freed before calling
+ * suspend_blocker_unregister().
+ */
+void suspend_blocker_init(struct suspend_blocker *blocker, const char *name)
+{
+	blocker->name = name;
+	suspend_blocker_register(blocker);
+}
+EXPORT_SYMBOL(suspend_blocker_init);
+
+/**
+ * suspend_blocker_unregister - Unregister a suspend blocker.
+ * @blocker: Suspend blocker to handle.
+ */
+void suspend_blocker_unregister(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	blocker->flags &= ~SB_INITIALIZED;
+	list_del(&blocker->link);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: Unregistered %s\n", __func__, blocker->name);
+}
+EXPORT_SYMBOL(suspend_blocker_unregister);
+
+/**
+ * suspend_block - Block system suspend.
+ * @blocker: Suspend blocker to use.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_block(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	blocker->flags |= SB_ACTIVE;
+	list_move(&blocker->link, &active_blockers);
+
+	current_event_num++;
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_block);
+
+/**
+ * suspend_unblock - Allow system suspend to happen.
+ * @blocker: Suspend blocker to unblock.
+ *
+ * If no other suspend blockers are active, schedule suspend of the system.
+ *
+ * It is safe to call this function from interrupt context.
+ */
+void suspend_unblock(struct suspend_blocker *blocker)
+{
+	unsigned long irqflags;
+
+	if (WARN_ON(!(blocker->flags & SB_INITIALIZED)))
+		return;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
+		pr_info("%s: %s\n", __func__, blocker->name);
+
+	list_move(&blocker->link, &inactive_blockers);
+	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
+		queue_work(pm_wq, &suspend_work);
+	blocker->flags &= ~(SB_ACTIVE);
+
+	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
+		print_active_suspend_blockers();
+
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(suspend_unblock);
+
+/**
+ * suspend_blocker_is_active - Test if a suspend blocker is blocking suspend
+ * @blocker: Suspend blocker to check.
+ *
+ * Returns true if the suspend_blocker is currently active.
+ */
+bool suspend_blocker_is_active(struct suspend_blocker *blocker)
+{
+	WARN_ON(!(blocker->flags & SB_INITIALIZED));
+
+	return !!(blocker->flags & SB_ACTIVE);
+}
+EXPORT_SYMBOL(suspend_blocker_is_active);
+
+bool opportunistic_suspend_valid_state(suspend_state_t state)
+{
+	return (state == PM_SUSPEND_ON) || valid_state(state);
+}
+
+int opportunistic_suspend_state(suspend_state_t state)
+{
+	unsigned long irqflags;
+
+	if (!opportunistic_suspend_valid_state(state))
+		return -ENODEV;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+
+	if (debug_mask & DEBUG_USER_STATE)
+		pr_info_time("%s: %s (%d->%d) at %lld ", __func__,
+			     state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			     requested_suspend_state, state,
+			     ktime_to_ns(ktime_get()));
+
+	requested_suspend_state = state;
+	if (state == PM_SUSPEND_ON)
+		suspend_block(&main_suspend_blocker);
+	else
+		suspend_unblock(&main_suspend_blocker);
+
+	spin_unlock_irqrestore(&state_lock, irqflags);
+
+	return 0;
+}
+
+void __init opportunistic_suspend_init(void)
+{
+	suspend_blocker_register(&main_suspend_blocker);
+	suspend_block(&main_suspend_blocker);
+	suspend_blocker_register(&unknown_wakeup);
+}
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46c5a26..2e9cfd5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -236,3 +236,12 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+/* kernel/power/opportunistic_suspend.c */
+extern int opportunistic_suspend_state(suspend_state_t state);
+extern bool opportunistic_suspend_valid_state(suspend_state_t state);
+extern void __init opportunistic_suspend_init(void);
+#else
+static inline void opportunistic_suspend_init(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..9eb3876 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -20,6 +20,7 @@
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_ON]		= "on",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
@@ -157,7 +158,7 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
 			error = suspend_ops->enter(state);
 		sysdev_resume();
 	}
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

Add a misc device, "suspend_blocker", that allows user-space processes
to block automatic suspend.

Opening this device creates a suspend blocker that can be used by the
opener to prevent automatic suspend from occurring.  There are ioctls
provided for blocking and unblocking suspend and for giving the
suspend blocker a meaningful name.  Closing the device special file
causes the suspend blocker to be destroyed.

For example, when select or poll indicates that input event are
available, this interface can be used by user space to block suspend
before it reads those events. This allows the input driver to release
its suspend blocker as soon as the event queue is empty. If user space
could not use a suspend blocker here the input driver would need to
delay the release of its suspend blocker until it knows (or assumes)
that user space has finished processing the events.

By careful use of suspend blockers in drivers and user space system
code, one can arrange for the system to stay awake for extremely short
periods of time in reaction to events, rapidly returning to a fully
suspended state.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/ioctl/ioctl-number.txt          |    3 +-
 Documentation/power/opportunistic-suspend.txt |   27 +++++
 include/linux/suspend_ioctls.h                |    4 +
 kernel/power/Kconfig                          |    7 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/user_suspend_blocker.c           |  143 +++++++++++++++++++++++++
 6 files changed, 184 insertions(+), 1 deletions(-)
 create mode 100644 kernel/power/user_suspend_blocker.c

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index dd5806f..e2458f7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -254,7 +254,8 @@ Code  Seq#(hex)	Include File		Comments
 'q'	80-FF	linux/telephony.h	Internet PhoneJACK, Internet LineJACK
 		linux/ixjuser.h		<http://www.quicknet.net>
 'r'	00-1F	linux/msdos_fs.h and fs/fat/dir.c
-'s'	all	linux/cdk.h
+'s'	all	linux/cdk.h	conflict!
+'s'	all	linux/suspend_block_dev.h	conflict!
 't'	00-7F	linux/if_ppp.h
 't'	80-8F	linux/isdn_ppp.h
 't'	90	linux/toshiba.h
diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
index 4bee7bc..93f4c24 100644
--- a/Documentation/power/opportunistic-suspend.txt
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -127,3 +127,30 @@ if (list_empty(&state->pending_work))
 	suspend_unblock(&state->suspend_blocker);
 else
 	suspend_block(&state->suspend_blocker);
+
+User space API
+==============
+
+To create a suspend blocker from user space, open the suspend_blocker special
+device file:
+
+    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
+
+then optionally call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
+
+To activate the suspend blocker call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
+
+To deactivate it call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
+
+To destroy the suspend blocker, close the device:
+
+    close(fd);
+
+If the first ioctl called is not SUSPEND_BLOCKER_IOCTL_SET_NAME the suspend
+blocker will get the default name "(userspace)".
diff --git a/include/linux/suspend_ioctls.h b/include/linux/suspend_ioctls.h
index 0b30382..b95a6b2 100644
--- a/include/linux/suspend_ioctls.h
+++ b/include/linux/suspend_ioctls.h
@@ -30,4 +30,8 @@ struct resume_swap_area {
 #define SNAPSHOT_ALLOC_SWAP_PAGE	_IOR(SNAPSHOT_IOC_MAGIC, 20, __kernel_loff_t)
 #define SNAPSHOT_IOC_MAXNR	20
 
+#define SUSPEND_BLOCKER_IOCTL_SET_NAME(len)	_IOC(_IOC_WRITE, 's', 0, len)
+#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
+#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
+
 #endif /* _LINUX_SUSPEND_IOCTLS_H */
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 6d11a45..2e665cd 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,13 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config USER_SUSPEND_BLOCKERS
+	bool "User space suspend blockers"
+	depends on OPPORTUNISTIC_SUSPEND
+	---help---
+	  User space suspend blockers API.  Creates a misc device allowing user
+	  space to create, use and destroy suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 95d8e6d..2015594 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
+obj-$(CONFIG_USER_SUSPEND_BLOCKERS)	+= user_suspend_blocker.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/user_suspend_blocker.c b/kernel/power/user_suspend_blocker.c
new file mode 100644
index 0000000..d53f939
--- /dev/null
+++ b/kernel/power/user_suspend_blocker.c
@@ -0,0 +1,143 @@
+/*
+ * kernel/power/user_suspend_blocker.c
+ *
+ * Copyright (C) 2009-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/slab.h>
+#include <linux/suspend.h>
+#include <linux/suspend_ioctls.h>
+
+enum {
+	DEBUG_FAILURE	= BIT(0),
+};
+static int debug_mask = DEBUG_FAILURE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static DEFINE_MUTEX(ioctl_lock);
+
+#define USER_SUSPEND_BLOCKER_NAME_LEN 31
+
+struct user_suspend_blocker {
+	struct suspend_blocker	blocker;
+	char			name[USER_SUSPEND_BLOCKER_NAME_LEN + 1];
+	bool			registered;
+};
+
+static int user_suspend_blocker_open(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker;
+
+	blocker = kzalloc(sizeof(*blocker), GFP_KERNEL);
+	if (!blocker)
+		return -ENOMEM;
+
+	nonseekable_open(inode, filp);
+	strcpy(blocker->name, "(userspace)");
+	blocker->blocker.name = blocker->name;
+	filp->private_data = blocker;
+
+	return 0;
+}
+
+static int suspend_blocker_set_name(struct user_suspend_blocker *blocker,
+				    void __user *name, size_t name_len)
+{
+	if (blocker->registered)
+		return -EBUSY;
+
+	if (name_len > USER_SUSPEND_BLOCKER_NAME_LEN)
+		name_len = USER_SUSPEND_BLOCKER_NAME_LEN;
+
+	if (copy_from_user(blocker->name, name, name_len))
+		return -EFAULT;
+	blocker->name[name_len] = '\0';
+
+	return 0;
+}
+
+static long user_suspend_blocker_ioctl(struct file *filp, unsigned int cmd,
+					unsigned long _arg)
+{
+	void __user *arg = (void __user *)_arg;
+	struct user_suspend_blocker *blocker = filp->private_data;
+	long ret = 0;
+
+	mutex_lock(&ioctl_lock);
+	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_SET_NAME(0)) {
+		ret = suspend_blocker_set_name(blocker, arg, _IOC_SIZE(cmd));
+		goto done;
+	}
+	if (!blocker->registered) {
+		suspend_blocker_register(&blocker->blocker);
+		blocker->registered = true;
+	}
+	switch (cmd) {
+	case SUSPEND_BLOCKER_IOCTL_BLOCK:
+		suspend_block(&blocker->blocker);
+		break;
+
+	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
+		suspend_unblock(&blocker->blocker);
+		break;
+
+	default:
+		ret = -ENOTTY;
+	}
+done:
+	if (ret && (debug_mask & DEBUG_FAILURE))
+		pr_err("user_suspend_blocker_ioctl: cmd %x failed, %ld\n",
+			cmd, ret);
+	mutex_unlock(&ioctl_lock);
+	return ret;
+}
+
+static int user_suspend_blocker_release(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker = filp->private_data;
+
+	if (blocker->registered)
+		suspend_blocker_unregister(&blocker->blocker);
+	kfree(blocker);
+
+	return 0;
+}
+
+const struct file_operations user_suspend_blocker_fops = {
+	.open = user_suspend_blocker_open,
+	.release = user_suspend_blocker_release,
+	.unlocked_ioctl = user_suspend_blocker_ioctl,
+};
+
+struct miscdevice user_suspend_blocker_device = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "suspend_blocker",
+	.fops = &user_suspend_blocker_fops,
+};
+
+static int __init user_suspend_blocker_init(void)
+{
+	return misc_register(&user_suspend_blocker_device);
+}
+
+static void __exit user_suspend_blocker_exit(void)
+{
+	misc_deregister(&user_suspend_blocker_device);
+}
+
+module_init(user_suspend_blocker_init);
+module_exit(user_suspend_blocker_exit);
-- 
1.6.5.1

[PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

Add a misc device, "suspend_blocker", that allows user-space processes
to block automatic suspend.

Opening this device creates a suspend blocker that can be used by the
opener to prevent automatic suspend from occurring.  There are ioctls
provided for blocking and unblocking suspend and for giving the
suspend blocker a meaningful name.  Closing the device special file
causes the suspend blocker to be destroyed.

For example, when select or poll indicates that input event are
available, this interface can be used by user space to block suspend
before it reads those events. This allows the input driver to release
its suspend blocker as soon as the event queue is empty. If user space
could not use a suspend blocker here the input driver would need to
delay the release of its suspend blocker until it knows (or assumes)
that user space has finished processing the events.

By careful use of suspend blockers in drivers and user space system
code, one can arrange for the system to stay awake for extremely short
periods of time in reaction to events, rapidly returning to a fully
suspended state.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 Documentation/ioctl/ioctl-number.txt          |    3 +-
 Documentation/power/opportunistic-suspend.txt |   27 +++++
 include/linux/suspend_ioctls.h                |    4 +
 kernel/power/Kconfig                          |    7 ++
 kernel/power/Makefile                         |    1 +
 kernel/power/user_suspend_blocker.c           |  143 +++++++++++++++++++++++++
 6 files changed, 184 insertions(+), 1 deletions(-)
 create mode 100644 kernel/power/user_suspend_blocker.c

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index dd5806f..e2458f7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -254,7 +254,8 @@ Code  Seq#(hex)	Include File		Comments
 'q'	80-FF	linux/telephony.h	Internet PhoneJACK, Internet LineJACK
 		linux/ixjuser.h		<http://www.quicknet.net>
 'r'	00-1F	linux/msdos_fs.h and fs/fat/dir.c
-'s'	all	linux/cdk.h
+'s'	all	linux/cdk.h	conflict!
+'s'	all	linux/suspend_block_dev.h	conflict!
 't'	00-7F	linux/if_ppp.h
 't'	80-8F	linux/isdn_ppp.h
 't'	90	linux/toshiba.h
diff --git a/Documentation/power/opportunistic-suspend.txt b/Documentation/power/opportunistic-suspend.txt
index 4bee7bc..93f4c24 100644
--- a/Documentation/power/opportunistic-suspend.txt
+++ b/Documentation/power/opportunistic-suspend.txt
@@ -127,3 +127,30 @@ if (list_empty(&state->pending_work))
 	suspend_unblock(&state->suspend_blocker);
 else
 	suspend_block(&state->suspend_blocker);
+
+User space API
+==============
+
+To create a suspend blocker from user space, open the suspend_blocker special
+device file:
+
+    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
+
+then optionally call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
+
+To activate the suspend blocker call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
+
+To deactivate it call:
+
+    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
+
+To destroy the suspend blocker, close the device:
+
+    close(fd);
+
+If the first ioctl called is not SUSPEND_BLOCKER_IOCTL_SET_NAME the suspend
+blocker will get the default name "(userspace)".
diff --git a/include/linux/suspend_ioctls.h b/include/linux/suspend_ioctls.h
index 0b30382..b95a6b2 100644
--- a/include/linux/suspend_ioctls.h
+++ b/include/linux/suspend_ioctls.h
@@ -30,4 +30,8 @@ struct resume_swap_area {
 #define SNAPSHOT_ALLOC_SWAP_PAGE	_IOR(SNAPSHOT_IOC_MAGIC, 20, __kernel_loff_t)
 #define SNAPSHOT_IOC_MAXNR	20
 
+#define SUSPEND_BLOCKER_IOCTL_SET_NAME(len)	_IOC(_IOC_WRITE, 's', 0, len)
+#define SUSPEND_BLOCKER_IOCTL_BLOCK		_IO('s', 1)
+#define SUSPEND_BLOCKER_IOCTL_UNBLOCK		_IO('s', 2)
+
 #endif /* _LINUX_SUSPEND_IOCTLS_H */
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 6d11a45..2e665cd 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,13 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config USER_SUSPEND_BLOCKERS
+	bool "User space suspend blockers"
+	depends on OPPORTUNISTIC_SUSPEND
+	---help---
+	  User space suspend blockers API.  Creates a misc device allowing user
+	  space to create, use and destroy suspend blockers.
+
 config HIBERNATION_NVS
 	bool
 
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 95d8e6d..2015594 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PM_SLEEP)		+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
 obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_OPPORTUNISTIC_SUSPEND)	+= opportunistic_suspend.o
+obj-$(CONFIG_USER_SUSPEND_BLOCKERS)	+= user_suspend_blocker.o
 obj-$(CONFIG_PM_TEST_SUSPEND)	+= suspend_test.o
 obj-$(CONFIG_HIBERNATION)	+= hibernate.o snapshot.o swap.o user.o
 obj-$(CONFIG_HIBERNATION_NVS)	+= hibernate_nvs.o
diff --git a/kernel/power/user_suspend_blocker.c b/kernel/power/user_suspend_blocker.c
new file mode 100644
index 0000000..d53f939
--- /dev/null
+++ b/kernel/power/user_suspend_blocker.c
@@ -0,0 +1,143 @@
+/*
+ * kernel/power/user_suspend_blocker.c
+ *
+ * Copyright (C) 2009-2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/slab.h>
+#include <linux/suspend.h>
+#include <linux/suspend_ioctls.h>
+
+enum {
+	DEBUG_FAILURE	= BIT(0),
+};
+static int debug_mask = DEBUG_FAILURE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static DEFINE_MUTEX(ioctl_lock);
+
+#define USER_SUSPEND_BLOCKER_NAME_LEN 31
+
+struct user_suspend_blocker {
+	struct suspend_blocker	blocker;
+	char			name[USER_SUSPEND_BLOCKER_NAME_LEN + 1];
+	bool			registered;
+};
+
+static int user_suspend_blocker_open(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker;
+
+	blocker = kzalloc(sizeof(*blocker), GFP_KERNEL);
+	if (!blocker)
+		return -ENOMEM;
+
+	nonseekable_open(inode, filp);
+	strcpy(blocker->name, "(userspace)");
+	blocker->blocker.name = blocker->name;
+	filp->private_data = blocker;
+
+	return 0;
+}
+
+static int suspend_blocker_set_name(struct user_suspend_blocker *blocker,
+				    void __user *name, size_t name_len)
+{
+	if (blocker->registered)
+		return -EBUSY;
+
+	if (name_len > USER_SUSPEND_BLOCKER_NAME_LEN)
+		name_len = USER_SUSPEND_BLOCKER_NAME_LEN;
+
+	if (copy_from_user(blocker->name, name, name_len))
+		return -EFAULT;
+	blocker->name[name_len] = '\0';
+
+	return 0;
+}
+
+static long user_suspend_blocker_ioctl(struct file *filp, unsigned int cmd,
+					unsigned long _arg)
+{
+	void __user *arg = (void __user *)_arg;
+	struct user_suspend_blocker *blocker = filp->private_data;
+	long ret = 0;
+
+	mutex_lock(&ioctl_lock);
+	if ((cmd & ~IOCSIZE_MASK) == SUSPEND_BLOCKER_IOCTL_SET_NAME(0)) {
+		ret = suspend_blocker_set_name(blocker, arg, _IOC_SIZE(cmd));
+		goto done;
+	}
+	if (!blocker->registered) {
+		suspend_blocker_register(&blocker->blocker);
+		blocker->registered = true;
+	}
+	switch (cmd) {
+	case SUSPEND_BLOCKER_IOCTL_BLOCK:
+		suspend_block(&blocker->blocker);
+		break;
+
+	case SUSPEND_BLOCKER_IOCTL_UNBLOCK:
+		suspend_unblock(&blocker->blocker);
+		break;
+
+	default:
+		ret = -ENOTTY;
+	}
+done:
+	if (ret && (debug_mask & DEBUG_FAILURE))
+		pr_err("user_suspend_blocker_ioctl: cmd %x failed, %ld\n",
+			cmd, ret);
+	mutex_unlock(&ioctl_lock);
+	return ret;
+}
+
+static int user_suspend_blocker_release(struct inode *inode, struct file *filp)
+{
+	struct user_suspend_blocker *blocker = filp->private_data;
+
+	if (blocker->registered)
+		suspend_blocker_unregister(&blocker->blocker);
+	kfree(blocker);
+
+	return 0;
+}
+
+const struct file_operations user_suspend_blocker_fops = {
+	.open = user_suspend_blocker_open,
+	.release = user_suspend_blocker_release,
+	.unlocked_ioctl = user_suspend_blocker_ioctl,
+};
+
+struct miscdevice user_suspend_blocker_device = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "suspend_blocker",
+	.fops = &user_suspend_blocker_fops,
+};
+
+static int __init user_suspend_blocker_init(void)
+{
+	return misc_register(&user_suspend_blocker_device);
+}
+
+static void __exit user_suspend_blocker_exit(void)
+{
+	misc_deregister(&user_suspend_blocker_device);
+}
+
+module_init(user_suspend_blocker_init);
+module_exit(user_suspend_blocker_exit);
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.

[Arve Hjønnevåg]

If a suspend_blocker is active, suspend will fail anyway. Since
try_to_freeze_tasks can take up to 20 seconds to complete or fail, aborting
as soon as someone blocks suspend (e.g. from an interrupt handler) improves
the worst case wakeup latency.

On an older kernel where task freezing could fail for processes attached
to a debugger, this fixed a problem where the device sometimes hung for
20 seconds before the screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 kernel/power/process.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index 71ae290..27d26d3 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -38,6 +38,7 @@ static int try_to_freeze_tasks(bool sig_only)
 	struct timeval start, end;
 	u64 elapsed_csecs64;
 	unsigned int elapsed_csecs;
+	bool wakeup = false;
 
 	do_gettimeofday(&start);
 
@@ -63,6 +64,10 @@ static int try_to_freeze_tasks(bool sig_only)
 				todo++;
 		} while_each_thread(g, p);
 		read_unlock(&tasklist_lock);
+		if (todo && suspend_is_blocked()) {
+			wakeup = true;
+			break;
+		}
 		if (!todo || time_after(jiffies, end_time))
 			break;
 
@@ -85,13 +90,15 @@ static int try_to_freeze_tasks(bool sig_only)
 		 * but it cleans up leftover PF_FREEZE requests.
 		 */
 		printk("\n");
-		printk(KERN_ERR "Freezing of tasks failed after %d.%02d seconds "
+		printk(KERN_ERR "Freezing of tasks %s after %d.%02d seconds "
 				"(%d tasks refusing to freeze):\n",
+				wakeup ? "aborted" : "failed",
 				elapsed_csecs / 100, elapsed_csecs % 100, todo);
 		read_lock(&tasklist_lock);
 		do_each_thread(g, p) {
 			task_lock(p);
-			if (freezing(p) && !freezer_should_skip(p))
+			if (freezing(p) && !freezer_should_skip(p)
+					&& elapsed_csecs > 100)
 				sched_show_task(p);
 			cancel_freezing(p);
 			task_unlock(p);
-- 
1.6.5.1

[PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.

[Arve Hjønnevåg]

If a suspend_blocker is active, suspend will fail anyway. Since
try_to_freeze_tasks can take up to 20 seconds to complete or fail, aborting
as soon as someone blocks suspend (e.g. from an interrupt handler) improves
the worst case wakeup latency.

On an older kernel where task freezing could fail for processes attached
to a debugger, this fixed a problem where the device sometimes hung for
20 seconds before the screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 kernel/power/process.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index 71ae290..27d26d3 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -38,6 +38,7 @@ static int try_to_freeze_tasks(bool sig_only)
 	struct timeval start, end;
 	u64 elapsed_csecs64;
 	unsigned int elapsed_csecs;
+	bool wakeup = false;
 
 	do_gettimeofday(&start);
 
@@ -63,6 +64,10 @@ static int try_to_freeze_tasks(bool sig_only)
 				todo++;
 		} while_each_thread(g, p);
 		read_unlock(&tasklist_lock);
+		if (todo && suspend_is_blocked()) {
+			wakeup = true;
+			break;
+		}
 		if (!todo || time_after(jiffies, end_time))
 			break;
 
@@ -85,13 +90,15 @@ static int try_to_freeze_tasks(bool sig_only)
 		 * but it cleans up leftover PF_FREEZE requests.
 		 */
 		printk("\n");
-		printk(KERN_ERR "Freezing of tasks failed after %d.%02d seconds "
+		printk(KERN_ERR "Freezing of tasks %s after %d.%02d seconds "
 				"(%d tasks refusing to freeze):\n",
+				wakeup ? "aborted" : "failed",
 				elapsed_csecs / 100, elapsed_csecs % 100, todo);
 		read_lock(&tasklist_lock);
 		do_each_thread(g, p) {
 			task_lock(p);
-			if (freezing(p) && !freezer_should_skip(p))
+			if (freezing(p) && !freezer_should_skip(p)
+					&& elapsed_csecs > 100)
 				sched_show_task(p);
 			cancel_freezing(p);
 			task_unlock(p);
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 4/8] PM: suspend_block: Add debugfs file

[Arve Hjønnevåg]

Report active and inactive suspend blockers in
/sys/kernel/debug/suspend_blockers.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/opportunistic_suspend.c |   43 +++++++++++++++++++++++++++++++++-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index cc90b60..6b5eb1d 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/rtc.h>
 #include <linux/suspend.h>
+#include <linux/debugfs.h>
 
 #include "power.h"
 
@@ -151,7 +152,8 @@ EXPORT_SYMBOL(suspend_blocker_register);
 /**
  * suspend_blocker_init - Initialize a suspend blocker's name and register it.
  * @blocker: Suspend blocker to initialize.
- * @name:    The name of the suspend blocker to show in debug messages.
+ * @name:    The name of the suspend blocker to show in debug messages and
+ *	     /sys/kernel/debug/suspend_blockers.
  *
  * The suspend blocker struct and name must not be freed before calling
  * suspend_blocker_unregister().
@@ -296,3 +298,42 @@ void __init opportunistic_suspend_init(void)
 	suspend_block(&main_suspend_blocker);
 	suspend_blocker_register(&unknown_wakeup);
 }
+
+static struct dentry *suspend_blocker_stats_dentry;
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tactive\n");
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		seq_printf(m, "\"%s\"\t0\n", blocker->name);
+	list_for_each_entry(blocker, &active_blockers, link)
+		seq_printf(m, "\"%s\"\t1\n", blocker->name);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, suspend_blocker_stats_show, NULL);
+}
+
+static const struct file_operations suspend_blocker_stats_fops = {
+	.owner = THIS_MODULE,
+	.open = suspend_blocker_stats_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+static int __init suspend_blocker_debugfs_init(void)
+{
+	suspend_blocker_stats_dentry = debugfs_create_file("suspend_blockers",
+			S_IRUGO, NULL, NULL, &suspend_blocker_stats_fops);
+	return 0;
+}
+
+postcore_initcall(suspend_blocker_debugfs_init);
-- 
1.6.5.1

[PATCH 4/8] PM: suspend_block: Add debugfs file

[Arve Hjønnevåg]

Report active and inactive suspend blockers in
/sys/kernel/debug/suspend_blockers.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/opportunistic_suspend.c |   43 +++++++++++++++++++++++++++++++++-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index cc90b60..6b5eb1d 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/rtc.h>
 #include <linux/suspend.h>
+#include <linux/debugfs.h>
 
 #include "power.h"
 
@@ -151,7 +152,8 @@ EXPORT_SYMBOL(suspend_blocker_register);
 /**
  * suspend_blocker_init - Initialize a suspend blocker's name and register it.
  * @blocker: Suspend blocker to initialize.
- * @name:    The name of the suspend blocker to show in debug messages.
+ * @name:    The name of the suspend blocker to show in debug messages and
+ *	     /sys/kernel/debug/suspend_blockers.
  *
  * The suspend blocker struct and name must not be freed before calling
  * suspend_blocker_unregister().
@@ -296,3 +298,42 @@ void __init opportunistic_suspend_init(void)
 	suspend_block(&main_suspend_blocker);
 	suspend_blocker_register(&unknown_wakeup);
 }
+
+static struct dentry *suspend_blocker_stats_dentry;
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tactive\n");
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		seq_printf(m, "\"%s\"\t0\n", blocker->name);
+	list_for_each_entry(blocker, &active_blockers, link)
+		seq_printf(m, "\"%s\"\t1\n", blocker->name);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, suspend_blocker_stats_show, NULL);
+}
+
+static const struct file_operations suspend_blocker_stats_fops = {
+	.owner = THIS_MODULE,
+	.open = suspend_blocker_stats_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+static int __init suspend_blocker_debugfs_init(void)
+{
+	suspend_blocker_stats_dentry = debugfs_create_file("suspend_blockers",
+			S_IRUGO, NULL, NULL, &suspend_blocker_stats_fops);
+	return 0;
+}
+
+postcore_initcall(suspend_blocker_debugfs_init);
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 5/8] PM: suspend_block: Add suspend_blocker stats

[Arve Hjønnevåg]

Report suspend block stats in /sys/kernel/debug/suspend_blockers.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 include/linux/suspend_blocker.h      |   27 +++++-
 kernel/power/Kconfig                 |    8 ++
 kernel/power/opportunistic_suspend.c |  195 +++++++++++++++++++++++++++++++++-
 kernel/power/power.h                 |    5 +
 kernel/power/suspend.c               |    4 +-
 5 files changed, 235 insertions(+), 4 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 8788302..256af15 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -17,11 +17,35 @@
 #define _LINUX_SUSPEND_BLOCKER_H
 
 #include <linux/list.h>
+#include <linux/ktime.h>
+
+/**
+ * struct suspend_blocker_stats - statistics for a suspend blocker
+ *
+ * @count: Number of times this blocker has been deacivated.
+ * @wakeup_count: Number of times this blocker was the first to block suspend
+ *	after resume.
+ * @total_time: Total time this suspend blocker has prevented suspend.
+ * @prevent_suspend_time: Time this suspend blocker has prevented suspend while
+ *	user-space requested suspend.
+ * @max_time: Max time this suspend blocker has been continuously active.
+ * @last_time: Monotonic clock when the active state last changed.
+ */
+struct suspend_blocker_stats {
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	unsigned int count;
+	unsigned int wakeup_count;
+	ktime_t total_time;
+	ktime_t prevent_suspend_time;
+	ktime_t max_time;
+	ktime_t last_time;
+#endif
+};
 
 /**
  * struct suspend_blocker - the basic suspend_blocker structure
  * @link: List entry for active or inactive list.
- * @flags: Tracks initialized and active state.
+ * @flags: Tracks initialized and active state and statistics.
  * @name: Suspend blocker name used for debugging.
  *
  * When a suspend_blocker is active it prevents the system from entering
@@ -34,6 +58,7 @@ struct suspend_blocker {
 	struct list_head link;
 	int flags;
 	const char *name;
+	struct suspend_blocker_stats stat;
 #endif
 };
 
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2e665cd..16a2570 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,14 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config SUSPEND_BLOCKER_STATS
+	bool "Suspend blockers statistics"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  Use /sys/kernel/debug/suspend_blockers to report suspend blockers
+	  statistics.
+
 config USER_SUSPEND_BLOCKERS
 	bool "User space suspend blockers"
 	depends on OPPORTUNISTIC_SUSPEND
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index 6b5eb1d..a8824ba 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -39,6 +39,7 @@ module_param_named(unknown_wakeup_delay_msecs, unknown_wakeup_delay_msecs, int,
 
 #define SB_INITIALIZED            (1U << 8)
 #define SB_ACTIVE                 (1U << 9)
+#define SB_PREVENTING_SUSPEND     (1U << 10)
 
 DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
 
@@ -51,6 +52,117 @@ static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
 static bool enable_suspend_blockers;
 static DEFINE_SUSPEND_BLOCKER(unknown_wakeup, unknown_wakeups);
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static struct suspend_blocker_stats dropped_suspend_blockers;
+static ktime_t last_sleep_time_update;
+static bool wait_for_wakeup;
+
+static void suspend_blocker_stat_init(struct suspend_blocker_stats *stat)
+{
+	stat->count = 0;
+	stat->wakeup_count = 0;
+	stat->total_time = ktime_set(0, 0);
+	stat->prevent_suspend_time = ktime_set(0, 0);
+	stat->max_time = ktime_set(0, 0);
+	stat->last_time = ktime_set(0, 0);
+}
+
+static void init_dropped_suspend_blockers(void)
+{
+	suspend_blocker_stat_init(&dropped_suspend_blockers);
+}
+
+static void suspend_blocker_stat_drop(struct suspend_blocker_stats *stat)
+{
+	if (!stat->count)
+		return;
+
+	dropped_suspend_blockers.count += stat->count;
+	dropped_suspend_blockers.total_time = ktime_add(
+		dropped_suspend_blockers.total_time, stat->total_time);
+	dropped_suspend_blockers.prevent_suspend_time = ktime_add(
+		dropped_suspend_blockers.prevent_suspend_time,
+		stat->prevent_suspend_time);
+	dropped_suspend_blockers.max_time = ktime_add(
+		dropped_suspend_blockers.max_time, stat->max_time);
+}
+
+static void suspend_unblock_stat(struct suspend_blocker *blocker)
+{
+	struct suspend_blocker_stats *stat = &blocker->stat;
+	ktime_t duration;
+	ktime_t now;
+
+	if (!(blocker->flags & SB_ACTIVE))
+		return;
+
+	now = ktime_get();
+	stat->count++;
+	duration = ktime_sub(now, stat->last_time);
+	stat->total_time = ktime_add(stat->total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(stat->max_time))
+		stat->max_time = duration;
+
+	stat->last_time = ktime_get();
+	if (blocker->flags & SB_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		stat->prevent_suspend_time = ktime_add(
+			stat->prevent_suspend_time, duration);
+		blocker->flags &= ~SB_PREVENTING_SUSPEND;
+	}
+}
+
+static void suspend_block_stat(struct suspend_blocker *blocker)
+{
+	if (wait_for_wakeup) {
+		if (debug_mask & DEBUG_WAKEUP)
+			pr_info("wakeup suspend blocker: %s\n", blocker->name);
+
+		wait_for_wakeup = false;
+		blocker->stat.wakeup_count++;
+	}
+	if (!(blocker->flags & SB_ACTIVE))
+		blocker->stat.last_time = ktime_get();
+}
+
+static void update_sleep_wait_stats(bool done)
+{
+	struct suspend_blocker *blocker;
+	ktime_t now, elapsed, add;
+
+	now = ktime_get();
+	elapsed = ktime_sub(now, last_sleep_time_update);
+	list_for_each_entry(blocker, &active_blockers, link) {
+		struct suspend_blocker_stats *stat = &blocker->stat;
+
+		if (blocker->flags & SB_PREVENTING_SUSPEND) {
+			add = elapsed;
+			stat->prevent_suspend_time = ktime_add(
+				stat->prevent_suspend_time, add);
+		}
+		if (done)
+			blocker->flags &= ~SB_PREVENTING_SUSPEND;
+		else
+			blocker->flags |= SB_PREVENTING_SUSPEND;
+	}
+	last_sleep_time_update = now;
+}
+
+void about_to_enter_suspend(void)
+{
+	wait_for_wakeup = true;
+}
+
+#else /* !CONFIG_SUSPEND_BLOCKER_STATS */
+
+static inline void init_dropped_suspend_blockers(void) {}
+static inline void suspend_blocker_stat_init(struct suspend_blocker_stats *s) {}
+static inline void suspend_blocker_stat_drop(struct suspend_blocker_stats *s) {}
+static inline void suspend_unblock_stat(struct suspend_blocker *blocker) {}
+static inline void suspend_block_stat(struct suspend_blocker *blocker) {}
+static inline void update_sleep_wait_stats(bool done) {}
+#endif /* !CONFIG_SUSPEND_BLOCKER_STATS */
+
 #define pr_info_time(fmt, args...) \
 	do { \
 		struct timespec ts; \
@@ -140,6 +252,8 @@ void suspend_blocker_register(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: Registering %s\n", __func__, blocker->name);
 
+	suspend_blocker_stat_init(&blocker->stat);
+
 	blocker->flags = SB_INITIALIZED;
 	INIT_LIST_HEAD(&blocker->link);
 
@@ -177,6 +291,10 @@ void suspend_blocker_unregister(struct suspend_blocker *blocker)
 		return;
 
 	spin_lock_irqsave(&list_lock, irqflags);
+
+	suspend_unblock_stat(blocker);
+	suspend_blocker_stat_drop(&blocker->stat);
+
 	blocker->flags &= ~SB_INITIALIZED;
 	list_del(&blocker->link);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -206,11 +324,18 @@ void suspend_block(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_block_stat(blocker);
+
 	blocker->flags |= SB_ACTIVE;
 	list_move(&blocker->link, &active_blockers);
 
 	current_event_num++;
 
+	if (blocker == &main_suspend_blocker)
+		update_sleep_wait_stats(true);
+	else if (!suspend_blocker_is_active(&main_suspend_blocker))
+		update_sleep_wait_stats(false);
+
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
 EXPORT_SYMBOL(suspend_block);
@@ -235,13 +360,19 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_unblock_stat(blocker);
+
 	list_move(&blocker->link, &inactive_blockers);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
 		queue_work(pm_wq, &suspend_work);
 	blocker->flags &= ~(SB_ACTIVE);
 
-	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
-		print_active_suspend_blockers();
+	if (blocker == &main_suspend_blocker) {
+		if (debug_mask & DEBUG_SUSPEND)
+			print_active_suspend_blockers();
+
+		update_sleep_wait_stats(false);
+	}
 
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -297,10 +428,68 @@ void __init opportunistic_suspend_init(void)
 	suspend_blocker_register(&main_suspend_blocker);
 	suspend_block(&main_suspend_blocker);
 	suspend_blocker_register(&unknown_wakeup);
+	init_dropped_suspend_blockers();
 }
 
 static struct dentry *suspend_blocker_stats_dentry;
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static int print_blocker_stats(struct seq_file *m, const char *name,
+				struct suspend_blocker_stats *stat, int flags)
+{
+	int lock_count = stat->count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = stat->total_time;
+	ktime_t max_time = stat->max_time;
+	ktime_t prevent_suspend_time = stat->prevent_suspend_time;
+
+	if (flags & SB_ACTIVE) {
+		ktime_t now, add_time;
+
+		now = ktime_get();
+		add_time = ktime_sub(now, stat->last_time);
+		lock_count++;
+		active_time = add_time;
+		total_time = ktime_add(total_time, add_time);
+		if (flags & SB_PREVENTING_SUSPEND)
+			prevent_suspend_time = ktime_add(prevent_suspend_time,
+					ktime_sub(now, last_sleep_time_update));
+		if (add_time.tv64 > max_time.tv64)
+			max_time = add_time;
+	}
+
+	return seq_printf(m, "\"%s\"\t%d\t%d\t%lld\t%lld\t%lld\t%lld\t%lld\n",
+			name, lock_count, stat->wakeup_count,
+			ktime_to_ns(active_time), ktime_to_ns(total_time),
+			ktime_to_ns(prevent_suspend_time),
+			ktime_to_ns(max_time),
+			ktime_to_ns(stat->last_time));
+}
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tcount\twake_count\tactive_since"
+		 "\ttotal_time\tsleep_time\tmax_time\tlast_change\n");
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &active_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	print_blocker_stats(m, "deleted", &dropped_suspend_blockers, 0);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+#else
+
 static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 {
 	unsigned long irqflags;
@@ -316,6 +505,8 @@ static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 	return 0;
 }
 
+#endif
+
 static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
 {
 	return single_open(file, suspend_blocker_stats_show, NULL);
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 2e9cfd5..e13c975 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -245,3 +245,8 @@ extern void __init opportunistic_suspend_init(void);
 #else
 static inline void opportunistic_suspend_init(void) {}
 #endif
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+void about_to_enter_suspend(void);
+#else
+static inline void about_to_enter_suspend(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 9eb3876..df694e7 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -158,8 +158,10 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE)) {
+			about_to_enter_suspend();
 			error = suspend_ops->enter(state);
+		}
 		sysdev_resume();
 	}
 
-- 
1.6.5.1

[PATCH 5/8] PM: suspend_block: Add suspend_blocker stats

[Arve Hjønnevåg]

Report suspend block stats in /sys/kernel/debug/suspend_blockers.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 include/linux/suspend_blocker.h      |   27 +++++-
 kernel/power/Kconfig                 |    8 ++
 kernel/power/opportunistic_suspend.c |  195 +++++++++++++++++++++++++++++++++-
 kernel/power/power.h                 |    5 +
 kernel/power/suspend.c               |    4 +-
 5 files changed, 235 insertions(+), 4 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 8788302..256af15 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -17,11 +17,35 @@
 #define _LINUX_SUSPEND_BLOCKER_H
 
 #include <linux/list.h>
+#include <linux/ktime.h>
+
+/**
+ * struct suspend_blocker_stats - statistics for a suspend blocker
+ *
+ * @count: Number of times this blocker has been deacivated.
+ * @wakeup_count: Number of times this blocker was the first to block suspend
+ *	after resume.
+ * @total_time: Total time this suspend blocker has prevented suspend.
+ * @prevent_suspend_time: Time this suspend blocker has prevented suspend while
+ *	user-space requested suspend.
+ * @max_time: Max time this suspend blocker has been continuously active.
+ * @last_time: Monotonic clock when the active state last changed.
+ */
+struct suspend_blocker_stats {
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+	unsigned int count;
+	unsigned int wakeup_count;
+	ktime_t total_time;
+	ktime_t prevent_suspend_time;
+	ktime_t max_time;
+	ktime_t last_time;
+#endif
+};
 
 /**
  * struct suspend_blocker - the basic suspend_blocker structure
  * @link: List entry for active or inactive list.
- * @flags: Tracks initialized and active state.
+ * @flags: Tracks initialized and active state and statistics.
  * @name: Suspend blocker name used for debugging.
  *
  * When a suspend_blocker is active it prevents the system from entering
@@ -34,6 +58,7 @@ struct suspend_blocker {
 	struct list_head link;
 	int flags;
 	const char *name;
+	struct suspend_blocker_stats stat;
 #endif
 };
 
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2e665cd..16a2570 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -146,6 +146,14 @@ config OPPORTUNISTIC_SUSPEND
 	  determines the sleep state the system will be put into when there are
 	  no active suspend blockers.
 
+config SUSPEND_BLOCKER_STATS
+	bool "Suspend blockers statistics"
+	depends on OPPORTUNISTIC_SUSPEND
+	default y
+	---help---
+	  Use /sys/kernel/debug/suspend_blockers to report suspend blockers
+	  statistics.
+
 config USER_SUSPEND_BLOCKERS
 	bool "User space suspend blockers"
 	depends on OPPORTUNISTIC_SUSPEND
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index 6b5eb1d..a8824ba 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -39,6 +39,7 @@ module_param_named(unknown_wakeup_delay_msecs, unknown_wakeup_delay_msecs, int,
 
 #define SB_INITIALIZED            (1U << 8)
 #define SB_ACTIVE                 (1U << 9)
+#define SB_PREVENTING_SUSPEND     (1U << 10)
 
 DEFINE_SUSPEND_BLOCKER(main_suspend_blocker, main);
 
@@ -51,6 +52,117 @@ static suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
 static bool enable_suspend_blockers;
 static DEFINE_SUSPEND_BLOCKER(unknown_wakeup, unknown_wakeups);
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static struct suspend_blocker_stats dropped_suspend_blockers;
+static ktime_t last_sleep_time_update;
+static bool wait_for_wakeup;
+
+static void suspend_blocker_stat_init(struct suspend_blocker_stats *stat)
+{
+	stat->count = 0;
+	stat->wakeup_count = 0;
+	stat->total_time = ktime_set(0, 0);
+	stat->prevent_suspend_time = ktime_set(0, 0);
+	stat->max_time = ktime_set(0, 0);
+	stat->last_time = ktime_set(0, 0);
+}
+
+static void init_dropped_suspend_blockers(void)
+{
+	suspend_blocker_stat_init(&dropped_suspend_blockers);
+}
+
+static void suspend_blocker_stat_drop(struct suspend_blocker_stats *stat)
+{
+	if (!stat->count)
+		return;
+
+	dropped_suspend_blockers.count += stat->count;
+	dropped_suspend_blockers.total_time = ktime_add(
+		dropped_suspend_blockers.total_time, stat->total_time);
+	dropped_suspend_blockers.prevent_suspend_time = ktime_add(
+		dropped_suspend_blockers.prevent_suspend_time,
+		stat->prevent_suspend_time);
+	dropped_suspend_blockers.max_time = ktime_add(
+		dropped_suspend_blockers.max_time, stat->max_time);
+}
+
+static void suspend_unblock_stat(struct suspend_blocker *blocker)
+{
+	struct suspend_blocker_stats *stat = &blocker->stat;
+	ktime_t duration;
+	ktime_t now;
+
+	if (!(blocker->flags & SB_ACTIVE))
+		return;
+
+	now = ktime_get();
+	stat->count++;
+	duration = ktime_sub(now, stat->last_time);
+	stat->total_time = ktime_add(stat->total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(stat->max_time))
+		stat->max_time = duration;
+
+	stat->last_time = ktime_get();
+	if (blocker->flags & SB_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		stat->prevent_suspend_time = ktime_add(
+			stat->prevent_suspend_time, duration);
+		blocker->flags &= ~SB_PREVENTING_SUSPEND;
+	}
+}
+
+static void suspend_block_stat(struct suspend_blocker *blocker)
+{
+	if (wait_for_wakeup) {
+		if (debug_mask & DEBUG_WAKEUP)
+			pr_info("wakeup suspend blocker: %s\n", blocker->name);
+
+		wait_for_wakeup = false;
+		blocker->stat.wakeup_count++;
+	}
+	if (!(blocker->flags & SB_ACTIVE))
+		blocker->stat.last_time = ktime_get();
+}
+
+static void update_sleep_wait_stats(bool done)
+{
+	struct suspend_blocker *blocker;
+	ktime_t now, elapsed, add;
+
+	now = ktime_get();
+	elapsed = ktime_sub(now, last_sleep_time_update);
+	list_for_each_entry(blocker, &active_blockers, link) {
+		struct suspend_blocker_stats *stat = &blocker->stat;
+
+		if (blocker->flags & SB_PREVENTING_SUSPEND) {
+			add = elapsed;
+			stat->prevent_suspend_time = ktime_add(
+				stat->prevent_suspend_time, add);
+		}
+		if (done)
+			blocker->flags &= ~SB_PREVENTING_SUSPEND;
+		else
+			blocker->flags |= SB_PREVENTING_SUSPEND;
+	}
+	last_sleep_time_update = now;
+}
+
+void about_to_enter_suspend(void)
+{
+	wait_for_wakeup = true;
+}
+
+#else /* !CONFIG_SUSPEND_BLOCKER_STATS */
+
+static inline void init_dropped_suspend_blockers(void) {}
+static inline void suspend_blocker_stat_init(struct suspend_blocker_stats *s) {}
+static inline void suspend_blocker_stat_drop(struct suspend_blocker_stats *s) {}
+static inline void suspend_unblock_stat(struct suspend_blocker *blocker) {}
+static inline void suspend_block_stat(struct suspend_blocker *blocker) {}
+static inline void update_sleep_wait_stats(bool done) {}
+#endif /* !CONFIG_SUSPEND_BLOCKER_STATS */
+
 #define pr_info_time(fmt, args...) \
 	do { \
 		struct timespec ts; \
@@ -140,6 +252,8 @@ void suspend_blocker_register(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: Registering %s\n", __func__, blocker->name);
 
+	suspend_blocker_stat_init(&blocker->stat);
+
 	blocker->flags = SB_INITIALIZED;
 	INIT_LIST_HEAD(&blocker->link);
 
@@ -177,6 +291,10 @@ void suspend_blocker_unregister(struct suspend_blocker *blocker)
 		return;
 
 	spin_lock_irqsave(&list_lock, irqflags);
+
+	suspend_unblock_stat(blocker);
+	suspend_blocker_stat_drop(&blocker->stat);
+
 	blocker->flags &= ~SB_INITIALIZED;
 	list_del(&blocker->link);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
@@ -206,11 +324,18 @@ void suspend_block(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_block_stat(blocker);
+
 	blocker->flags |= SB_ACTIVE;
 	list_move(&blocker->link, &active_blockers);
 
 	current_event_num++;
 
+	if (blocker == &main_suspend_blocker)
+		update_sleep_wait_stats(true);
+	else if (!suspend_blocker_is_active(&main_suspend_blocker))
+		update_sleep_wait_stats(false);
+
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
 EXPORT_SYMBOL(suspend_block);
@@ -235,13 +360,19 @@ void suspend_unblock(struct suspend_blocker *blocker)
 	if (debug_mask & DEBUG_SUSPEND_BLOCKER)
 		pr_info("%s: %s\n", __func__, blocker->name);
 
+	suspend_unblock_stat(blocker);
+
 	list_move(&blocker->link, &inactive_blockers);
 	if ((blocker->flags & SB_ACTIVE) && list_empty(&active_blockers))
 		queue_work(pm_wq, &suspend_work);
 	blocker->flags &= ~(SB_ACTIVE);
 
-	if ((debug_mask & DEBUG_SUSPEND) && blocker == &main_suspend_blocker)
-		print_active_suspend_blockers();
+	if (blocker == &main_suspend_blocker) {
+		if (debug_mask & DEBUG_SUSPEND)
+			print_active_suspend_blockers();
+
+		update_sleep_wait_stats(false);
+	}
 
 	spin_unlock_irqrestore(&list_lock, irqflags);
 }
@@ -297,10 +428,68 @@ void __init opportunistic_suspend_init(void)
 	suspend_blocker_register(&main_suspend_blocker);
 	suspend_block(&main_suspend_blocker);
 	suspend_blocker_register(&unknown_wakeup);
+	init_dropped_suspend_blockers();
 }
 
 static struct dentry *suspend_blocker_stats_dentry;
 
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+static int print_blocker_stats(struct seq_file *m, const char *name,
+				struct suspend_blocker_stats *stat, int flags)
+{
+	int lock_count = stat->count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = stat->total_time;
+	ktime_t max_time = stat->max_time;
+	ktime_t prevent_suspend_time = stat->prevent_suspend_time;
+
+	if (flags & SB_ACTIVE) {
+		ktime_t now, add_time;
+
+		now = ktime_get();
+		add_time = ktime_sub(now, stat->last_time);
+		lock_count++;
+		active_time = add_time;
+		total_time = ktime_add(total_time, add_time);
+		if (flags & SB_PREVENTING_SUSPEND)
+			prevent_suspend_time = ktime_add(prevent_suspend_time,
+					ktime_sub(now, last_sleep_time_update));
+		if (add_time.tv64 > max_time.tv64)
+			max_time = add_time;
+	}
+
+	return seq_printf(m, "\"%s\"\t%d\t%d\t%lld\t%lld\t%lld\t%lld\t%lld\n",
+			name, lock_count, stat->wakeup_count,
+			ktime_to_ns(active_time), ktime_to_ns(total_time),
+			ktime_to_ns(prevent_suspend_time),
+			ktime_to_ns(max_time),
+			ktime_to_ns(stat->last_time));
+}
+
+static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
+{
+	unsigned long irqflags;
+	struct suspend_blocker *blocker;
+
+	seq_puts(m, "name\tcount\twake_count\tactive_since"
+		 "\ttotal_time\tsleep_time\tmax_time\tlast_change\n");
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(blocker, &active_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	list_for_each_entry(blocker, &inactive_blockers, link)
+		print_blocker_stats(m,
+				blocker->name, &blocker->stat, blocker->flags);
+
+	print_blocker_stats(m, "deleted", &dropped_suspend_blockers, 0);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return 0;
+}
+
+#else
+
 static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 {
 	unsigned long irqflags;
@@ -316,6 +505,8 @@ static int suspend_blocker_stats_show(struct seq_file *m, void *unused)
 	return 0;
 }
 
+#endif
+
 static int suspend_blocker_stats_open(struct inode *inode, struct file *file)
 {
 	return single_open(file, suspend_blocker_stats_show, NULL);
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 2e9cfd5..e13c975 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -245,3 +245,8 @@ extern void __init opportunistic_suspend_init(void);
 #else
 static inline void opportunistic_suspend_init(void) {}
 #endif
+#ifdef CONFIG_SUSPEND_BLOCKER_STATS
+void about_to_enter_suspend(void);
+#else
+static inline void about_to_enter_suspend(void) {}
+#endif
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 9eb3876..df694e7 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -158,8 +158,10 @@ static int suspend_enter(suspend_state_t state)
 
 	error = sysdev_suspend(PMSG_SUSPEND);
 	if (!error) {
-		if (!suspend_is_blocked() && !suspend_test(TEST_CORE))
+		if (!suspend_is_blocked() && !suspend_test(TEST_CORE)) {
+			about_to_enter_suspend();
 			error = suspend_ops->enter(state);
+		}
 		sysdev_resume();
 	}
 
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 6/8] PM: Add suspend blocking work.

[Arve Hjønnevåg]

Allow work to be queued that will block suspend while it is pending
or executing. To get the same functionality in the calling code often
requires a separate suspend_blocker for pending and executing work, or
additional state and locking. This implementation does add additional
state and locking, but this can be removed later if we add support for
suspend blocking work to the core workqueue code.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 include/linux/suspend_blocker.h      |   67 +++++++++++++++++++++
 kernel/power/opportunistic_suspend.c |  109 ++++++++++++++++++++++++++++++++++
 2 files changed, 176 insertions(+), 0 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 256af15..bb90b45 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -18,6 +18,7 @@
 
 #include <linux/list.h>
 #include <linux/ktime.h>
+#include <linux/workqueue.h>
 
 /**
  * struct suspend_blocker_stats - statistics for a suspend blocker
@@ -62,6 +63,38 @@ struct suspend_blocker {
 #endif
 };
 
+/**
+ * struct suspend_blocking_work - the basic suspend_blocking_work structure
+ * @work:		Standard work struct.
+ * @suspend_blocker:	Suspend blocker.
+ * @func:		Callback.
+ * @lock:		Spinlock protecting pending and running state.
+ * @active:		Number of cpu workqueues where work is pending or
+ *			callback is running.
+ *
+ * When suspend blocking work is pending or its callback is running it prevents
+ * the system from entering opportunistic suspend.
+ *
+ * The suspend_blocking_work structure must be initialized by
+ * suspend_blocking_work_init().
+ */
+
+struct suspend_blocking_work {
+	struct work_struct work;
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct suspend_blocker suspend_blocker;
+	work_func_t func;
+	spinlock_t lock;
+	int active;
+#endif
+};
+
+static inline struct suspend_blocking_work *to_suspend_blocking_work(
+	struct work_struct *work)
+{
+	return container_of(work, struct suspend_blocking_work, work);
+}
+
 #ifdef CONFIG_OPPORTUNISTIC_SUSPEND
 #define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
 	{ .name = #blocker_name, }
@@ -78,6 +111,14 @@ extern void suspend_unblock(struct suspend_blocker *blocker);
 extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
 extern bool suspend_is_blocked(void);
 
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name);
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work);
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work);
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work);
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work);
+
 #else
 
 #define DEFINE_SUSPEND_BLOCKER(blocker, name) \
@@ -94,6 +135,32 @@ static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
 	return false;
 }
 static inline bool suspend_is_blocked(void) { return false; }
+
+static inline void suspend_blocking_work_init(
+	struct suspend_blocking_work *work, work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, func);
+}
+static inline void suspend_blocking_work_destroy(
+	struct suspend_blocking_work *work)
+{
+	cancel_work_sync(&work->work);
+}
+static inline int queue_suspend_blocking_work(
+	struct workqueue_struct *wq, struct suspend_blocking_work *work)
+{
+	return queue_work(wq, &work->work);
+}
+static inline int schedule_suspend_blocking_work(
+	struct suspend_blocking_work *work)
+{
+	return schedule_work(&work->work);
+}
+static inline int cancel_suspend_blocking_work_sync(
+	struct suspend_blocking_work *work)
+{
+	return cancel_work_sync(&work->work);
+}
 #endif
 
 #endif
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index a8824ba..3af0ed3 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -528,3 +528,112 @@ static int __init suspend_blocker_debugfs_init(void)
 }
 
 postcore_initcall(suspend_blocker_debugfs_init);
+
+static void suspend_blocking_work_complete(struct suspend_blocking_work *work)
+{
+	unsigned long flags;
+
+	WARN_ON(!work->active);
+	spin_lock_irqsave(&work->lock, flags);
+	if (!--work->active)
+		suspend_unblock(&work->suspend_blocker);
+	spin_unlock_irqrestore(&work->lock, flags);
+}
+
+static void suspend_blocking_work_func(struct work_struct *work)
+{
+	struct suspend_blocking_work *sbwork = to_suspend_blocking_work(work);
+
+	sbwork->func(work);
+	suspend_blocking_work_complete(sbwork);
+}
+
+/**
+ * suspend_blocking_work_init - Initialize a suspend-blocking work item.
+ * @work: Work item to initialize.
+ * @func: Callback.
+ * @name: Name for suspend blocker.
+ *
+ */
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, suspend_blocking_work_func);
+	suspend_blocker_init(&work->suspend_blocker, name);
+	work->func = func;
+	spin_lock_init(&work->lock);
+	work->active = 0;
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_init);
+
+/**
+ * cancel_suspend_blocking_work_sync - Cancel a suspend-blocking work item.
+ * @work: Work item to handle.
+ */
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work)
+{
+	int ret;
+
+	ret = cancel_work_sync(&work->work);
+	if (ret)
+		suspend_blocking_work_complete(work);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cancel_suspend_blocking_work_sync);
+
+/**
+ * suspend_blocking_work_destroy - Destroy a suspend-blocking work item.
+ * @work: The work item in question.
+ *
+ * If the work was ever queued on more then one workqueue all but the last
+ * workqueue must be flushed before calling suspend_blocking_work_destroy.
+ */
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work)
+{
+	cancel_suspend_blocking_work_sync(work);
+	WARN_ON(work->active);
+	suspend_blocker_unregister(&work->suspend_blocker);
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_destroy);
+
+/**
+ * queue_suspend_blocking_work - Queue a suspend-blocking work item.
+ * @wq: Workqueue to queue the work on.
+ * @work: Work item to queue.
+ */
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = queue_work(wq, &work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(queue_suspend_blocking_work);
+
+/**
+ * schedule_suspend_blocking_work - Schedule a suspend-blocking work item.
+ * @work: Work item to schedule.
+ */
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = schedule_work(&work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(schedule_suspend_blocking_work);
-- 
1.6.5.1

[PATCH 6/8] PM: Add suspend blocking work.

[Arve Hjønnevåg]

Allow work to be queued that will block suspend while it is pending
or executing. To get the same functionality in the calling code often
requires a separate suspend_blocker for pending and executing work, or
additional state and locking. This implementation does add additional
state and locking, but this can be removed later if we add support for
suspend blocking work to the core workqueue code.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
 include/linux/suspend_blocker.h      |   67 +++++++++++++++++++++
 kernel/power/opportunistic_suspend.c |  109 ++++++++++++++++++++++++++++++++++
 2 files changed, 176 insertions(+), 0 deletions(-)

diff --git a/include/linux/suspend_blocker.h b/include/linux/suspend_blocker.h
index 256af15..bb90b45 100755
--- a/include/linux/suspend_blocker.h
+++ b/include/linux/suspend_blocker.h
@@ -18,6 +18,7 @@
 
 #include <linux/list.h>
 #include <linux/ktime.h>
+#include <linux/workqueue.h>
 
 /**
  * struct suspend_blocker_stats - statistics for a suspend blocker
@@ -62,6 +63,38 @@ struct suspend_blocker {
 #endif
 };
 
+/**
+ * struct suspend_blocking_work - the basic suspend_blocking_work structure
+ * @work:		Standard work struct.
+ * @suspend_blocker:	Suspend blocker.
+ * @func:		Callback.
+ * @lock:		Spinlock protecting pending and running state.
+ * @active:		Number of cpu workqueues where work is pending or
+ *			callback is running.
+ *
+ * When suspend blocking work is pending or its callback is running it prevents
+ * the system from entering opportunistic suspend.
+ *
+ * The suspend_blocking_work structure must be initialized by
+ * suspend_blocking_work_init().
+ */
+
+struct suspend_blocking_work {
+	struct work_struct work;
+#ifdef CONFIG_OPPORTUNISTIC_SUSPEND
+	struct suspend_blocker suspend_blocker;
+	work_func_t func;
+	spinlock_t lock;
+	int active;
+#endif
+};
+
+static inline struct suspend_blocking_work *to_suspend_blocking_work(
+	struct work_struct *work)
+{
+	return container_of(work, struct suspend_blocking_work, work);
+}
+
 #ifdef CONFIG_OPPORTUNISTIC_SUSPEND
 #define __SUSPEND_BLOCKER_INITIALIZER(blocker_name) \
 	{ .name = #blocker_name, }
@@ -78,6 +111,14 @@ extern void suspend_unblock(struct suspend_blocker *blocker);
 extern bool suspend_blocker_is_active(struct suspend_blocker *blocker);
 extern bool suspend_is_blocked(void);
 
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name);
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work);
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work);
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work);
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work);
+
 #else
 
 #define DEFINE_SUSPEND_BLOCKER(blocker, name) \
@@ -94,6 +135,32 @@ static inline bool suspend_blocker_is_active(struct suspend_blocker *bl)
 	return false;
 }
 static inline bool suspend_is_blocked(void) { return false; }
+
+static inline void suspend_blocking_work_init(
+	struct suspend_blocking_work *work, work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, func);
+}
+static inline void suspend_blocking_work_destroy(
+	struct suspend_blocking_work *work)
+{
+	cancel_work_sync(&work->work);
+}
+static inline int queue_suspend_blocking_work(
+	struct workqueue_struct *wq, struct suspend_blocking_work *work)
+{
+	return queue_work(wq, &work->work);
+}
+static inline int schedule_suspend_blocking_work(
+	struct suspend_blocking_work *work)
+{
+	return schedule_work(&work->work);
+}
+static inline int cancel_suspend_blocking_work_sync(
+	struct suspend_blocking_work *work)
+{
+	return cancel_work_sync(&work->work);
+}
 #endif
 
 #endif
diff --git a/kernel/power/opportunistic_suspend.c b/kernel/power/opportunistic_suspend.c
index a8824ba..3af0ed3 100644
--- a/kernel/power/opportunistic_suspend.c
+++ b/kernel/power/opportunistic_suspend.c
@@ -528,3 +528,112 @@ static int __init suspend_blocker_debugfs_init(void)
 }
 
 postcore_initcall(suspend_blocker_debugfs_init);
+
+static void suspend_blocking_work_complete(struct suspend_blocking_work *work)
+{
+	unsigned long flags;
+
+	WARN_ON(!work->active);
+	spin_lock_irqsave(&work->lock, flags);
+	if (!--work->active)
+		suspend_unblock(&work->suspend_blocker);
+	spin_unlock_irqrestore(&work->lock, flags);
+}
+
+static void suspend_blocking_work_func(struct work_struct *work)
+{
+	struct suspend_blocking_work *sbwork = to_suspend_blocking_work(work);
+
+	sbwork->func(work);
+	suspend_blocking_work_complete(sbwork);
+}
+
+/**
+ * suspend_blocking_work_init - Initialize a suspend-blocking work item.
+ * @work: Work item to initialize.
+ * @func: Callback.
+ * @name: Name for suspend blocker.
+ *
+ */
+void suspend_blocking_work_init(struct suspend_blocking_work *work,
+				work_func_t func, const char *name)
+{
+	INIT_WORK(&work->work, suspend_blocking_work_func);
+	suspend_blocker_init(&work->suspend_blocker, name);
+	work->func = func;
+	spin_lock_init(&work->lock);
+	work->active = 0;
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_init);
+
+/**
+ * cancel_suspend_blocking_work_sync - Cancel a suspend-blocking work item.
+ * @work: Work item to handle.
+ */
+int cancel_suspend_blocking_work_sync(struct suspend_blocking_work *work)
+{
+	int ret;
+
+	ret = cancel_work_sync(&work->work);
+	if (ret)
+		suspend_blocking_work_complete(work);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cancel_suspend_blocking_work_sync);
+
+/**
+ * suspend_blocking_work_destroy - Destroy a suspend-blocking work item.
+ * @work: The work item in question.
+ *
+ * If the work was ever queued on more then one workqueue all but the last
+ * workqueue must be flushed before calling suspend_blocking_work_destroy.
+ */
+void suspend_blocking_work_destroy(struct suspend_blocking_work *work)
+{
+	cancel_suspend_blocking_work_sync(work);
+	WARN_ON(work->active);
+	suspend_blocker_unregister(&work->suspend_blocker);
+}
+EXPORT_SYMBOL_GPL(suspend_blocking_work_destroy);
+
+/**
+ * queue_suspend_blocking_work - Queue a suspend-blocking work item.
+ * @wq: Workqueue to queue the work on.
+ * @work: Work item to queue.
+ */
+int queue_suspend_blocking_work(struct workqueue_struct *wq,
+				struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = queue_work(wq, &work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(queue_suspend_blocking_work);
+
+/**
+ * schedule_suspend_blocking_work - Schedule a suspend-blocking work item.
+ * @work: Work item to schedule.
+ */
+int schedule_suspend_blocking_work(struct suspend_blocking_work *work)
+{
+	int ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&work->lock, flags);
+	ret = schedule_work(&work->work);
+	if (ret) {
+		suspend_block(&work->suspend_blocker);
+		work->active++;
+	}
+	spin_unlock_irqrestore(&work->lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(schedule_suspend_blocking_work);
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 7/8] Input: Block suspend while event queue is not empty.

[Arve Hjønnevåg]

Add an ioctl, EVIOCSSUSPENDBLOCK, to enable a suspend_blocker that will block
suspend while the event queue is not empty. This allows userspace code to
process input events while the device appears to be asleep.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/input/evdev.c |   22 ++++++++++++++++++++++
 include/linux/input.h |    3 +++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2ee6c7a..bff2247 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -20,6 +20,7 @@
 #include <linux/input.h>
 #include <linux/major.h>
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include "input-compat.h"
 
 struct evdev {
@@ -43,6 +44,8 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	struct suspend_blocker suspend_blocker;
+	bool use_suspend_blocker;
 };
 
 static struct evdev *evdev_table[EVDEV_MINORS];
@@ -55,6 +58,8 @@ static void evdev_pass_event(struct evdev_client *client,
 	 * Interrupts are disabled, just acquire the lock
 	 */
 	spin_lock(&client->buffer_lock);
+	if (client->use_suspend_blocker)
+		suspend_block(&client->suspend_blocker);
 	client->buffer[client->head++] = *event;
 	client->head &= EVDEV_BUFFER_SIZE - 1;
 	spin_unlock(&client->buffer_lock);
@@ -234,6 +239,8 @@ static int evdev_release(struct inode *inode, struct file *file)
 	mutex_unlock(&evdev->mutex);
 
 	evdev_detach_client(evdev, client);
+	if (client->use_suspend_blocker)
+		suspend_blocker_unregister(&client->suspend_blocker);
 	kfree(client);
 
 	evdev_close_device(evdev);
@@ -335,6 +342,8 @@ static int evdev_fetch_next_event(struct evdev_client *client,
 	if (have_event) {
 		*event = client->buffer[client->tail++];
 		client->tail &= EVDEV_BUFFER_SIZE - 1;
+		if (client->use_suspend_blocker && client->head == client->tail)
+			suspend_unblock(&client->suspend_blocker);
 	}
 
 	spin_unlock_irq(&client->buffer_lock);
@@ -585,6 +594,19 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		else
 			return evdev_ungrab(evdev, client);
 
+	case EVIOCGSUSPENDBLOCK:
+		return put_user(client->use_suspend_blocker, ip);
+
+	case EVIOCSSUSPENDBLOCK:
+		spin_lock_irq(&client->buffer_lock);
+		if (!client->use_suspend_blocker && p)
+			suspend_blocker_init(&client->suspend_blocker, "evdev");
+		else if (client->use_suspend_blocker && !p)
+			suspend_blocker_unregister(&client->suspend_blocker);
+		client->use_suspend_blocker = !!p;
+		spin_unlock_irq(&client->buffer_lock);
+		return 0;
+
 	default:
 
 		if (_IOC_TYPE(cmd) != 'E')
diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..b2d93b4 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -82,6 +82,9 @@ struct input_absinfo {
 
 #define EVIOCGRAB		_IOW('E', 0x90, int)			/* Grab/Release device */
 
+#define EVIOCGSUSPENDBLOCK	_IOR('E', 0x91, int)			/* get suspend block enable */
+#define EVIOCSSUSPENDBLOCK	_IOW('E', 0x91, int)			/* set suspend block enable */
+
 /*
  * Event types
  */
-- 
1.6.5.1

[PATCH 7/8] Input: Block suspend while event queue is not empty.

[Arve Hjønnevåg]

Add an ioctl, EVIOCSSUSPENDBLOCK, to enable a suspend_blocker that will block
suspend while the event queue is not empty. This allows userspace code to
process input events while the device appears to be asleep.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/input/evdev.c |   22 ++++++++++++++++++++++
 include/linux/input.h |    3 +++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2ee6c7a..bff2247 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -20,6 +20,7 @@
 #include <linux/input.h>
 #include <linux/major.h>
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include "input-compat.h"
 
 struct evdev {
@@ -43,6 +44,8 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	struct suspend_blocker suspend_blocker;
+	bool use_suspend_blocker;
 };
 
 static struct evdev *evdev_table[EVDEV_MINORS];
@@ -55,6 +58,8 @@ static void evdev_pass_event(struct evdev_client *client,
 	 * Interrupts are disabled, just acquire the lock
 	 */
 	spin_lock(&client->buffer_lock);
+	if (client->use_suspend_blocker)
+		suspend_block(&client->suspend_blocker);
 	client->buffer[client->head++] = *event;
 	client->head &= EVDEV_BUFFER_SIZE - 1;
 	spin_unlock(&client->buffer_lock);
@@ -234,6 +239,8 @@ static int evdev_release(struct inode *inode, struct file *file)
 	mutex_unlock(&evdev->mutex);
 
 	evdev_detach_client(evdev, client);
+	if (client->use_suspend_blocker)
+		suspend_blocker_unregister(&client->suspend_blocker);
 	kfree(client);
 
 	evdev_close_device(evdev);
@@ -335,6 +342,8 @@ static int evdev_fetch_next_event(struct evdev_client *client,
 	if (have_event) {
 		*event = client->buffer[client->tail++];
 		client->tail &= EVDEV_BUFFER_SIZE - 1;
+		if (client->use_suspend_blocker && client->head == client->tail)
+			suspend_unblock(&client->suspend_blocker);
 	}
 
 	spin_unlock_irq(&client->buffer_lock);
@@ -585,6 +594,19 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		else
 			return evdev_ungrab(evdev, client);
 
+	case EVIOCGSUSPENDBLOCK:
+		return put_user(client->use_suspend_blocker, ip);
+
+	case EVIOCSSUSPENDBLOCK:
+		spin_lock_irq(&client->buffer_lock);
+		if (!client->use_suspend_blocker && p)
+			suspend_blocker_init(&client->suspend_blocker, "evdev");
+		else if (client->use_suspend_blocker && !p)
+			suspend_blocker_unregister(&client->suspend_blocker);
+		client->use_suspend_blocker = !!p;
+		spin_unlock_irq(&client->buffer_lock);
+		return 0;
+
 	default:
 
 		if (_IOC_TYPE(cmd) != 'E')
diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..b2d93b4 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -82,6 +82,9 @@ struct input_absinfo {
 
 #define EVIOCGRAB		_IOW('E', 0x90, int)			/* Grab/Release device */
 
+#define EVIOCGSUSPENDBLOCK	_IOR('E', 0x91, int)			/* get suspend block enable */
+#define EVIOCSSUSPENDBLOCK	_IOW('E', 0x91, int)			/* set suspend block enable */
+
 /*
  * Event types
  */
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending

[Arve Hjønnevåg]

When connecting usb or the charger the device would often go back to sleep
before the charge led and screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/power/power_supply_core.c |    9 ++++++---
 include/linux/power_supply.h      |    3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/power/power_supply_core.c b/drivers/power/power_supply_core.c
index cce75b4..577a131 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -39,7 +39,7 @@ static int __power_supply_changed_work(struct device *dev, void *data)
 static void power_supply_changed_work(struct work_struct *work)
 {
 	struct power_supply *psy = container_of(work, struct power_supply,
-						changed_work);
+						changed_work.work);
 
 	dev_dbg(psy->dev, "%s\n", __func__);
 
@@ -55,7 +55,7 @@ void power_supply_changed(struct power_supply *psy)
 {
 	dev_dbg(psy->dev, "%s\n", __func__);
 
-	schedule_work(&psy->changed_work);
+	schedule_suspend_blocking_work(&psy->changed_work);
 }
 EXPORT_SYMBOL_GPL(power_supply_changed);
 
@@ -155,7 +155,8 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 		goto dev_create_failed;
 	}
 
-	INIT_WORK(&psy->changed_work, power_supply_changed_work);
+	suspend_blocking_work_init(&psy->changed_work,
+				   power_supply_changed_work, "power-supply");
 
 	rc = power_supply_create_attrs(psy);
 	if (rc)
@@ -172,6 +173,7 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 create_triggers_failed:
 	power_supply_remove_attrs(psy);
 create_attrs_failed:
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 dev_create_failed:
 success:
@@ -184,6 +186,7 @@ void power_supply_unregister(struct power_supply *psy)
 	flush_scheduled_work();
 	power_supply_remove_triggers(psy);
 	power_supply_remove_attrs(psy);
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 }
 EXPORT_SYMBOL_GPL(power_supply_unregister);
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ebd2b8f..f6412c8 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -14,6 +14,7 @@
 #define __LINUX_POWER_SUPPLY_H__
 
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include <linux/workqueue.h>
 #include <linux/leds.h>
 
@@ -152,7 +153,7 @@ struct power_supply {
 
 	/* private */
 	struct device *dev;
-	struct work_struct changed_work;
+	struct suspend_blocking_work changed_work;
 
 #ifdef CONFIG_LEDS_TRIGGERS
 	struct led_trigger *charging_full_trig;
-- 
1.6.5.1

[PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending

[Arve Hjønnevåg]

When connecting usb or the charger the device would often go back to sleep
before the charge led and screen turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/power/power_supply_core.c |    9 ++++++---
 include/linux/power_supply.h      |    3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/power/power_supply_core.c b/drivers/power/power_supply_core.c
index cce75b4..577a131 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -39,7 +39,7 @@ static int __power_supply_changed_work(struct device *dev, void *data)
 static void power_supply_changed_work(struct work_struct *work)
 {
 	struct power_supply *psy = container_of(work, struct power_supply,
-						changed_work);
+						changed_work.work);
 
 	dev_dbg(psy->dev, "%s\n", __func__);
 
@@ -55,7 +55,7 @@ void power_supply_changed(struct power_supply *psy)
 {
 	dev_dbg(psy->dev, "%s\n", __func__);
 
-	schedule_work(&psy->changed_work);
+	schedule_suspend_blocking_work(&psy->changed_work);
 }
 EXPORT_SYMBOL_GPL(power_supply_changed);
 
@@ -155,7 +155,8 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 		goto dev_create_failed;
 	}
 
-	INIT_WORK(&psy->changed_work, power_supply_changed_work);
+	suspend_blocking_work_init(&psy->changed_work,
+				   power_supply_changed_work, "power-supply");
 
 	rc = power_supply_create_attrs(psy);
 	if (rc)
@@ -172,6 +173,7 @@ int power_supply_register(struct device *parent, struct power_supply *psy)
 create_triggers_failed:
 	power_supply_remove_attrs(psy);
 create_attrs_failed:
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 dev_create_failed:
 success:
@@ -184,6 +186,7 @@ void power_supply_unregister(struct power_supply *psy)
 	flush_scheduled_work();
 	power_supply_remove_triggers(psy);
 	power_supply_remove_attrs(psy);
+	suspend_blocking_work_destroy(&psy->changed_work);
 	device_unregister(psy->dev);
 }
 EXPORT_SYMBOL_GPL(power_supply_unregister);
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ebd2b8f..f6412c8 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -14,6 +14,7 @@
 #define __LINUX_POWER_SUPPLY_H__
 
 #include <linux/device.h>
+#include <linux/suspend.h>
 #include <linux/workqueue.h>
 #include <linux/leds.h>
 
@@ -152,7 +153,7 @@ struct power_supply {
 
 	/* private */
 	struct device *dev;
-	struct work_struct changed_work;
+	struct suspend_blocking_work changed_work;
 
 #ifdef CONFIG_LEDS_TRIGGERS
 	struct led_trigger *charging_full_trig;
-- 
1.6.5.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:

> The first goal can be achieved either by using device runtime PM and
> cpuidle to put all hardware into low-power states, transparently from
> the user space point of view, or by suspending the whole system.
> However, system suspend, in its current form, does not guarantee that
> the events of interest will always be responded to, since wakeup
> events (events that wake the CPU from idle and the system from
> suspend) that occur right after initiating suspend will not be
> processed until another possibly unrelated event wakes the system up
> again.

Minor point of clarification here.  I'm not requesting that the patch 
description be rewritten.  But this issue of lost wakeup events is more 
subtle than it appears.

Wakeup events can be lost in at least three different ways:

     1. A hardware signal (such as an IRQ) gets ignored.

     2. The hardware event occurs, but without effect since the
	kernel thread that would handle the event has been frozen.
	The event just ends up sitting in a queue somewhere until
	something else wakes up the system.

     3. The hardware event occurs and the kernel handles it fully,
	but the event propagates to userspace for further handling
	and the user program is already frozen.

1 is a hardware configuration failure (for example, it might happen as
a result of using edge-triggered IRQs instead of level-triggered) and
is outside the scope of this discussion.

2 generally represents a failure of the core PM subsystem, or a failure
of some other part of the kernel to use the PM core correctly.  In
theory we should be able to fix such mistakes.  Right now I'm aware of
at least one possible failure scenario that could be fixed fairly
easily.

3 is the type of failure that suspend blockers were really meant to
handle, particularly the userspace suspend-blocker API.

IMO, we should strive to fix the existing type-2 failure modes.  
However it is worth pointing out that they are basically separate from 
the suspend-blocker mechanism.

And it might be a good idea to point out somewhere in the patch
descriptions that suspend blockers are really meant to handle type-3
wakeup losses.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:

> The first goal can be achieved either by using device runtime PM and
> cpuidle to put all hardware into low-power states, transparently from
> the user space point of view, or by suspending the whole system.
> However, system suspend, in its current form, does not guarantee that
> the events of interest will always be responded to, since wakeup
> events (events that wake the CPU from idle and the system from
> suspend) that occur right after initiating suspend will not be
> processed until another possibly unrelated event wakes the system up
> again.

Minor point of clarification here.  I'm not requesting that the patch 
description be rewritten.  But this issue of lost wakeup events is more 
subtle than it appears.

Wakeup events can be lost in at least three different ways:

     1. A hardware signal (such as an IRQ) gets ignored.

     2. The hardware event occurs, but without effect since the
	kernel thread that would handle the event has been frozen.
	The event just ends up sitting in a queue somewhere until
	something else wakes up the system.

     3. The hardware event occurs and the kernel handles it fully,
	but the event propagates to userspace for further handling
	and the user program is already frozen.

1 is a hardware configuration failure (for example, it might happen as
a result of using edge-triggered IRQs instead of level-triggered) and
is outside the scope of this discussion.

2 generally represents a failure of the core PM subsystem, or a failure
of some other part of the kernel to use the PM core correctly.  In
theory we should be able to fix such mistakes.  Right now I'm aware of
at least one possible failure scenario that could be fixed fairly
easily.

3 is the type of failure that suspend blockers were really meant to
handle, particularly the userspace suspend-blocker API.

IMO, we should strive to fix the existing type-2 failure modes.  
However it is worth pointing out that they are basically separate from 
the suspend-blocker mechanism.

And it might be a good idea to point out somewhere in the patch
descriptions that suspend blockers are really meant to handle type-3
wakeup losses.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version adds a
> delay before suspending again if no suspend blockers were used
> during the last suspend attempt.

Patches [1-6/8] applied to suspend-2.6/linux-next

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> This patch series adds a suspend-block api that provides the same
> functionality as the android wakelock api. This version adds a
> delay before suspending again if no suspend blockers were used
> during the last suspend attempt.

Patches [1-6/8] applied to suspend-2.6/linux-next

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> This patch series adds a suspend-block api that provides the same
>> functionality as the android wakelock api. This version adds a
>> delay before suspending again if no suspend blockers were used
>> during the last suspend attempt.
>
>Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of 
developers had on the other thread, this series is still taken. What's 
the point in dicussing/reviewing the patches then ?

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> This patch series adds a suspend-block api that provides the same
>> functionality as the android wakelock api. This version adds a
>> delay before suspending again if no suspend blockers were used
>> during the last suspend attempt.
>
>Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of 
developers had on the other thread, this series is still taken. What's 
the point in dicussing/reviewing the patches then ?

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Monday 24 May 2010, Felipe Balbi wrote:
> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version adds a
> >> delay before suspending again if no suspend blockers were used
> >> during the last suspend attempt.
> >
> >Patches [1-6/8] applied to suspend-2.6/linux-next
> 
> funny thing is that even without sorting out the concerns plenty of 
> developers had on the other thread, this series is still taken. What's 
> the point in dicussing/reviewing the patches then ?

I don't think the concerns you're referring to can be solved out.  Some people
just don't like the whole idea and I don't think there's any way we can improve
the patches to make them happy.  The only "solution" they would be satisfied
with would simply be rejecting the feature altogether, although there are no
practically viable alternatives known to me.

OTOH I do think there are quite a few reasons to take the patchset, so I'm
going to push it to Linus as I told in one of my replies to Kevin.  If Linus
decides not to pull it, so be it.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Monday 24 May 2010, Felipe Balbi wrote:
> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version adds a
> >> delay before suspending again if no suspend blockers were used
> >> during the last suspend attempt.
> >
> >Patches [1-6/8] applied to suspend-2.6/linux-next
> 
> funny thing is that even without sorting out the concerns plenty of 
> developers had on the other thread, this series is still taken. What's 
> the point in dicussing/reviewing the patches then ?

I don't think the concerns you're referring to can be solved out.  Some people
just don't like the whole idea and I don't think there's any way we can improve
the patches to make them happy.  The only "solution" they would be satisfied
with would simply be rejecting the feature altogether, although there are no
practically viable alternatives known to me.

OTOH I do think there are quite a few reasons to take the patchset, so I'm
going to push it to Linus as I told in one of my replies to Kevin.  If Linus
decides not to pull it, so be it.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Monday 24 May 2010, Felipe Balbi wrote:
>> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> >> This patch series adds a suspend-block api that provides the same
>> >> functionality as the android wakelock api. This version adds a
>> >> delay before suspending again if no suspend blockers were used
>> >> during the last suspend attempt.
>> >
>> >Patches [1-6/8] applied to suspend-2.6/linux-next
>> 
>> funny thing is that even without sorting out the concerns plenty of 
>> developers had on the other thread, this series is still taken. What's 
>> the point in dicussing/reviewing the patches then ?
>
> I don't think the concerns you're referring to can be solved out.  
> Some people just don't like the whole idea and I don't think there's
> any way we can improve the patches to make them happy.  The only
> "solution" they would be satisfied with would simply be rejecting
> the feature altogether, although there are no practically viable
> alternatives known to me.

I'm not sure who the "some people" you're referring to are, but I'll
assume I'm included in that group.

I don't think this is a fair characterization of the objections, nor
do I think "rejecting the feature altogether" is the only satisfactory
answer.  Speaking for myself, I find the idea of being able to suspend
while idle a valid objective, and certainly see the usefulness of it
for embedded systems.  I'm also an owner and user of an Android phone,
so I am certainly not out just to make life difficult for Android.

The primary objection is not the end goal, but rather the
implementation.  In particular, the problematic redefintion of what it
means to be idle, or "not doing work that's immediately useful to the
user" to use the phrase from the changelog (where "useful" is still
not defined.)

This (re)definition completely bypasses all current idle
infrastructure based on timers, scheduler, etc. and makes "usefulness"
defined in terms of who holds suspend blockers.  This of course will
lead to a scattering of suspend blockers into any drivers/subsystems
considered "useful", which by looking through current Android kernels
is many of them.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Monday 24 May 2010, Felipe Balbi wrote:
>> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> >> This patch series adds a suspend-block api that provides the same
>> >> functionality as the android wakelock api. This version adds a
>> >> delay before suspending again if no suspend blockers were used
>> >> during the last suspend attempt.
>> >
>> >Patches [1-6/8] applied to suspend-2.6/linux-next
>> 
>> funny thing is that even without sorting out the concerns plenty of 
>> developers had on the other thread, this series is still taken. What's 
>> the point in dicussing/reviewing the patches then ?
>
> I don't think the concerns you're referring to can be solved out.  
> Some people just don't like the whole idea and I don't think there's
> any way we can improve the patches to make them happy.  The only
> "solution" they would be satisfied with would simply be rejecting
> the feature altogether, although there are no practically viable
> alternatives known to me.

I'm not sure who the "some people" you're referring to are, but I'll
assume I'm included in that group.

I don't think this is a fair characterization of the objections, nor
do I think "rejecting the feature altogether" is the only satisfactory
answer.  Speaking for myself, I find the idea of being able to suspend
while idle a valid objective, and certainly see the usefulness of it
for embedded systems.  I'm also an owner and user of an Android phone,
so I am certainly not out just to make life difficult for Android.

The primary objection is not the end goal, but rather the
implementation.  In particular, the problematic redefintion of what it
means to be idle, or "not doing work that's immediately useful to the
user" to use the phrase from the changelog (where "useful" is still
not defined.)

This (re)definition completely bypasses all current idle
infrastructure based on timers, scheduler, etc. and makes "usefulness"
defined in terms of who holds suspend blockers.  This of course will
lead to a scattering of suspend blockers into any drivers/subsystems
considered "useful", which by looking through current Android kernels
is many of them.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Monday 24 May 2010, Felipe Balbi wrote:
> >> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> >> This patch series adds a suspend-block api that provides the same
> >> >> functionality as the android wakelock api. This version adds a
> >> >> delay before suspending again if no suspend blockers were used
> >> >> during the last suspend attempt.
> >> >
> >> >Patches [1-6/8] applied to suspend-2.6/linux-next
> >> 
> >> funny thing is that even without sorting out the concerns plenty of 
> >> developers had on the other thread, this series is still taken. What's 
> >> the point in dicussing/reviewing the patches then ?
> >
> > I don't think the concerns you're referring to can be solved out.  
> > Some people just don't like the whole idea and I don't think there's
> > any way we can improve the patches to make them happy.  The only
> > "solution" they would be satisfied with would simply be rejecting
> > the feature altogether, although there are no practically viable
> > alternatives known to me.
> 
> I'm not sure who the "some people" you're referring to are, but I'll
> assume I'm included in that group.
> 
> I don't think this is a fair characterization of the objections, nor
> do I think "rejecting the feature altogether" is the only satisfactory
> answer.  Speaking for myself, I find the idea of being able to suspend
> while idle a valid objective, and certainly see the usefulness of it
> for embedded systems.  I'm also an owner and user of an Android phone,
> so I am certainly not out just to make life difficult for Android.
> 
> The primary objection is not the end goal, but rather the
> implementation.  In particular, the problematic redefintion of what it
> means to be idle, or "not doing work that's immediately useful to the
> user" to use the phrase from the changelog (where "useful" is still
> not defined.)

So, in fact, you don't like the _idea_, because the _idea_ is to use suspend
blockers instead of trying to define what "idle" means.

I don't think it's generally possible to define "idle" to match every possible
criteria one can imagine, so you're request to do that simply cannot be
satisfied.

> This (re)definition completely bypasses all current idle
> infrastructure based on timers, scheduler, etc. and makes "usefulness"
> defined in terms of who holds suspend blockers.

That's because the point is not to suspend when the system is "idle", because
that would mean "suspend transparently from the applications' point of view",
which is what the Android people _don't_ _want_ _to_ _do_, because in that
case their battery life would go to the toilet.  The idea is to suspend even
when the system is not techincally "idle" and you don't like _that_.

> This of course will lead to a scattering of suspend blockers into any
> drivers/subsystems considered "useful", which by looking through current
> Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power
to reject requested changes.

As I said before, I don't think there's a way to resolve this so that everyone
is happy and in my opinion there are reasons to merge the feature.

Also I don't think we can make any progress discussing it.  We've already
discussed it for a month or so without any real progress and I don't see how
that's going to change now.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Monday 24 May 2010, Felipe Balbi wrote:
> >> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> >> This patch series adds a suspend-block api that provides the same
> >> >> functionality as the android wakelock api. This version adds a
> >> >> delay before suspending again if no suspend blockers were used
> >> >> during the last suspend attempt.
> >> >
> >> >Patches [1-6/8] applied to suspend-2.6/linux-next
> >> 
> >> funny thing is that even without sorting out the concerns plenty of 
> >> developers had on the other thread, this series is still taken. What's 
> >> the point in dicussing/reviewing the patches then ?
> >
> > I don't think the concerns you're referring to can be solved out.  
> > Some people just don't like the whole idea and I don't think there's
> > any way we can improve the patches to make them happy.  The only
> > "solution" they would be satisfied with would simply be rejecting
> > the feature altogether, although there are no practically viable
> > alternatives known to me.
> 
> I'm not sure who the "some people" you're referring to are, but I'll
> assume I'm included in that group.
> 
> I don't think this is a fair characterization of the objections, nor
> do I think "rejecting the feature altogether" is the only satisfactory
> answer.  Speaking for myself, I find the idea of being able to suspend
> while idle a valid objective, and certainly see the usefulness of it
> for embedded systems.  I'm also an owner and user of an Android phone,
> so I am certainly not out just to make life difficult for Android.
> 
> The primary objection is not the end goal, but rather the
> implementation.  In particular, the problematic redefintion of what it
> means to be idle, or "not doing work that's immediately useful to the
> user" to use the phrase from the changelog (where "useful" is still
> not defined.)

So, in fact, you don't like the _idea_, because the _idea_ is to use suspend
blockers instead of trying to define what "idle" means.

I don't think it's generally possible to define "idle" to match every possible
criteria one can imagine, so you're request to do that simply cannot be
satisfied.

> This (re)definition completely bypasses all current idle
> infrastructure based on timers, scheduler, etc. and makes "usefulness"
> defined in terms of who holds suspend blockers.

That's because the point is not to suspend when the system is "idle", because
that would mean "suspend transparently from the applications' point of view",
which is what the Android people _don't_ _want_ _to_ _do_, because in that
case their battery life would go to the toilet.  The idea is to suspend even
when the system is not techincally "idle" and you don't like _that_.

> This of course will lead to a scattering of suspend blockers into any
> drivers/subsystems considered "useful", which by looking through current
> Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power
to reject requested changes.

As I said before, I don't think there's a way to resolve this so that everyone
is happy and in my opinion there are reasons to merge the feature.

Also I don't think we can make any progress discussing it.  We've already
discussed it for a month or so without any real progress and I don't see how
that's going to change now.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/21 Alan Stern <stern@rowland.harvard.edu>:
> On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:
>
>> The first goal can be achieved either by using device runtime PM and
>> cpuidle to put all hardware into low-power states, transparently from
>> the user space point of view, or by suspending the whole system.
>> However, system suspend, in its current form, does not guarantee that
>> the events of interest will always be responded to, since wakeup
>> events (events that wake the CPU from idle and the system from
>> suspend) that occur right after initiating suspend will not be
>> processed until another possibly unrelated event wakes the system up
>> again.
>
> Minor point of clarification here.  I'm not requesting that the patch
> description be rewritten.  But this issue of lost wakeup events is more
> subtle than it appears.
>
> Wakeup events can be lost in at least three different ways:
>
>     1. A hardware signal (such as an IRQ) gets ignored.
>
>     2. The hardware event occurs, but without effect since the
>        kernel thread that would handle the event has been frozen.
>        The event just ends up sitting in a queue somewhere until
>        something else wakes up the system.
>
>     3. The hardware event occurs and the kernel handles it fully,
>        but the event propagates to userspace for further handling
>        and the user program is already frozen.
>
> 1 is a hardware configuration failure (for example, it might happen as
> a result of using edge-triggered IRQs instead of level-triggered) and
> is outside the scope of this discussion.
>
> 2 generally represents a failure of the core PM subsystem, or a failure
> of some other part of the kernel to use the PM core correctly.  In
> theory we should be able to fix such mistakes.  Right now I'm aware of
> at least one possible failure scenario that could be fixed fairly
> easily.
>
> 3 is the type of failure that suspend blockers were really meant to
> handle, particularly the userspace suspend-blocker API.
>
> IMO, we should strive to fix the existing type-2 failure modes.
> However it is worth pointing out that they are basically separate from
> the suspend-blocker mechanism.
>
> And it might be a good idea to point out somewhere in the patch
> descriptions that suspend blockers are really meant to handle type-3
> wakeup losses.
>

I don't see a big difference between 2 and 3. You can use suspend
blockers to handle either.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/21 Alan Stern <stern@rowland.harvard.edu>:
> On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:
>
>> The first goal can be achieved either by using device runtime PM and
>> cpuidle to put all hardware into low-power states, transparently from
>> the user space point of view, or by suspending the whole system.
>> However, system suspend, in its current form, does not guarantee that
>> the events of interest will always be responded to, since wakeup
>> events (events that wake the CPU from idle and the system from
>> suspend) that occur right after initiating suspend will not be
>> processed until another possibly unrelated event wakes the system up
>> again.
>
> Minor point of clarification here.  I'm not requesting that the patch
> description be rewritten.  But this issue of lost wakeup events is more
> subtle than it appears.
>
> Wakeup events can be lost in at least three different ways:
>
>     1. A hardware signal (such as an IRQ) gets ignored.
>
>     2. The hardware event occurs, but without effect since the
>        kernel thread that would handle the event has been frozen.
>        The event just ends up sitting in a queue somewhere until
>        something else wakes up the system.
>
>     3. The hardware event occurs and the kernel handles it fully,
>        but the event propagates to userspace for further handling
>        and the user program is already frozen.
>
> 1 is a hardware configuration failure (for example, it might happen as
> a result of using edge-triggered IRQs instead of level-triggered) and
> is outside the scope of this discussion.
>
> 2 generally represents a failure of the core PM subsystem, or a failure
> of some other part of the kernel to use the PM core correctly.  In
> theory we should be able to fix such mistakes.  Right now I'm aware of
> at least one possible failure scenario that could be fixed fairly
> easily.
>
> 3 is the type of failure that suspend blockers were really meant to
> handle, particularly the userspace suspend-blocker API.
>
> IMO, we should strive to fix the existing type-2 failure modes.
> However it is worth pointing out that they are basically separate from
> the suspend-blocker mechanism.
>
> And it might be a good idea to point out somewhere in the patch
> descriptions that suspend blockers are really meant to handle type-3
> wakeup losses.
>

I don't see a big difference between 2 and 3. You can use suspend
blockers to handle either.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Mon, 24 May 2010, Arve Hjønnevåg wrote:

> > Wakeup events can be lost in at least three different ways:
> >
> >     1. A hardware signal (such as an IRQ) gets ignored.
> >
> >     2. The hardware event occurs, but without effect since the
> >        kernel thread that would handle the event has been frozen.
> >        The event just ends up sitting in a queue somewhere until
> >        something else wakes up the system.
> >
> >     3. The hardware event occurs and the kernel handles it fully,
> >        but the event propagates to userspace for further handling
> >        and the user program is already frozen.
> >
> > 1 is a hardware configuration failure (for example, it might happen as
> > a result of using edge-triggered IRQs instead of level-triggered) and
> > is outside the scope of this discussion.
> >
> > 2 generally represents a failure of the core PM subsystem, or a failure
> > of some other part of the kernel to use the PM core correctly.  In
> > theory we should be able to fix such mistakes.  Right now I'm aware of
> > at least one possible failure scenario that could be fixed fairly
> > easily.
> >
> > 3 is the type of failure that suspend blockers were really meant to
> > handle, particularly the userspace suspend-blocker API.

> I don't see a big difference between 2 and 3. You can use suspend
> blockers to handle either.

You can, but they aren't necessary.  If 2 were the only reason for 
suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing
mechanism.  3 is perhaps the most important reason for using suspend
blockers.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Mon, 24 May 2010, Arve Hjønnevåg wrote:

> > Wakeup events can be lost in at least three different ways:
> >
> >     1. A hardware signal (such as an IRQ) gets ignored.
> >
> >     2. The hardware event occurs, but without effect since the
> >        kernel thread that would handle the event has been frozen.
> >        The event just ends up sitting in a queue somewhere until
> >        something else wakes up the system.
> >
> >     3. The hardware event occurs and the kernel handles it fully,
> >        but the event propagates to userspace for further handling
> >        and the user program is already frozen.
> >
> > 1 is a hardware configuration failure (for example, it might happen as
> > a result of using edge-triggered IRQs instead of level-triggered) and
> > is outside the scope of this discussion.
> >
> > 2 generally represents a failure of the core PM subsystem, or a failure
> > of some other part of the kernel to use the PM core correctly.  In
> > theory we should be able to fix such mistakes.  Right now I'm aware of
> > at least one possible failure scenario that could be fixed fairly
> > easily.
> >
> > 3 is the type of failure that suspend blockers were really meant to
> > handle, particularly the userspace suspend-blocker API.

> I don't see a big difference between 2 and 3. You can use suspend
> blockers to handle either.

You can, but they aren't necessary.  If 2 were the only reason for 
suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing
mechanism.  3 is perhaps the most important reason for using suspend
blockers.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Mon, May 24, 2010 at 09:34:54PM -0400, Alan Stern wrote:
> On Mon, 24 May 2010, Arve Hjønnevåg wrote:
> 
> > > Wakeup events can be lost in at least three different ways:
> > >
> > >     1. A hardware signal (such as an IRQ) gets ignored.
> > >
> > >     2. The hardware event occurs, but without effect since the
> > >        kernel thread that would handle the event has been frozen.
> > >        The event just ends up sitting in a queue somewhere until
> > >        something else wakes up the system.
> > >
> > >     3. The hardware event occurs and the kernel handles it fully,
> > >        but the event propagates to userspace for further handling
> > >        and the user program is already frozen.
> > >
> > > 1 is a hardware configuration failure (for example, it might happen as
> > > a result of using edge-triggered IRQs instead of level-triggered) and
> > > is outside the scope of this discussion.
> > >
> > > 2 generally represents a failure of the core PM subsystem, or a failure
> > > of some other part of the kernel to use the PM core correctly.  In
> > > theory we should be able to fix such mistakes.  Right now I'm aware of
> > > at least one possible failure scenario that could be fixed fairly
> > > easily.
> > >
> > > 3 is the type of failure that suspend blockers were really meant to
> > > handle, particularly the userspace suspend-blocker API.
> 
> > I don't see a big difference between 2 and 3. You can use suspend
> > blockers to handle either.
> 
> You can, but they aren't necessary.  If 2 were the only reason for 
> suspend blockers, I would say they shouldn't be merged.
> 
> Whereas 3, on the other hand, can _not_ be handled by any existing
> mechanism.  3 is perhaps the most important reason for using suspend
> blockers.
> 

I do not see why 3 has to be implemented using suspend blockers either.
If you are concerned that event gets stuck somewhere in the stack make
sure that devices in the stack do not suspend while their queue is not
empty. This way if you try opportunistic suspend it will keep failing
until you drained all important queues.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Mon, May 24, 2010 at 09:34:54PM -0400, Alan Stern wrote:
> On Mon, 24 May 2010, Arve Hjønnevåg wrote:
> 
> > > Wakeup events can be lost in at least three different ways:
> > >
> > >     1. A hardware signal (such as an IRQ) gets ignored.
> > >
> > >     2. The hardware event occurs, but without effect since the
> > >        kernel thread that would handle the event has been frozen.
> > >        The event just ends up sitting in a queue somewhere until
> > >        something else wakes up the system.
> > >
> > >     3. The hardware event occurs and the kernel handles it fully,
> > >        but the event propagates to userspace for further handling
> > >        and the user program is already frozen.
> > >
> > > 1 is a hardware configuration failure (for example, it might happen as
> > > a result of using edge-triggered IRQs instead of level-triggered) and
> > > is outside the scope of this discussion.
> > >
> > > 2 generally represents a failure of the core PM subsystem, or a failure
> > > of some other part of the kernel to use the PM core correctly.  In
> > > theory we should be able to fix such mistakes.  Right now I'm aware of
> > > at least one possible failure scenario that could be fixed fairly
> > > easily.
> > >
> > > 3 is the type of failure that suspend blockers were really meant to
> > > handle, particularly the userspace suspend-blocker API.
> 
> > I don't see a big difference between 2 and 3. You can use suspend
> > blockers to handle either.
> 
> You can, but they aren't necessary.  If 2 were the only reason for 
> suspend blockers, I would say they shouldn't be merged.
> 
> Whereas 3, on the other hand, can _not_ be handled by any existing
> mechanism.  3 is perhaps the most important reason for using suspend
> blockers.
> 

I do not see why 3 has to be implemented using suspend blockers either.
If you are concerned that event gets stuck somewhere in the stack make
sure that devices in the stack do not suspend while their queue is not
empty. This way if you try opportunistic suspend it will keep failing
until you drained all important queues.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > I don't see a big difference between 2 and 3. You can use suspend
> > > blockers to handle either.
> > 
> > You can, but they aren't necessary.  If 2 were the only reason for 
> > suspend blockers, I would say they shouldn't be merged.
> > 
> > Whereas 3, on the other hand, can _not_ be handled by any existing
> > mechanism.  3 is perhaps the most important reason for using suspend
> > blockers.
> > 
> 
> I do not see why 3 has to be implemented using suspend blockers either.
> If you are concerned that event gets stuck somewhere in the stack make
> sure that devices in the stack do not suspend while their queue is not
> empty. This way if you try opportunistic suspend it will keep failing
> until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver
processes the keystroke and puts it in an input queue.  A user process
reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend.  
Since the input queue is empty, there's nothing to stop it.  As the
first step, userspace is frozen -- before the process has a chance to
do anything with the keystroke it just read.  As a result, the system
stays asleep until something else wakes it up, even though the
keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario.  Here's how:

The user process doesn't read the input queue directly; instead it 
does a select or poll.  When it sees there is data in the queue, it 
first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend
blocker is active.  The user process can do whatever it wants with the
keystroke.  When it is finished, it releases the suspend blocker and
loops back to the select/poll call.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > I don't see a big difference between 2 and 3. You can use suspend
> > > blockers to handle either.
> > 
> > You can, but they aren't necessary.  If 2 were the only reason for 
> > suspend blockers, I would say they shouldn't be merged.
> > 
> > Whereas 3, on the other hand, can _not_ be handled by any existing
> > mechanism.  3 is perhaps the most important reason for using suspend
> > blockers.
> > 
> 
> I do not see why 3 has to be implemented using suspend blockers either.
> If you are concerned that event gets stuck somewhere in the stack make
> sure that devices in the stack do not suspend while their queue is not
> empty. This way if you try opportunistic suspend it will keep failing
> until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver
processes the keystroke and puts it in an input queue.  A user process
reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend.  
Since the input queue is empty, there's nothing to stop it.  As the
first step, userspace is frozen -- before the process has a chance to
do anything with the keystroke it just read.  As a result, the system
stays asleep until something else wakes it up, even though the
keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario.  Here's how:

The user process doesn't read the input queue directly; instead it 
does a select or poll.  When it sees there is data in the queue, it 
first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend
blocker is active.  The user process can do whatever it wants with the
keystroke.  When it is finished, it releases the suspend blocker and
loops back to the select/poll call.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > blockers to handle either.
> > > 
> > > You can, but they aren't necessary.  If 2 were the only reason for
> > > suspend blockers, I would say they shouldn't be merged.
> > > 
> > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > mechanism.  3 is perhaps the most important reason for using suspend
> > > blockers.
> > 
> > I do not see why 3 has to be implemented using suspend blockers either.
> > If you are concerned that event gets stuck somewhere in the stack make
> > sure that devices in the stack do not suspend while their queue is not
> > empty. This way if you try opportunistic suspend it will keep failing
> > until you drained all important queues.
> 
> Here's the scenario:
> 
> The system is awake, and the user presses a key. The keyboard driver
> processes the keystroke and puts it in an input queue.  A user process
> reads it from the event queue, thereby emptying the queue.
> 
> At that moment, the system decides to go into opportunistic suspend.
> Since the input queue is empty, there's nothing to stop it.  As the
> first step, userspace is frozen -- before the process has a chance to
> do anything with the keystroke it just read.  As a result, the system
> stays asleep until something else wakes it up, even though the
> keystroke was important and should have prevented it from sleeping.
> 
> Suspend blockers protect against this scenario.  Here's how:
> 
> The user process doesn't read the input queue directly; instead it
> does a select or poll.  When it sees there is data in the queue, it
> first acquires a suspend blocker and then reads the data.
> 
> Now the system _can't_ go into opportunistic suspend, because a suspend
> blocker is active.  The user process can do whatever it wants with the
> keystroke.  When it is finished, it releases the suspend blocker and
> loops back to the select/poll call.
> 

What you describe can be done in userspace though, via a "suspend manager" 
process. Tasks reading input events will post "busy" events to stop the 
manager process from sending system into suspend. But this can be confined to 
Android userspace, leaving the kernel as is (well, kernel needs to be modified 
to not go into suspend with full queues, but that is using existing kernel 
APIs).

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > blockers to handle either.
> > > 
> > > You can, but they aren't necessary.  If 2 were the only reason for
> > > suspend blockers, I would say they shouldn't be merged.
> > > 
> > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > mechanism.  3 is perhaps the most important reason for using suspend
> > > blockers.
> > 
> > I do not see why 3 has to be implemented using suspend blockers either.
> > If you are concerned that event gets stuck somewhere in the stack make
> > sure that devices in the stack do not suspend while their queue is not
> > empty. This way if you try opportunistic suspend it will keep failing
> > until you drained all important queues.
> 
> Here's the scenario:
> 
> The system is awake, and the user presses a key. The keyboard driver
> processes the keystroke and puts it in an input queue.  A user process
> reads it from the event queue, thereby emptying the queue.
> 
> At that moment, the system decides to go into opportunistic suspend.
> Since the input queue is empty, there's nothing to stop it.  As the
> first step, userspace is frozen -- before the process has a chance to
> do anything with the keystroke it just read.  As a result, the system
> stays asleep until something else wakes it up, even though the
> keystroke was important and should have prevented it from sleeping.
> 
> Suspend blockers protect against this scenario.  Here's how:
> 
> The user process doesn't read the input queue directly; instead it
> does a select or poll.  When it sees there is data in the queue, it
> first acquires a suspend blocker and then reads the data.
> 
> Now the system _can't_ go into opportunistic suspend, because a suspend
> blocker is active.  The user process can do whatever it wants with the
> keystroke.  When it is finished, it releases the suspend blocker and
> loops back to the select/poll call.
> 

What you describe can be done in userspace though, via a "suspend manager" 
process. Tasks reading input events will post "busy" events to stop the 
manager process from sending system into suspend. But this can be confined to 
Android userspace, leaving the kernel as is (well, kernel needs to be modified 
to not go into suspend with full queues, but that is using existing kernel 
APIs).

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > Here's the scenario:
> > 
> > The system is awake, and the user presses a key. The keyboard driver
> > processes the keystroke and puts it in an input queue.  A user process
> > reads it from the event queue, thereby emptying the queue.
> > 
> > At that moment, the system decides to go into opportunistic suspend.
> > Since the input queue is empty, there's nothing to stop it.  As the
> > first step, userspace is frozen -- before the process has a chance to
> > do anything with the keystroke it just read.  As a result, the system
> > stays asleep until something else wakes it up, even though the
> > keystroke was important and should have prevented it from sleeping.
> > 
> > Suspend blockers protect against this scenario.  Here's how:
> > 
> > The user process doesn't read the input queue directly; instead it
> > does a select or poll.  When it sees there is data in the queue, it
> > first acquires a suspend blocker and then reads the data.
> > 
> > Now the system _can't_ go into opportunistic suspend, because a suspend
> > blocker is active.  The user process can do whatever it wants with the
> > keystroke.  When it is finished, it releases the suspend blocker and
> > loops back to the select/poll call.
> > 
> 
> What you describe can be done in userspace though, via a "suspend manager" 
> process. Tasks reading input events will post "busy" events to stop the 
> manager process from sending system into suspend. But this can be confined to 
> Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> to not go into suspend with full queues, but that is using existing kernel 
> APIs).

I think that could be made to work.  And it might remove the need for 
the userspace suspend-blocker API, which would be an advantage.  It 
could even remove the need for the opportunistic-suspend workqueue -- 
opportunistic suspends would be initiated by the "suspend manager" 
process instead of by the kernel.

However you still have the issue of modifying the kernel drivers to 
disallow opportunistic suspend if their queues are non-empty.  Doing 
that is more or less equivalent to implementing kernel-level suspend 
blockers.  (The suspend blocker approach is slightly more efficient, 
because it will prevent a suspend from starting if a queue is 
non-empty, instead of allowing the suspend to start and then aborting 
it partway through.)

Maybe I'm missing something here...  No doubt someone will point it out 
if I am.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > Here's the scenario:
> > 
> > The system is awake, and the user presses a key. The keyboard driver
> > processes the keystroke and puts it in an input queue.  A user process
> > reads it from the event queue, thereby emptying the queue.
> > 
> > At that moment, the system decides to go into opportunistic suspend.
> > Since the input queue is empty, there's nothing to stop it.  As the
> > first step, userspace is frozen -- before the process has a chance to
> > do anything with the keystroke it just read.  As a result, the system
> > stays asleep until something else wakes it up, even though the
> > keystroke was important and should have prevented it from sleeping.
> > 
> > Suspend blockers protect against this scenario.  Here's how:
> > 
> > The user process doesn't read the input queue directly; instead it
> > does a select or poll.  When it sees there is data in the queue, it
> > first acquires a suspend blocker and then reads the data.
> > 
> > Now the system _can't_ go into opportunistic suspend, because a suspend
> > blocker is active.  The user process can do whatever it wants with the
> > keystroke.  When it is finished, it releases the suspend blocker and
> > loops back to the select/poll call.
> > 
> 
> What you describe can be done in userspace though, via a "suspend manager" 
> process. Tasks reading input events will post "busy" events to stop the 
> manager process from sending system into suspend. But this can be confined to 
> Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> to not go into suspend with full queues, but that is using existing kernel 
> APIs).

I think that could be made to work.  And it might remove the need for 
the userspace suspend-blocker API, which would be an advantage.  It 
could even remove the need for the opportunistic-suspend workqueue -- 
opportunistic suspends would be initiated by the "suspend manager" 
process instead of by the kernel.

However you still have the issue of modifying the kernel drivers to 
disallow opportunistic suspend if their queues are non-empty.  Doing 
that is more or less equivalent to implementing kernel-level suspend 
blockers.  (The suspend blocker approach is slightly more efficient, 
because it will prevent a suspend from starting if a queue is 
non-empty, instead of allowing the suspend to start and then aborting 
it partway through.)

Maybe I'm missing something here...  No doubt someone will point it out 
if I am.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> 
> > > Here's the scenario:
> > > 
> > > The system is awake, and the user presses a key. The keyboard driver
> > > processes the keystroke and puts it in an input queue.  A user process
> > > reads it from the event queue, thereby emptying the queue.
> > > 
> > > At that moment, the system decides to go into opportunistic suspend.
> > > Since the input queue is empty, there's nothing to stop it.  As the
> > > first step, userspace is frozen -- before the process has a chance to
> > > do anything with the keystroke it just read.  As a result, the system
> > > stays asleep until something else wakes it up, even though the
> > > keystroke was important and should have prevented it from sleeping.
> > > 
> > > Suspend blockers protect against this scenario.  Here's how:
> > > 
> > > The user process doesn't read the input queue directly; instead it
> > > does a select or poll.  When it sees there is data in the queue, it
> > > first acquires a suspend blocker and then reads the data.
> > > 
> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > blocker is active.  The user process can do whatever it wants with the
> > > keystroke.  When it is finished, it releases the suspend blocker and
> > > loops back to the select/poll call.
> > > 
> > 
> > What you describe can be done in userspace though, via a "suspend manager" 
> > process. Tasks reading input events will post "busy" events to stop the 
> > manager process from sending system into suspend. But this can be confined to 
> > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > to not go into suspend with full queues, but that is using existing kernel 
> > APIs).
> 
> I think that could be made to work.  And it might remove the need for 
> the userspace suspend-blocker API, which would be an advantage.  It 
> could even remove the need for the opportunistic-suspend workqueue -- 
> opportunistic suspends would be initiated by the "suspend manager" 
> process instead of by the kernel.
> 
> However you still have the issue of modifying the kernel drivers to 
> disallow opportunistic suspend if their queues are non-empty.  Doing 
> that is more or less equivalent to implementing kernel-level suspend 
> blockers.  (The suspend blocker approach is slightly more efficient, 
> because it will prevent a suspend from starting if a queue is 
> non-empty, instead of allowing the suspend to start and then aborting 
> it partway through.)
>
> Maybe I'm missing something here...  No doubt someone will point it out 
> if I am.
> 

Well, from my perspective that would limit changes to the evdev driver
(well, limited input core plumbing will be needed) but that is using the
current PM infrastructure. The HW driver changes will be limited to what
you described "type 2" in your other e-mail.

Also, not suspending while events are in progress) is probably
beneficial for platforms other than Android as well. So unless I am
missing something this sounds like a win.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> 
> > > Here's the scenario:
> > > 
> > > The system is awake, and the user presses a key. The keyboard driver
> > > processes the keystroke and puts it in an input queue.  A user process
> > > reads it from the event queue, thereby emptying the queue.
> > > 
> > > At that moment, the system decides to go into opportunistic suspend.
> > > Since the input queue is empty, there's nothing to stop it.  As the
> > > first step, userspace is frozen -- before the process has a chance to
> > > do anything with the keystroke it just read.  As a result, the system
> > > stays asleep until something else wakes it up, even though the
> > > keystroke was important and should have prevented it from sleeping.
> > > 
> > > Suspend blockers protect against this scenario.  Here's how:
> > > 
> > > The user process doesn't read the input queue directly; instead it
> > > does a select or poll.  When it sees there is data in the queue, it
> > > first acquires a suspend blocker and then reads the data.
> > > 
> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > blocker is active.  The user process can do whatever it wants with the
> > > keystroke.  When it is finished, it releases the suspend blocker and
> > > loops back to the select/poll call.
> > > 
> > 
> > What you describe can be done in userspace though, via a "suspend manager" 
> > process. Tasks reading input events will post "busy" events to stop the 
> > manager process from sending system into suspend. But this can be confined to 
> > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > to not go into suspend with full queues, but that is using existing kernel 
> > APIs).
> 
> I think that could be made to work.  And it might remove the need for 
> the userspace suspend-blocker API, which would be an advantage.  It 
> could even remove the need for the opportunistic-suspend workqueue -- 
> opportunistic suspends would be initiated by the "suspend manager" 
> process instead of by the kernel.
> 
> However you still have the issue of modifying the kernel drivers to 
> disallow opportunistic suspend if their queues are non-empty.  Doing 
> that is more or less equivalent to implementing kernel-level suspend 
> blockers.  (The suspend blocker approach is slightly more efficient, 
> because it will prevent a suspend from starting if a queue is 
> non-empty, instead of allowing the suspend to start and then aborting 
> it partway through.)
>
> Maybe I'm missing something here...  No doubt someone will point it out 
> if I am.
> 

Well, from my perspective that would limit changes to the evdev driver
(well, limited input core plumbing will be needed) but that is using the
current PM infrastructure. The HW driver changes will be limited to what
you described "type 2" in your other e-mail.

Also, not suspending while events are in progress) is probably
beneficial for platforms other than Android as well. So unless I am
missing something this sounds like a win.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > What you describe can be done in userspace though, via a "suspend manager" 
> > > process. Tasks reading input events will post "busy" events to stop the 
> > > manager process from sending system into suspend. But this can be confined to 
> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > to not go into suspend with full queues, but that is using existing kernel 
> > > APIs).
> > 
> > I think that could be made to work.  And it might remove the need for 
> > the userspace suspend-blocker API, which would be an advantage.  It 
> > could even remove the need for the opportunistic-suspend workqueue -- 
> > opportunistic suspends would be initiated by the "suspend manager" 
> > process instead of by the kernel.
> > 
> > However you still have the issue of modifying the kernel drivers to 
> > disallow opportunistic suspend if their queues are non-empty.  Doing 
> > that is more or less equivalent to implementing kernel-level suspend 
> > blockers.  (The suspend blocker approach is slightly more efficient, 
> > because it will prevent a suspend from starting if a queue is 
> > non-empty, instead of allowing the suspend to start and then aborting 
> > it partway through.)
> >
> > Maybe I'm missing something here...  No doubt someone will point it out 
> > if I am.
> > 
> 
> Well, from my perspective that would limit changes to the evdev driver
> (well, limited input core plumbing will be needed) but that is using the
> current PM infrastructure. The HW driver changes will be limited to what
> you described "type 2" in your other e-mail.
> 
> Also, not suspending while events are in progress) is probably
> beneficial for platforms other than Android as well. So unless I am
> missing something this sounds like a win.

I agree that simplifying the user API would be an advantage.  Instead 
of the full-blown suspend-blocker interface, we would need only a way 
to initiate an opportunistic suspend.  For example:

	echo opportunistic >/sys/power/state

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > What you describe can be done in userspace though, via a "suspend manager" 
> > > process. Tasks reading input events will post "busy" events to stop the 
> > > manager process from sending system into suspend. But this can be confined to 
> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > to not go into suspend with full queues, but that is using existing kernel 
> > > APIs).
> > 
> > I think that could be made to work.  And it might remove the need for 
> > the userspace suspend-blocker API, which would be an advantage.  It 
> > could even remove the need for the opportunistic-suspend workqueue -- 
> > opportunistic suspends would be initiated by the "suspend manager" 
> > process instead of by the kernel.
> > 
> > However you still have the issue of modifying the kernel drivers to 
> > disallow opportunistic suspend if their queues are non-empty.  Doing 
> > that is more or less equivalent to implementing kernel-level suspend 
> > blockers.  (The suspend blocker approach is slightly more efficient, 
> > because it will prevent a suspend from starting if a queue is 
> > non-empty, instead of allowing the suspend to start and then aborting 
> > it partway through.)
> >
> > Maybe I'm missing something here...  No doubt someone will point it out 
> > if I am.
> > 
> 
> Well, from my perspective that would limit changes to the evdev driver
> (well, limited input core plumbing will be needed) but that is using the
> current PM infrastructure. The HW driver changes will be limited to what
> you described "type 2" in your other e-mail.
> 
> Also, not suspending while events are in progress) is probably
> beneficial for platforms other than Android as well. So unless I am
> missing something this sounds like a win.

I agree that simplifying the user API would be an advantage.  Instead 
of the full-blown suspend-blocker interface, we would need only a way 
to initiate an opportunistic suspend.  For example:

	echo opportunistic >/sys/power/state

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > blockers to handle either.
> > > > 
> > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > suspend blockers, I would say they shouldn't be merged.
> > > > 
> > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > blockers.
> > > 
> > > I do not see why 3 has to be implemented using suspend blockers either.
> > > If you are concerned that event gets stuck somewhere in the stack make
> > > sure that devices in the stack do not suspend while their queue is not
> > > empty. This way if you try opportunistic suspend it will keep failing
> > > until you drained all important queues.
> > 
> > Here's the scenario:
> > 
> > The system is awake, and the user presses a key. The keyboard driver
> > processes the keystroke and puts it in an input queue.  A user process
> > reads it from the event queue, thereby emptying the queue.
> > 
> > At that moment, the system decides to go into opportunistic suspend.
> > Since the input queue is empty, there's nothing to stop it.  As the
> > first step, userspace is frozen -- before the process has a chance to
> > do anything with the keystroke it just read.  As a result, the system
> > stays asleep until something else wakes it up, even though the
> > keystroke was important and should have prevented it from sleeping.
> > 
> > Suspend blockers protect against this scenario.  Here's how:
> > 
> > The user process doesn't read the input queue directly; instead it
> > does a select or poll.  When it sees there is data in the queue, it
> > first acquires a suspend blocker and then reads the data.
> > 
> > Now the system _can't_ go into opportunistic suspend, because a suspend
> > blocker is active.  The user process can do whatever it wants with the
> > keystroke.  When it is finished, it releases the suspend blocker and
> > loops back to the select/poll call.
> > 
> 
> What you describe can be done in userspace though, via a "suspend manager" 
> process. Tasks reading input events will post "busy" events to stop the 
> manager process from sending system into suspend. But this can be confined to 
> Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> to not go into suspend with full queues, but that is using existing kernel 
> APIs).

For that to work, you'd have to make the user space suspend manager prevent
key-reading processes from emptying the queue before it orders the kernel to
put the system to sleep.  Otherwise it still is possible that the queue will be
emptied right at the moment it writes to /sys/power/state and the scenario
described by Alan is going to happen.

Moreover, I don't think it's limited to the input subsystem, because the wakeup
events may originate from the network or some other sources and all of them
would require similar handling.

The problem here is that user space can't do anything to stop the freezing of
tasks without suspend blockers (or something more-or-less equivalent).

Now, you can argue that in theory we can avoid that if tasks are not frozen,
but quite frankly that's not a very realistic way to go.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > blockers to handle either.
> > > > 
> > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > suspend blockers, I would say they shouldn't be merged.
> > > > 
> > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > blockers.
> > > 
> > > I do not see why 3 has to be implemented using suspend blockers either.
> > > If you are concerned that event gets stuck somewhere in the stack make
> > > sure that devices in the stack do not suspend while their queue is not
> > > empty. This way if you try opportunistic suspend it will keep failing
> > > until you drained all important queues.
> > 
> > Here's the scenario:
> > 
> > The system is awake, and the user presses a key. The keyboard driver
> > processes the keystroke and puts it in an input queue.  A user process
> > reads it from the event queue, thereby emptying the queue.
> > 
> > At that moment, the system decides to go into opportunistic suspend.
> > Since the input queue is empty, there's nothing to stop it.  As the
> > first step, userspace is frozen -- before the process has a chance to
> > do anything with the keystroke it just read.  As a result, the system
> > stays asleep until something else wakes it up, even though the
> > keystroke was important and should have prevented it from sleeping.
> > 
> > Suspend blockers protect against this scenario.  Here's how:
> > 
> > The user process doesn't read the input queue directly; instead it
> > does a select or poll.  When it sees there is data in the queue, it
> > first acquires a suspend blocker and then reads the data.
> > 
> > Now the system _can't_ go into opportunistic suspend, because a suspend
> > blocker is active.  The user process can do whatever it wants with the
> > keystroke.  When it is finished, it releases the suspend blocker and
> > loops back to the select/poll call.
> > 
> 
> What you describe can be done in userspace though, via a "suspend manager" 
> process. Tasks reading input events will post "busy" events to stop the 
> manager process from sending system into suspend. But this can be confined to 
> Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> to not go into suspend with full queues, but that is using existing kernel 
> APIs).

For that to work, you'd have to make the user space suspend manager prevent
key-reading processes from emptying the queue before it orders the kernel to
put the system to sleep.  Otherwise it still is possible that the queue will be
emptied right at the moment it writes to /sys/power/state and the scenario
described by Alan is going to happen.

Moreover, I don't think it's limited to the input subsystem, because the wakeup
events may originate from the network or some other sources and all of them
would require similar handling.

The problem here is that user space can't do anything to stop the freezing of
tasks without suspend blockers (or something more-or-less equivalent).

Now, you can argue that in theory we can avoid that if tasks are not frozen,
but quite frankly that's not a very realistic way to go.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > blockers to handle either.
> > > > > 
> > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > 
> > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > blockers.
> > > > 
> > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > sure that devices in the stack do not suspend while their queue is not
> > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > until you drained all important queues.
> > > 
> > > Here's the scenario:
> > > 
> > > The system is awake, and the user presses a key. The keyboard driver
> > > processes the keystroke and puts it in an input queue.  A user process
> > > reads it from the event queue, thereby emptying the queue.
> > > 
> > > At that moment, the system decides to go into opportunistic suspend.
> > > Since the input queue is empty, there's nothing to stop it.  As the
> > > first step, userspace is frozen -- before the process has a chance to
> > > do anything with the keystroke it just read.  As a result, the system
> > > stays asleep until something else wakes it up, even though the
> > > keystroke was important and should have prevented it from sleeping.
> > > 
> > > Suspend blockers protect against this scenario.  Here's how:
> > > 
> > > The user process doesn't read the input queue directly; instead it
> > > does a select or poll.  When it sees there is data in the queue, it
> > > first acquires a suspend blocker and then reads the data.
> > > 
> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > blocker is active.  The user process can do whatever it wants with the
> > > keystroke.  When it is finished, it releases the suspend blocker and
> > > loops back to the select/poll call.
> > > 
> > 
> > What you describe can be done in userspace though, via a "suspend manager" 
> > process. Tasks reading input events will post "busy" events to stop the 
> > manager process from sending system into suspend. But this can be confined to 
> > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > to not go into suspend with full queues, but that is using existing kernel 
> > APIs).
> 
> For that to work, you'd have to make the user space suspend manager prevent
> key-reading processes from emptying the queue before it orders the kernel to
> put the system to sleep.  Otherwise it still is possible that the queue will be
> emptied right at the moment it writes to /sys/power/state and the scenario
> described by Alan is going to happen.
>

You do exactly the same as what Alan done, but in userspace - poll, post
"busy" event to suspend manager, read, process, retract "busy".
Basically you still have the suspend blocker, but it is confined to your
userspace.

> Moreover, I don't think it's limited to the input subsystem, because the wakeup
> events may originate from the network or some other sources and all of them
> would require similar handling.

Yes, all devices (real or virtual), not only input ones, holding the
queues have to refuse suspending for this to work.

> 
> The problem here is that user space can't do anything to stop the freezing of
> tasks without suspend blockers (or something more-or-less equivalent).

Sure it can if suspend is intiated by userspace itself.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > blockers to handle either.
> > > > > 
> > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > 
> > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > blockers.
> > > > 
> > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > sure that devices in the stack do not suspend while their queue is not
> > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > until you drained all important queues.
> > > 
> > > Here's the scenario:
> > > 
> > > The system is awake, and the user presses a key. The keyboard driver
> > > processes the keystroke and puts it in an input queue.  A user process
> > > reads it from the event queue, thereby emptying the queue.
> > > 
> > > At that moment, the system decides to go into opportunistic suspend.
> > > Since the input queue is empty, there's nothing to stop it.  As the
> > > first step, userspace is frozen -- before the process has a chance to
> > > do anything with the keystroke it just read.  As a result, the system
> > > stays asleep until something else wakes it up, even though the
> > > keystroke was important and should have prevented it from sleeping.
> > > 
> > > Suspend blockers protect against this scenario.  Here's how:
> > > 
> > > The user process doesn't read the input queue directly; instead it
> > > does a select or poll.  When it sees there is data in the queue, it
> > > first acquires a suspend blocker and then reads the data.
> > > 
> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > blocker is active.  The user process can do whatever it wants with the
> > > keystroke.  When it is finished, it releases the suspend blocker and
> > > loops back to the select/poll call.
> > > 
> > 
> > What you describe can be done in userspace though, via a "suspend manager" 
> > process. Tasks reading input events will post "busy" events to stop the 
> > manager process from sending system into suspend. But this can be confined to 
> > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > to not go into suspend with full queues, but that is using existing kernel 
> > APIs).
> 
> For that to work, you'd have to make the user space suspend manager prevent
> key-reading processes from emptying the queue before it orders the kernel to
> put the system to sleep.  Otherwise it still is possible that the queue will be
> emptied right at the moment it writes to /sys/power/state and the scenario
> described by Alan is going to happen.
>

You do exactly the same as what Alan done, but in userspace - poll, post
"busy" event to suspend manager, read, process, retract "busy".
Basically you still have the suspend blocker, but it is confined to your
userspace.

> Moreover, I don't think it's limited to the input subsystem, because the wakeup
> events may originate from the network or some other sources and all of them
> would require similar handling.

Yes, all devices (real or virtual), not only input ones, holding the
queues have to refuse suspending for this to work.

> 
> The problem here is that user space can't do anything to stop the freezing of
> tasks without suspend blockers (or something more-or-less equivalent).

Sure it can if suspend is intiated by userspace itself.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > > blockers to handle either.
> > > > > > 
> > > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > > 
> > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > > blockers.
> > > > > 
> > > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > > sure that devices in the stack do not suspend while their queue is not
> > > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > > until you drained all important queues.
> > > > 
> > > > Here's the scenario:
> > > > 
> > > > The system is awake, and the user presses a key. The keyboard driver
> > > > processes the keystroke and puts it in an input queue.  A user process
> > > > reads it from the event queue, thereby emptying the queue.
> > > > 
> > > > At that moment, the system decides to go into opportunistic suspend.
> > > > Since the input queue is empty, there's nothing to stop it.  As the
> > > > first step, userspace is frozen -- before the process has a chance to
> > > > do anything with the keystroke it just read.  As a result, the system
> > > > stays asleep until something else wakes it up, even though the
> > > > keystroke was important and should have prevented it from sleeping.
> > > > 
> > > > Suspend blockers protect against this scenario.  Here's how:
> > > > 
> > > > The user process doesn't read the input queue directly; instead it
> > > > does a select or poll.  When it sees there is data in the queue, it
> > > > first acquires a suspend blocker and then reads the data.
> > > > 
> > > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > > blocker is active.  The user process can do whatever it wants with the
> > > > keystroke.  When it is finished, it releases the suspend blocker and
> > > > loops back to the select/poll call.
> > > > 
> > > 
> > > What you describe can be done in userspace though, via a "suspend manager" 
> > > process. Tasks reading input events will post "busy" events to stop the 
> > > manager process from sending system into suspend. But this can be confined to 
> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > to not go into suspend with full queues, but that is using existing kernel 
> > > APIs).
> > 
> > For that to work, you'd have to make the user space suspend manager prevent
> > key-reading processes from emptying the queue before it orders the kernel to
> > put the system to sleep.  Otherwise it still is possible that the queue will be
> > emptied right at the moment it writes to /sys/power/state and the scenario
> > described by Alan is going to happen.
> >
> 
> You do exactly the same as what Alan done, but in userspace - poll, post
> "busy" event to suspend manager, read, process, retract "busy".
> Basically you still have the suspend blocker, but it is confined to your
> userspace.

OK, now the question is why this is actually better.

> > Moreover, I don't think it's limited to the input subsystem, because the wakeup
> > events may originate from the network or some other sources and all of them
> > would require similar handling.
> 
> Yes, all devices (real or virtual), not only input ones, holding the
> queues have to refuse suspending for this to work.

So, basically, you'd prefer to move the entire complexity to user space.
I'm not sure if that's a big win and I'm not sure anyone is actually going to
implement it (and some drivers would still have to be modified to participate
in this framework).  So again, we have a hunch that the goal may be achieved
in a different way, but at this point we'd rather need a _working_ _solution_
(in the form of code one can build and actually use).

I don't think it's realistic to expect the Android people to go and redesign
their stuff along the lines you've described, because they have a working
implementation (in the kernel) that they are satisfied with.

Now, we can reject their patches, but that's not going to cause any progress
to happen, realistically.  Quite on the contrary, Android will continue to use
wakelocks and Android driver writers will continue to ignore the mainline
and the gap between the two kernel lines will only get wider and wider over
time.

And what really is the drawback if we merge the patches?  Quite frankly,
I don't see any.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > > blockers to handle either.
> > > > > > 
> > > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > > 
> > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > > blockers.
> > > > > 
> > > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > > sure that devices in the stack do not suspend while their queue is not
> > > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > > until you drained all important queues.
> > > > 
> > > > Here's the scenario:
> > > > 
> > > > The system is awake, and the user presses a key. The keyboard driver
> > > > processes the keystroke and puts it in an input queue.  A user process
> > > > reads it from the event queue, thereby emptying the queue.
> > > > 
> > > > At that moment, the system decides to go into opportunistic suspend.
> > > > Since the input queue is empty, there's nothing to stop it.  As the
> > > > first step, userspace is frozen -- before the process has a chance to
> > > > do anything with the keystroke it just read.  As a result, the system
> > > > stays asleep until something else wakes it up, even though the
> > > > keystroke was important and should have prevented it from sleeping.
> > > > 
> > > > Suspend blockers protect against this scenario.  Here's how:
> > > > 
> > > > The user process doesn't read the input queue directly; instead it
> > > > does a select or poll.  When it sees there is data in the queue, it
> > > > first acquires a suspend blocker and then reads the data.
> > > > 
> > > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > > blocker is active.  The user process can do whatever it wants with the
> > > > keystroke.  When it is finished, it releases the suspend blocker and
> > > > loops back to the select/poll call.
> > > > 
> > > 
> > > What you describe can be done in userspace though, via a "suspend manager" 
> > > process. Tasks reading input events will post "busy" events to stop the 
> > > manager process from sending system into suspend. But this can be confined to 
> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > to not go into suspend with full queues, but that is using existing kernel 
> > > APIs).
> > 
> > For that to work, you'd have to make the user space suspend manager prevent
> > key-reading processes from emptying the queue before it orders the kernel to
> > put the system to sleep.  Otherwise it still is possible that the queue will be
> > emptied right at the moment it writes to /sys/power/state and the scenario
> > described by Alan is going to happen.
> >
> 
> You do exactly the same as what Alan done, but in userspace - poll, post
> "busy" event to suspend manager, read, process, retract "busy".
> Basically you still have the suspend blocker, but it is confined to your
> userspace.

OK, now the question is why this is actually better.

> > Moreover, I don't think it's limited to the input subsystem, because the wakeup
> > events may originate from the network or some other sources and all of them
> > would require similar handling.
> 
> Yes, all devices (real or virtual), not only input ones, holding the
> queues have to refuse suspending for this to work.

So, basically, you'd prefer to move the entire complexity to user space.
I'm not sure if that's a big win and I'm not sure anyone is actually going to
implement it (and some drivers would still have to be modified to participate
in this framework).  So again, we have a hunch that the goal may be achieved
in a different way, but at this point we'd rather need a _working_ _solution_
(in the form of code one can build and actually use).

I don't think it's realistic to expect the Android people to go and redesign
their stuff along the lines you've described, because they have a working
implementation (in the kernel) that they are satisfied with.

Now, we can reject their patches, but that's not going to cause any progress
to happen, realistically.  Quite on the contrary, Android will continue to use
wakelocks and Android driver writers will continue to ignore the mainline
and the gap between the two kernel lines will only get wider and wider over
time.

And what really is the drawback if we merge the patches?  Quite frankly,
I don't see any.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 10:21:55PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > > > blockers to handle either.
> > > > > > > 
> > > > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > > > 
> > > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > > > blockers.
> > > > > > 
> > > > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > > > sure that devices in the stack do not suspend while their queue is not
> > > > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > > > until you drained all important queues.
> > > > > 
> > > > > Here's the scenario:
> > > > > 
> > > > > The system is awake, and the user presses a key. The keyboard driver
> > > > > processes the keystroke and puts it in an input queue.  A user process
> > > > > reads it from the event queue, thereby emptying the queue.
> > > > > 
> > > > > At that moment, the system decides to go into opportunistic suspend.
> > > > > Since the input queue is empty, there's nothing to stop it.  As the
> > > > > first step, userspace is frozen -- before the process has a chance to
> > > > > do anything with the keystroke it just read.  As a result, the system
> > > > > stays asleep until something else wakes it up, even though the
> > > > > keystroke was important and should have prevented it from sleeping.
> > > > > 
> > > > > Suspend blockers protect against this scenario.  Here's how:
> > > > > 
> > > > > The user process doesn't read the input queue directly; instead it
> > > > > does a select or poll.  When it sees there is data in the queue, it
> > > > > first acquires a suspend blocker and then reads the data.
> > > > > 
> > > > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > > > blocker is active.  The user process can do whatever it wants with the
> > > > > keystroke.  When it is finished, it releases the suspend blocker and
> > > > > loops back to the select/poll call.
> > > > > 
> > > > 
> > > > What you describe can be done in userspace though, via a "suspend manager" 
> > > > process. Tasks reading input events will post "busy" events to stop the 
> > > > manager process from sending system into suspend. But this can be confined to 
> > > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > > to not go into suspend with full queues, but that is using existing kernel 
> > > > APIs).
> > > 
> > > For that to work, you'd have to make the user space suspend manager prevent
> > > key-reading processes from emptying the queue before it orders the kernel to
> > > put the system to sleep.  Otherwise it still is possible that the queue will be
> > > emptied right at the moment it writes to /sys/power/state and the scenario
> > > described by Alan is going to happen.
> > >
> > 
> > You do exactly the same as what Alan done, but in userspace - poll, post
> > "busy" event to suspend manager, read, process, retract "busy".
> > Basically you still have the suspend blocker, but it is confined to your
> > userspace.
> 
> OK, now the question is why this is actually better.
> 
> > > Moreover, I don't think it's limited to the input subsystem, because the wakeup
> > > events may originate from the network or some other sources and all of them
> > > would require similar handling.
> > 
> > Yes, all devices (real or virtual), not only input ones, holding the
> > queues have to refuse suspending for this to work.
> 
> So, basically, you'd prefer to move the entire complexity to user space.

Yes, I want to shift it from the kernel that use used by all platforms
into platform-sepcific userspace. Especially since I do not see everyone
buying into suspend-blocker model.

> I'm not sure if that's a big win and I'm not sure anyone is actually going to
> implement it (and some drivers would still have to be modified to participate
> in this framework).

I think it is much less than sprinkling every input driver out there
with suspend blockers.

  So again, we have a hunch that the goal may be achieved
> in a different way, but at this point we'd rather need a _working_ _solution_
> (in the form of code one can build and actually use).
> 
> I don't think it's realistic to expect the Android people to go and redesign
> their stuff along the lines you've described, because they have a working
> implementation (in the kernel) that they are satisfied with.
> 

Hmm, and this is different form ever other vendor solution how?

> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any.

Adding stuff that is not beneficial to anyone but a particular platform?
It is uncommon to say the least.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 10:21:55PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > > > blockers to handle either.
> > > > > > > 
> > > > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > > > 
> > > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > > > blockers.
> > > > > > 
> > > > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > > > sure that devices in the stack do not suspend while their queue is not
> > > > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > > > until you drained all important queues.
> > > > > 
> > > > > Here's the scenario:
> > > > > 
> > > > > The system is awake, and the user presses a key. The keyboard driver
> > > > > processes the keystroke and puts it in an input queue.  A user process
> > > > > reads it from the event queue, thereby emptying the queue.
> > > > > 
> > > > > At that moment, the system decides to go into opportunistic suspend.
> > > > > Since the input queue is empty, there's nothing to stop it.  As the
> > > > > first step, userspace is frozen -- before the process has a chance to
> > > > > do anything with the keystroke it just read.  As a result, the system
> > > > > stays asleep until something else wakes it up, even though the
> > > > > keystroke was important and should have prevented it from sleeping.
> > > > > 
> > > > > Suspend blockers protect against this scenario.  Here's how:
> > > > > 
> > > > > The user process doesn't read the input queue directly; instead it
> > > > > does a select or poll.  When it sees there is data in the queue, it
> > > > > first acquires a suspend blocker and then reads the data.
> > > > > 
> > > > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > > > blocker is active.  The user process can do whatever it wants with the
> > > > > keystroke.  When it is finished, it releases the suspend blocker and
> > > > > loops back to the select/poll call.
> > > > > 
> > > > 
> > > > What you describe can be done in userspace though, via a "suspend manager" 
> > > > process. Tasks reading input events will post "busy" events to stop the 
> > > > manager process from sending system into suspend. But this can be confined to 
> > > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > > > to not go into suspend with full queues, but that is using existing kernel 
> > > > APIs).
> > > 
> > > For that to work, you'd have to make the user space suspend manager prevent
> > > key-reading processes from emptying the queue before it orders the kernel to
> > > put the system to sleep.  Otherwise it still is possible that the queue will be
> > > emptied right at the moment it writes to /sys/power/state and the scenario
> > > described by Alan is going to happen.
> > >
> > 
> > You do exactly the same as what Alan done, but in userspace - poll, post
> > "busy" event to suspend manager, read, process, retract "busy".
> > Basically you still have the suspend blocker, but it is confined to your
> > userspace.
> 
> OK, now the question is why this is actually better.
> 
> > > Moreover, I don't think it's limited to the input subsystem, because the wakeup
> > > events may originate from the network or some other sources and all of them
> > > would require similar handling.
> > 
> > Yes, all devices (real or virtual), not only input ones, holding the
> > queues have to refuse suspending for this to work.
> 
> So, basically, you'd prefer to move the entire complexity to user space.

Yes, I want to shift it from the kernel that use used by all platforms
into platform-sepcific userspace. Especially since I do not see everyone
buying into suspend-blocker model.

> I'm not sure if that's a big win and I'm not sure anyone is actually going to
> implement it (and some drivers would still have to be modified to participate
> in this framework).

I think it is much less than sprinkling every input driver out there
with suspend blockers.

  So again, we have a hunch that the goal may be achieved
> in a different way, but at this point we'd rather need a _working_ _solution_
> (in the form of code one can build and actually use).
> 
> I don't think it's realistic to expect the Android people to go and redesign
> their stuff along the lines you've described, because they have a working
> implementation (in the kernel) that they are satisfied with.
> 

Hmm, and this is different form ever other vendor solution how?

> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any.

Adding stuff that is not beneficial to anyone but a particular platform?
It is uncommon to say the least.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Rafael J. Wysocki wrote:

> So, basically, you'd prefer to move the entire complexity to user space.

No, just the complexity of the userspace suspend blockers.  That was 
one of the parts of the interface that people objected to, after all.

> I'm not sure if that's a big win

It's not a _big_ win, but it is an improvement IMO.

>  and I'm not sure anyone is actually going to
> implement it (and some drivers would still have to be modified to participate
> in this framework).

Of course drivers have to be modified.  The kernel-layer suspend
blockers aren't affected by this proposal, so they still have to be
implemented.

>  So again, we have a hunch that the goal may be achieved
> in a different way, but at this point we'd rather need a _working_ _solution_
> (in the form of code one can build and actually use).

It's not very different from what has been submitted, and I think
there's little doubt that it could be built and used fairly easily.  
All we're talking about is removing the userspace suspend-blocker API
and the opportunistic workqueue, replacing them with an "opportunistic"
entry in /sys/power/state, and setting up a userspace power manager
process.

> I don't think it's realistic to expect the Android people to go and redesign
> their stuff along the lines you've described, because they have a working
> implementation (in the kernel) that they are satisfied with.

The redesign would be pretty small.  The kernel changes relative to
what they have submitted are minimal, mostly just removing a few of
their additions.  Furthermore, we've been told that Android _already_
funnels all its userspace suspend-blocker work through a single
process.  All that would be needed would be to make that process
initiate an opportunistic suspend whenever no userspace suspend
blockers were active.

> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any.

You don't seem to appreciate how small a change Dmitry has proposed.  
Almost all of the suspend-blocker work would remain as in the submitted
patches.  The only difference is that the userspace API and
opportunistic-suspend implementation would be simplified, by moving
some of the work out of the kernel.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Rafael J. Wysocki wrote:

> So, basically, you'd prefer to move the entire complexity to user space.

No, just the complexity of the userspace suspend blockers.  That was 
one of the parts of the interface that people objected to, after all.

> I'm not sure if that's a big win

It's not a _big_ win, but it is an improvement IMO.

>  and I'm not sure anyone is actually going to
> implement it (and some drivers would still have to be modified to participate
> in this framework).

Of course drivers have to be modified.  The kernel-layer suspend
blockers aren't affected by this proposal, so they still have to be
implemented.

>  So again, we have a hunch that the goal may be achieved
> in a different way, but at this point we'd rather need a _working_ _solution_
> (in the form of code one can build and actually use).

It's not very different from what has been submitted, and I think
there's little doubt that it could be built and used fairly easily.  
All we're talking about is removing the userspace suspend-blocker API
and the opportunistic workqueue, replacing them with an "opportunistic"
entry in /sys/power/state, and setting up a userspace power manager
process.

> I don't think it's realistic to expect the Android people to go and redesign
> their stuff along the lines you've described, because they have a working
> implementation (in the kernel) that they are satisfied with.

The redesign would be pretty small.  The kernel changes relative to
what they have submitted are minimal, mostly just removing a few of
their additions.  Furthermore, we've been told that Android _already_
funnels all its userspace suspend-blocker work through a single
process.  All that would be needed would be to make that process
initiate an opportunistic suspend whenever no userspace suspend
blockers were active.

> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any.

You don't seem to appreciate how small a change Dmitry has proposed.  
Almost all of the suspend-blocker work would remain as in the submitted
patches.  The only difference is that the userspace API and
opportunistic-suspend implementation would be simplified, by moving
some of the work out of the kernel.

Alan Stern

Re: [linux-pm] [PATCH 1/8] PM: Opportunistic suspend support.

[Vitaly Wool]

On Tue, May 25, 2010 at 10:44 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

>> Now, we can reject their patches, but that's not going to cause any progress
>> to happen, realistically.  Quite on the contrary, Android will continue to use
>> wakelocks and Android driver writers will continue to ignore the mainline
>> and the gap between the two kernel lines will only get wider and wider over
>> time.
>>
>> And what really is the drawback if we merge the patches?  Quite frankly,
>> I don't see any.
>
> Adding stuff that is not beneficial to anyone but a particular platform?
> It is uncommon to say the least.

Yeah, I'd even say we're about to adopt mechanism which will provoke
adding drivers with buggy solutions.

Moving that stuff to platform-specific userspace will solve that, more or less.

Also, I'm less than happy about Android vs mainline talks that come
into play when out of the technical points. Google is doing a good job
but we shouldn't compromise neither the quality nor the principles in
order to make them happy. They will not support tons of drivers with
custom PM solution by themselves, so it's to mutual benefit if they
come with a satisfactory solution.

~Vitaly

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Vitaly Wool]

On Tue, May 25, 2010 at 10:44 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

>> Now, we can reject their patches, but that's not going to cause any progress
>> to happen, realistically.  Quite on the contrary, Android will continue to use
>> wakelocks and Android driver writers will continue to ignore the mainline
>> and the gap between the two kernel lines will only get wider and wider over
>> time.
>>
>> And what really is the drawback if we merge the patches?  Quite frankly,
>> I don't see any.
>
> Adding stuff that is not beneficial to anyone but a particular platform?
> It is uncommon to say the least.

Yeah, I'd even say we're about to adopt mechanism which will provoke
adding drivers with buggy solutions.

Moving that stuff to platform-specific userspace will solve that, more or less.

Also, I'm less than happy about Android vs mainline talks that come
into play when out of the technical points. Google is doing a good job
but we shouldn't compromise neither the quality nor the principles in
order to make them happy. They will not support tons of drivers with
custom PM solution by themselves, so it's to mutual benefit if they
come with a satisfactory solution.

~Vitaly

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tue, May 25, 2010 at 10:21:55PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
...
> > Now, we can reject their patches, but that's not going to cause any progress
> > to happen, realistically.  Quite on the contrary, Android will continue to use
> > wakelocks and Android driver writers will continue to ignore the mainline
> > and the gap between the two kernel lines will only get wider and wider over
> > time.
> > 
> > And what really is the drawback if we merge the patches?  Quite frankly,
> > I don't see any.
> 
> Adding stuff that is not beneficial to anyone but a particular platform?
> It is uncommon to say the least.

Well, not quite.  We have a number of platform-specific drivers for one
example.

Also, In fact I think it would benefit everyone if Android users could run
mainline kernels without major modifications on their systems.

Also, I think it would benefit everyone if Android drivers were merged into
the mainline.

Moreover, I think this stuff may actually be useful to someone beyond Android,
because it's proven working and people can readily play with it.  Which is not
going to happen if it's not in the mainline.

And I don't believe a user space power manager is going to be implemented
in a platform-idependent way, if at all (assuming we reject the Android
patches).

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> On Tue, May 25, 2010 at 10:21:55PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
...
> > Now, we can reject their patches, but that's not going to cause any progress
> > to happen, realistically.  Quite on the contrary, Android will continue to use
> > wakelocks and Android driver writers will continue to ignore the mainline
> > and the gap between the two kernel lines will only get wider and wider over
> > time.
> > 
> > And what really is the drawback if we merge the patches?  Quite frankly,
> > I don't see any.
> 
> Adding stuff that is not beneficial to anyone but a particular platform?
> It is uncommon to say the least.

Well, not quite.  We have a number of platform-specific drivers for one
example.

Also, In fact I think it would benefit everyone if Android users could run
mainline kernels without major modifications on their systems.

Also, I think it would benefit everyone if Android drivers were merged into
the mainline.

Moreover, I think this stuff may actually be useful to someone beyond Android,
because it's proven working and people can readily play with it.  Which is not
going to happen if it's not in the mainline.

And I don't believe a user space power manager is going to be implemented
in a platform-idependent way, if at all (assuming we reject the Android
patches).

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Alan Stern wrote:
> On Tue, 25 May 2010, Rafael J. Wysocki wrote:
> 
> > So, basically, you'd prefer to move the entire complexity to user space.
> 
> No, just the complexity of the userspace suspend blockers.  That was 
> one of the parts of the interface that people objected to, after all.
> 
> > I'm not sure if that's a big win
> 
> It's not a _big_ win, but it is an improvement IMO.
> 
> >  and I'm not sure anyone is actually going to
> > implement it (and some drivers would still have to be modified to participate
> > in this framework).
> 
> Of course drivers have to be modified.  The kernel-layer suspend
> blockers aren't affected by this proposal, so they still have to be
> implemented.
> 
> >  So again, we have a hunch that the goal may be achieved
> > in a different way, but at this point we'd rather need a _working_ _solution_
> > (in the form of code one can build and actually use).
> 
> It's not very different from what has been submitted, and I think
> there's little doubt that it could be built and used fairly easily.  
> All we're talking about is removing the userspace suspend-blocker API
> and the opportunistic workqueue, replacing them with an "opportunistic"
> entry in /sys/power/state, and setting up a userspace power manager
> process.
> 
> > I don't think it's realistic to expect the Android people to go and redesign
> > their stuff along the lines you've described, because they have a working
> > implementation (in the kernel) that they are satisfied with.
> 
> The redesign would be pretty small.  The kernel changes relative to
> what they have submitted are minimal, mostly just removing a few of
> their additions.  Furthermore, we've been told that Android _already_
> funnels all its userspace suspend-blocker work through a single
> process.  All that would be needed would be to make that process
> initiate an opportunistic suspend whenever no userspace suspend
> blockers were active.
> 
> > Now, we can reject their patches, but that's not going to cause any progress
> > to happen, realistically.  Quite on the contrary, Android will continue to use
> > wakelocks and Android driver writers will continue to ignore the mainline
> > and the gap between the two kernel lines will only get wider and wider over
> > time.
> > 
> > And what really is the drawback if we merge the patches?  Quite frankly,
> > I don't see any.
> 
> You don't seem to appreciate how small a change Dmitry has proposed.  
> Almost all of the suspend-blocker work would remain as in the submitted
> patches.  The only difference is that the userspace API and
> opportunistic-suspend implementation would be simplified, by moving
> some of the work out of the kernel.

No, I don't really think it's going to be a small change.  The problem is that
for the Android people changing user space is very hard, so I don't think
this realy is an option, given that they would have to implement it themselves,
test it, validate it on multiple different hardware platforms etc. and _then_
resubmit the feature without any guarantee that it will be merged.

So, my opinion is that we only have a choice to either take the feature as is
now, or reject it altogether and live with the consequeces in each case.  And
quite frankly I don't feel like I'm in position to make that decision.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Alan Stern wrote:
> On Tue, 25 May 2010, Rafael J. Wysocki wrote:
> 
> > So, basically, you'd prefer to move the entire complexity to user space.
> 
> No, just the complexity of the userspace suspend blockers.  That was 
> one of the parts of the interface that people objected to, after all.
> 
> > I'm not sure if that's a big win
> 
> It's not a _big_ win, but it is an improvement IMO.
> 
> >  and I'm not sure anyone is actually going to
> > implement it (and some drivers would still have to be modified to participate
> > in this framework).
> 
> Of course drivers have to be modified.  The kernel-layer suspend
> blockers aren't affected by this proposal, so they still have to be
> implemented.
> 
> >  So again, we have a hunch that the goal may be achieved
> > in a different way, but at this point we'd rather need a _working_ _solution_
> > (in the form of code one can build and actually use).
> 
> It's not very different from what has been submitted, and I think
> there's little doubt that it could be built and used fairly easily.  
> All we're talking about is removing the userspace suspend-blocker API
> and the opportunistic workqueue, replacing them with an "opportunistic"
> entry in /sys/power/state, and setting up a userspace power manager
> process.
> 
> > I don't think it's realistic to expect the Android people to go and redesign
> > their stuff along the lines you've described, because they have a working
> > implementation (in the kernel) that they are satisfied with.
> 
> The redesign would be pretty small.  The kernel changes relative to
> what they have submitted are minimal, mostly just removing a few of
> their additions.  Furthermore, we've been told that Android _already_
> funnels all its userspace suspend-blocker work through a single
> process.  All that would be needed would be to make that process
> initiate an opportunistic suspend whenever no userspace suspend
> blockers were active.
> 
> > Now, we can reject their patches, but that's not going to cause any progress
> > to happen, realistically.  Quite on the contrary, Android will continue to use
> > wakelocks and Android driver writers will continue to ignore the mainline
> > and the gap between the two kernel lines will only get wider and wider over
> > time.
> > 
> > And what really is the drawback if we merge the patches?  Quite frankly,
> > I don't see any.
> 
> You don't seem to appreciate how small a change Dmitry has proposed.  
> Almost all of the suspend-blocker work would remain as in the submitted
> patches.  The only difference is that the userspace API and
> opportunistic-suspend implementation would be simplified, by moving
> some of the work out of the kernel.

No, I don't really think it's going to be a small change.  The problem is that
for the Android people changing user space is very hard, so I don't think
this realy is an option, given that they would have to implement it themselves,
test it, validate it on multiple different hardware platforms etc. and _then_
resubmit the feature without any guarantee that it will be merged.

So, my opinion is that we only have a choice to either take the feature as is
now, or reject it altogether and live with the consequeces in each case.  And
quite frankly I don't feel like I'm in position to make that decision.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>
>> > > Here's the scenario:
>> > >
>> > > The system is awake, and the user presses a key. The keyboard driver
>> > > processes the keystroke and puts it in an input queue.  A user process
>> > > reads it from the event queue, thereby emptying the queue.
>> > >
>> > > At that moment, the system decides to go into opportunistic suspend.
>> > > Since the input queue is empty, there's nothing to stop it.  As the
>> > > first step, userspace is frozen -- before the process has a chance to
>> > > do anything with the keystroke it just read.  As a result, the system
>> > > stays asleep until something else wakes it up, even though the
>> > > keystroke was important and should have prevented it from sleeping.
>> > >
>> > > Suspend blockers protect against this scenario.  Here's how:
>> > >
>> > > The user process doesn't read the input queue directly; instead it
>> > > does a select or poll.  When it sees there is data in the queue, it
>> > > first acquires a suspend blocker and then reads the data.
>> > >
>> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> > > blocker is active.  The user process can do whatever it wants with the
>> > > keystroke.  When it is finished, it releases the suspend blocker and
>> > > loops back to the select/poll call.
>> > >
>> >
>> > What you describe can be done in userspace though, via a "suspend manager"
>> > process. Tasks reading input events will post "busy" events to stop the
>> > manager process from sending system into suspend. But this can be confined to
>> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> > to not go into suspend with full queues, but that is using existing kernel
>> > APIs).
>>
>> I think that could be made to work.  And it might remove the need for
>> the userspace suspend-blocker API, which would be an advantage.  It
>> could even remove the need for the opportunistic-suspend workqueue --
>> opportunistic suspends would be initiated by the "suspend manager"
>> process instead of by the kernel.
>>
>> However you still have the issue of modifying the kernel drivers to
>> disallow opportunistic suspend if their queues are non-empty.  Doing
>> that is more or less equivalent to implementing kernel-level suspend
>> blockers.  (The suspend blocker approach is slightly more efficient,
>> because it will prevent a suspend from starting if a queue is
>> non-empty, instead of allowing the suspend to start and then aborting
>> it partway through.)
>>
>> Maybe I'm missing something here...  No doubt someone will point it out
>> if I am.
>>
>
> Well, from my perspective that would limit changes to the evdev driver
> (well, limited input core plumbing will be needed) but that is using the
> current PM infrastructure. The HW driver changes will be limited to what
> you described "type 2" in your other e-mail.
>
> Also, not suspending while events are in progress) is probably
> beneficial for platforms other than Android as well. So unless I am
> missing something this sounds like a win.
>

How would this limit the changes you need in the evdev driver? It need
to block suspend when there are unprocessed events in some queues.
Suspend blockers gives you an api to do this, without it, you check
the queues in your suspend hook and abort suspend if they are not
empty. Without suspend blockers you have no api to signal that it is
OK to suspend again, so you are forcing the thread that tried to
suspend to poll until you stop aborting suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>
>> > > Here's the scenario:
>> > >
>> > > The system is awake, and the user presses a key. The keyboard driver
>> > > processes the keystroke and puts it in an input queue.  A user process
>> > > reads it from the event queue, thereby emptying the queue.
>> > >
>> > > At that moment, the system decides to go into opportunistic suspend.
>> > > Since the input queue is empty, there's nothing to stop it.  As the
>> > > first step, userspace is frozen -- before the process has a chance to
>> > > do anything with the keystroke it just read.  As a result, the system
>> > > stays asleep until something else wakes it up, even though the
>> > > keystroke was important and should have prevented it from sleeping.
>> > >
>> > > Suspend blockers protect against this scenario.  Here's how:
>> > >
>> > > The user process doesn't read the input queue directly; instead it
>> > > does a select or poll.  When it sees there is data in the queue, it
>> > > first acquires a suspend blocker and then reads the data.
>> > >
>> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> > > blocker is active.  The user process can do whatever it wants with the
>> > > keystroke.  When it is finished, it releases the suspend blocker and
>> > > loops back to the select/poll call.
>> > >
>> >
>> > What you describe can be done in userspace though, via a "suspend manager"
>> > process. Tasks reading input events will post "busy" events to stop the
>> > manager process from sending system into suspend. But this can be confined to
>> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> > to not go into suspend with full queues, but that is using existing kernel
>> > APIs).
>>
>> I think that could be made to work.  And it might remove the need for
>> the userspace suspend-blocker API, which would be an advantage.  It
>> could even remove the need for the opportunistic-suspend workqueue --
>> opportunistic suspends would be initiated by the "suspend manager"
>> process instead of by the kernel.
>>
>> However you still have the issue of modifying the kernel drivers to
>> disallow opportunistic suspend if their queues are non-empty.  Doing
>> that is more or less equivalent to implementing kernel-level suspend
>> blockers.  (The suspend blocker approach is slightly more efficient,
>> because it will prevent a suspend from starting if a queue is
>> non-empty, instead of allowing the suspend to start and then aborting
>> it partway through.)
>>
>> Maybe I'm missing something here...  No doubt someone will point it out
>> if I am.
>>
>
> Well, from my perspective that would limit changes to the evdev driver
> (well, limited input core plumbing will be needed) but that is using the
> current PM infrastructure. The HW driver changes will be limited to what
> you described "type 2" in your other e-mail.
>
> Also, not suspending while events are in progress) is probably
> beneficial for platforms other than Android as well. So unless I am
> missing something this sounds like a win.
>

How would this limit the changes you need in the evdev driver? It need
to block suspend when there are unprocessed events in some queues.
Suspend blockers gives you an api to do this, without it, you check
the queues in your suspend hook and abort suspend if they are not
empty. Without suspend blockers you have no api to signal that it is
OK to suspend again, so you are forcing the thread that tried to
suspend to poll until you stop aborting suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >>
> >> > > Here's the scenario:
> >> > >
> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> > > reads it from the event queue, thereby emptying the queue.
> >> > >
> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> > > first step, userspace is frozen -- before the process has a chance to
> >> > > do anything with the keystroke it just read.  As a result, the system
> >> > > stays asleep until something else wakes it up, even though the
> >> > > keystroke was important and should have prevented it from sleeping.
> >> > >
> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> > >
> >> > > The user process doesn't read the input queue directly; instead it
> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> > > first acquires a suspend blocker and then reads the data.
> >> > >
> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> > > blocker is active.  The user process can do whatever it wants with the
> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> > > loops back to the select/poll call.
> >> > >
> >> >
> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> > process. Tasks reading input events will post "busy" events to stop the
> >> > manager process from sending system into suspend. But this can be confined to
> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> > to not go into suspend with full queues, but that is using existing kernel
> >> > APIs).
> >>
> >> I think that could be made to work.  And it might remove the need for
> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> could even remove the need for the opportunistic-suspend workqueue --
> >> opportunistic suspends would be initiated by the "suspend manager"
> >> process instead of by the kernel.
> >>
> >> However you still have the issue of modifying the kernel drivers to
> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> that is more or less equivalent to implementing kernel-level suspend
> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> because it will prevent a suspend from starting if a queue is
> >> non-empty, instead of allowing the suspend to start and then aborting
> >> it partway through.)
> >>
> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> if I am.
> >>
> >
> > Well, from my perspective that would limit changes to the evdev driver
> > (well, limited input core plumbing will be needed) but that is using the
> > current PM infrastructure. The HW driver changes will be limited to what
> > you described "type 2" in your other e-mail.
> >
> > Also, not suspending while events are in progress) is probably
> > beneficial for platforms other than Android as well. So unless I am
> > missing something this sounds like a win.
> >
> 
> How would this limit the changes you need in the evdev driver? It need
> to block suspend when there are unprocessed events in some queues.
> Suspend blockers gives you an api to do this, without it, you check
> the queues in your suspend hook and abort suspend if they are not
> empty. Without suspend blockers you have no api to signal that it is
> OK to suspend again, so you are forcing the thread that tried to
> suspend to poll until you stop aborting suspend.

No, you do not need to poll. You just set a timeout (short or long,
depending on your needs) and if no userspace task blocked suspend
durng that time you attempt to initiate suspend from your manager
process. If it succeeds - good, if not that means that more events came
your way and you have to do it later.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >>
> >> > > Here's the scenario:
> >> > >
> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> > > reads it from the event queue, thereby emptying the queue.
> >> > >
> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> > > first step, userspace is frozen -- before the process has a chance to
> >> > > do anything with the keystroke it just read.  As a result, the system
> >> > > stays asleep until something else wakes it up, even though the
> >> > > keystroke was important and should have prevented it from sleeping.
> >> > >
> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> > >
> >> > > The user process doesn't read the input queue directly; instead it
> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> > > first acquires a suspend blocker and then reads the data.
> >> > >
> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> > > blocker is active.  The user process can do whatever it wants with the
> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> > > loops back to the select/poll call.
> >> > >
> >> >
> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> > process. Tasks reading input events will post "busy" events to stop the
> >> > manager process from sending system into suspend. But this can be confined to
> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> > to not go into suspend with full queues, but that is using existing kernel
> >> > APIs).
> >>
> >> I think that could be made to work.  And it might remove the need for
> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> could even remove the need for the opportunistic-suspend workqueue --
> >> opportunistic suspends would be initiated by the "suspend manager"
> >> process instead of by the kernel.
> >>
> >> However you still have the issue of modifying the kernel drivers to
> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> that is more or less equivalent to implementing kernel-level suspend
> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> because it will prevent a suspend from starting if a queue is
> >> non-empty, instead of allowing the suspend to start and then aborting
> >> it partway through.)
> >>
> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> if I am.
> >>
> >
> > Well, from my perspective that would limit changes to the evdev driver
> > (well, limited input core plumbing will be needed) but that is using the
> > current PM infrastructure. The HW driver changes will be limited to what
> > you described "type 2" in your other e-mail.
> >
> > Also, not suspending while events are in progress) is probably
> > beneficial for platforms other than Android as well. So unless I am
> > missing something this sounds like a win.
> >
> 
> How would this limit the changes you need in the evdev driver? It need
> to block suspend when there are unprocessed events in some queues.
> Suspend blockers gives you an api to do this, without it, you check
> the queues in your suspend hook and abort suspend if they are not
> empty. Without suspend blockers you have no api to signal that it is
> OK to suspend again, so you are forcing the thread that tried to
> suspend to poll until you stop aborting suspend.

No, you do not need to poll. You just set a timeout (short or long,
depending on your needs) and if no userspace task blocked suspend
durng that time you attempt to initiate suspend from your manager
process. If it succeeds - good, if not that means that more events came
your way and you have to do it later.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday 25 May 2010, Alan Stern wrote:
>> On Tue, 25 May 2010, Rafael J. Wysocki wrote:
>>
>> > So, basically, you'd prefer to move the entire complexity to user space.
>>
>> No, just the complexity of the userspace suspend blockers.  That was
>> one of the parts of the interface that people objected to, after all.
>>
>> > I'm not sure if that's a big win
>>
>> It's not a _big_ win, but it is an improvement IMO.
>>
>> >  and I'm not sure anyone is actually going to
>> > implement it (and some drivers would still have to be modified to participate
>> > in this framework).
>>
>> Of course drivers have to be modified.  The kernel-layer suspend
>> blockers aren't affected by this proposal, so they still have to be
>> implemented.
>>
>> >  So again, we have a hunch that the goal may be achieved
>> > in a different way, but at this point we'd rather need a _working_ _solution_
>> > (in the form of code one can build and actually use).
>>
>> It's not very different from what has been submitted, and I think
>> there's little doubt that it could be built and used fairly easily.
>> All we're talking about is removing the userspace suspend-blocker API
>> and the opportunistic workqueue, replacing them with an "opportunistic"
>> entry in /sys/power/state, and setting up a userspace power manager
>> process.
>>
>> > I don't think it's realistic to expect the Android people to go and redesign
>> > their stuff along the lines you've described, because they have a working
>> > implementation (in the kernel) that they are satisfied with.
>>
>> The redesign would be pretty small.  The kernel changes relative to
>> what they have submitted are minimal, mostly just removing a few of
>> their additions.  Furthermore, we've been told that Android _already_
>> funnels all its userspace suspend-blocker work through a single
>> process.  All that would be needed would be to make that process
>> initiate an opportunistic suspend whenever no userspace suspend
>> blockers were active.
>>
>> > Now, we can reject their patches, but that's not going to cause any progress
>> > to happen, realistically.  Quite on the contrary, Android will continue to use
>> > wakelocks and Android driver writers will continue to ignore the mainline
>> > and the gap between the two kernel lines will only get wider and wider over
>> > time.
>> >
>> > And what really is the drawback if we merge the patches?  Quite frankly,
>> > I don't see any.
>>
>> You don't seem to appreciate how small a change Dmitry has proposed.
>> Almost all of the suspend-blocker work would remain as in the submitted
>> patches.  The only difference is that the userspace API and
>> opportunistic-suspend implementation would be simplified, by moving
>> some of the work out of the kernel.
>
> No, I don't really think it's going to be a small change.  The problem is that
> for the Android people changing user space is very hard, so I don't think
> this realy is an option, given that they would have to implement it themselves,
> test it, validate it on multiple different hardware platforms etc. and _then_
> resubmit the feature without any guarantee that it will be merged.
>

The biggest problem here is not that it is hard to change our
user-space, but that the proposed change is inferior to what we have
now. It forces us to poll until all drivers stop aborting suspend. On
one hand we have people telling us that all code that polls is broken
and must be fixed (instead of suspending to limit the damage), and on
the other hand we have people suggesting we implement opportunistic
suspend by polling from user-space until suspend succeeds.


> So, my opinion is that we only have a choice to either take the feature as is
> now, or reject it altogether and live with the consequeces in each case.  And
> quite frankly I don't feel like I'm in position to make that decision.
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Tue, May 25, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday 25 May 2010, Alan Stern wrote:
>> On Tue, 25 May 2010, Rafael J. Wysocki wrote:
>>
>> > So, basically, you'd prefer to move the entire complexity to user space.
>>
>> No, just the complexity of the userspace suspend blockers.  That was
>> one of the parts of the interface that people objected to, after all.
>>
>> > I'm not sure if that's a big win
>>
>> It's not a _big_ win, but it is an improvement IMO.
>>
>> >  and I'm not sure anyone is actually going to
>> > implement it (and some drivers would still have to be modified to participate
>> > in this framework).
>>
>> Of course drivers have to be modified.  The kernel-layer suspend
>> blockers aren't affected by this proposal, so they still have to be
>> implemented.
>>
>> >  So again, we have a hunch that the goal may be achieved
>> > in a different way, but at this point we'd rather need a _working_ _solution_
>> > (in the form of code one can build and actually use).
>>
>> It's not very different from what has been submitted, and I think
>> there's little doubt that it could be built and used fairly easily.
>> All we're talking about is removing the userspace suspend-blocker API
>> and the opportunistic workqueue, replacing them with an "opportunistic"
>> entry in /sys/power/state, and setting up a userspace power manager
>> process.
>>
>> > I don't think it's realistic to expect the Android people to go and redesign
>> > their stuff along the lines you've described, because they have a working
>> > implementation (in the kernel) that they are satisfied with.
>>
>> The redesign would be pretty small.  The kernel changes relative to
>> what they have submitted are minimal, mostly just removing a few of
>> their additions.  Furthermore, we've been told that Android _already_
>> funnels all its userspace suspend-blocker work through a single
>> process.  All that would be needed would be to make that process
>> initiate an opportunistic suspend whenever no userspace suspend
>> blockers were active.
>>
>> > Now, we can reject their patches, but that's not going to cause any progress
>> > to happen, realistically.  Quite on the contrary, Android will continue to use
>> > wakelocks and Android driver writers will continue to ignore the mainline
>> > and the gap between the two kernel lines will only get wider and wider over
>> > time.
>> >
>> > And what really is the drawback if we merge the patches?  Quite frankly,
>> > I don't see any.
>>
>> You don't seem to appreciate how small a change Dmitry has proposed.
>> Almost all of the suspend-blocker work would remain as in the submitted
>> patches.  The only difference is that the userspace API and
>> opportunistic-suspend implementation would be simplified, by moving
>> some of the work out of the kernel.
>
> No, I don't really think it's going to be a small change.  The problem is that
> for the Android people changing user space is very hard, so I don't think
> this realy is an option, given that they would have to implement it themselves,
> test it, validate it on multiple different hardware platforms etc. and _then_
> resubmit the feature without any guarantee that it will be merged.
>

The biggest problem here is not that it is hard to change our
user-space, but that the proposed change is inferior to what we have
now. It forces us to poll until all drivers stop aborting suspend. On
one hand we have people telling us that all code that polls is broken
and must be fixed (instead of suspending to limit the damage), and on
the other hand we have people suggesting we implement opportunistic
suspend by polling from user-space until suspend succeeds.


> So, my opinion is that we only have a choice to either take the feature as is
> now, or reject it altogether and live with the consequeces in each case.  And
> quite frankly I don't feel like I'm in position to make that decision.
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >>
>> >> > > Here's the scenario:
>> >> > >
>> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> > > reads it from the event queue, thereby emptying the queue.
>> >> > >
>> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> > > stays asleep until something else wakes it up, even though the
>> >> > > keystroke was important and should have prevented it from sleeping.
>> >> > >
>> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> > >
>> >> > > The user process doesn't read the input queue directly; instead it
>> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> > > first acquires a suspend blocker and then reads the data.
>> >> > >
>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> > > loops back to the select/poll call.
>> >> > >
>> >> >
>> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> > manager process from sending system into suspend. But this can be confined to
>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> > APIs).
>> >>
>> >> I think that could be made to work.  And it might remove the need for
>> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> process instead of by the kernel.
>> >>
>> >> However you still have the issue of modifying the kernel drivers to
>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> that is more or less equivalent to implementing kernel-level suspend
>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> because it will prevent a suspend from starting if a queue is
>> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> it partway through.)
>> >>
>> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> if I am.
>> >>
>> >
>> > Well, from my perspective that would limit changes to the evdev driver
>> > (well, limited input core plumbing will be needed) but that is using the
>> > current PM infrastructure. The HW driver changes will be limited to what
>> > you described "type 2" in your other e-mail.
>> >
>> > Also, not suspending while events are in progress) is probably
>> > beneficial for platforms other than Android as well. So unless I am
>> > missing something this sounds like a win.
>> >
>>
>> How would this limit the changes you need in the evdev driver? It need
>> to block suspend when there are unprocessed events in some queues.
>> Suspend blockers gives you an api to do this, without it, you check
>> the queues in your suspend hook and abort suspend if they are not
>> empty. Without suspend blockers you have no api to signal that it is
>> OK to suspend again, so you are forcing the thread that tried to
>> suspend to poll until you stop aborting suspend.
>
> No, you do not need to poll. You just set a timeout (short or long,
> depending on your needs) and if no userspace task blocked suspend
> durng that time you attempt to initiate suspend from your manager
> process. If it succeeds - good, if not that means that more events came
> your way and you have to do it later.
>

How is that not polling? If the user is holding down a key, the keypad
driver has to block suspend, and user space will try to suspend again
and again and again...

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >>
>> >> > > Here's the scenario:
>> >> > >
>> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> > > reads it from the event queue, thereby emptying the queue.
>> >> > >
>> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> > > stays asleep until something else wakes it up, even though the
>> >> > > keystroke was important and should have prevented it from sleeping.
>> >> > >
>> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> > >
>> >> > > The user process doesn't read the input queue directly; instead it
>> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> > > first acquires a suspend blocker and then reads the data.
>> >> > >
>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> > > loops back to the select/poll call.
>> >> > >
>> >> >
>> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> > manager process from sending system into suspend. But this can be confined to
>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> > APIs).
>> >>
>> >> I think that could be made to work.  And it might remove the need for
>> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> process instead of by the kernel.
>> >>
>> >> However you still have the issue of modifying the kernel drivers to
>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> that is more or less equivalent to implementing kernel-level suspend
>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> because it will prevent a suspend from starting if a queue is
>> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> it partway through.)
>> >>
>> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> if I am.
>> >>
>> >
>> > Well, from my perspective that would limit changes to the evdev driver
>> > (well, limited input core plumbing will be needed) but that is using the
>> > current PM infrastructure. The HW driver changes will be limited to what
>> > you described "type 2" in your other e-mail.
>> >
>> > Also, not suspending while events are in progress) is probably
>> > beneficial for platforms other than Android as well. So unless I am
>> > missing something this sounds like a win.
>> >
>>
>> How would this limit the changes you need in the evdev driver? It need
>> to block suspend when there are unprocessed events in some queues.
>> Suspend blockers gives you an api to do this, without it, you check
>> the queues in your suspend hook and abort suspend if they are not
>> empty. Without suspend blockers you have no api to signal that it is
>> OK to suspend again, so you are forcing the thread that tried to
>> suspend to poll until you stop aborting suspend.
>
> No, you do not need to poll. You just set a timeout (short or long,
> depending on your needs) and if no userspace task blocked suspend
> durng that time you attempt to initiate suspend from your manager
> process. If it succeeds - good, if not that means that more events came
> your way and you have to do it later.
>

How is that not polling? If the user is holding down a key, the keypad
driver has to block suspend, and user space will try to suspend again
and again and again...

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >> >>
> >> >> > > Here's the scenario:
> >> >> > >
> >> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> >> > > reads it from the event queue, thereby emptying the queue.
> >> >> > >
> >> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> >> > > first step, userspace is frozen -- before the process has a chance to
> >> >> > > do anything with the keystroke it just read.  As a result, the system
> >> >> > > stays asleep until something else wakes it up, even though the
> >> >> > > keystroke was important and should have prevented it from sleeping.
> >> >> > >
> >> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> >> > >
> >> >> > > The user process doesn't read the input queue directly; instead it
> >> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> >> > > first acquires a suspend blocker and then reads the data.
> >> >> > >
> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> >> > > blocker is active.  The user process can do whatever it wants with the
> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> >> > > loops back to the select/poll call.
> >> >> > >
> >> >> >
> >> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> >> > process. Tasks reading input events will post "busy" events to stop the
> >> >> > manager process from sending system into suspend. But this can be confined to
> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> >> > to not go into suspend with full queues, but that is using existing kernel
> >> >> > APIs).
> >> >>
> >> >> I think that could be made to work.  And it might remove the need for
> >> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> >> could even remove the need for the opportunistic-suspend workqueue --
> >> >> opportunistic suspends would be initiated by the "suspend manager"
> >> >> process instead of by the kernel.
> >> >>
> >> >> However you still have the issue of modifying the kernel drivers to
> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> >> that is more or less equivalent to implementing kernel-level suspend
> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> >> because it will prevent a suspend from starting if a queue is
> >> >> non-empty, instead of allowing the suspend to start and then aborting
> >> >> it partway through.)
> >> >>
> >> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> >> if I am.
> >> >>
> >> >
> >> > Well, from my perspective that would limit changes to the evdev driver
> >> > (well, limited input core plumbing will be needed) but that is using the
> >> > current PM infrastructure. The HW driver changes will be limited to what
> >> > you described "type 2" in your other e-mail.
> >> >
> >> > Also, not suspending while events are in progress) is probably
> >> > beneficial for platforms other than Android as well. So unless I am
> >> > missing something this sounds like a win.
> >> >
> >>
> >> How would this limit the changes you need in the evdev driver? It need
> >> to block suspend when there are unprocessed events in some queues.
> >> Suspend blockers gives you an api to do this, without it, you check
> >> the queues in your suspend hook and abort suspend if they are not
> >> empty. Without suspend blockers you have no api to signal that it is
> >> OK to suspend again, so you are forcing the thread that tried to
> >> suspend to poll until you stop aborting suspend.
> >
> > No, you do not need to poll. You just set a timeout (short or long,
> > depending on your needs) and if no userspace task blocked suspend
> > durng that time you attempt to initiate suspend from your manager
> > process. If it succeeds - good, if not that means that more events came
> > your way and you have to do it later.
> >
> 
> How is that not polling? If the user is holding down a key, the keypad
> driver has to block suspend, and user space will try to suspend again
> and again and again...
> 

If your userpsace is that stupid - sure. However, you can:

1. Notify the suspend manager process that he rest of your userspace is
busy handling keystrokes so that it does not try to suspend while there
are events pending.

2. Wait a tiny bit after last application notified you that it finished
processing events.

So basically the difference is that with in-kernel suspend blockers,
there is a tiny window where we haven't started the suspend yet but are
about to the driver has a chance to prevent entire system from starting
sleep.

Without the blocker we may start suspending and will stop midcycle. We
may be even better off in the end since we could leave some devices
still powered down after aborting system-wide suspend.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >> >>
> >> >> > > Here's the scenario:
> >> >> > >
> >> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> >> > > reads it from the event queue, thereby emptying the queue.
> >> >> > >
> >> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> >> > > first step, userspace is frozen -- before the process has a chance to
> >> >> > > do anything with the keystroke it just read.  As a result, the system
> >> >> > > stays asleep until something else wakes it up, even though the
> >> >> > > keystroke was important and should have prevented it from sleeping.
> >> >> > >
> >> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> >> > >
> >> >> > > The user process doesn't read the input queue directly; instead it
> >> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> >> > > first acquires a suspend blocker and then reads the data.
> >> >> > >
> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> >> > > blocker is active.  The user process can do whatever it wants with the
> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> >> > > loops back to the select/poll call.
> >> >> > >
> >> >> >
> >> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> >> > process. Tasks reading input events will post "busy" events to stop the
> >> >> > manager process from sending system into suspend. But this can be confined to
> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> >> > to not go into suspend with full queues, but that is using existing kernel
> >> >> > APIs).
> >> >>
> >> >> I think that could be made to work.  And it might remove the need for
> >> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> >> could even remove the need for the opportunistic-suspend workqueue --
> >> >> opportunistic suspends would be initiated by the "suspend manager"
> >> >> process instead of by the kernel.
> >> >>
> >> >> However you still have the issue of modifying the kernel drivers to
> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> >> that is more or less equivalent to implementing kernel-level suspend
> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> >> because it will prevent a suspend from starting if a queue is
> >> >> non-empty, instead of allowing the suspend to start and then aborting
> >> >> it partway through.)
> >> >>
> >> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> >> if I am.
> >> >>
> >> >
> >> > Well, from my perspective that would limit changes to the evdev driver
> >> > (well, limited input core plumbing will be needed) but that is using the
> >> > current PM infrastructure. The HW driver changes will be limited to what
> >> > you described "type 2" in your other e-mail.
> >> >
> >> > Also, not suspending while events are in progress) is probably
> >> > beneficial for platforms other than Android as well. So unless I am
> >> > missing something this sounds like a win.
> >> >
> >>
> >> How would this limit the changes you need in the evdev driver? It need
> >> to block suspend when there are unprocessed events in some queues.
> >> Suspend blockers gives you an api to do this, without it, you check
> >> the queues in your suspend hook and abort suspend if they are not
> >> empty. Without suspend blockers you have no api to signal that it is
> >> OK to suspend again, so you are forcing the thread that tried to
> >> suspend to poll until you stop aborting suspend.
> >
> > No, you do not need to poll. You just set a timeout (short or long,
> > depending on your needs) and if no userspace task blocked suspend
> > durng that time you attempt to initiate suspend from your manager
> > process. If it succeeds - good, if not that means that more events came
> > your way and you have to do it later.
> >
> 
> How is that not polling? If the user is holding down a key, the keypad
> driver has to block suspend, and user space will try to suspend again
> and again and again...
> 

If your userpsace is that stupid - sure. However, you can:

1. Notify the suspend manager process that he rest of your userspace is
busy handling keystrokes so that it does not try to suspend while there
are events pending.

2. Wait a tiny bit after last application notified you that it finished
processing events.

So basically the difference is that with in-kernel suspend blockers,
there is a tiny window where we haven't started the suspend yet but are
about to the driver has a chance to prevent entire system from starting
sleep.

Without the blocker we may start suspending and will stop midcycle. We
may be even better off in the end since we could leave some devices
still powered down after aborting system-wide suspend.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

Arve Hjønnevåg <arve@android.com> writes:

> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>>> <dmitry.torokhov@gmail.com> wrote:
>>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>> >>
>>> >> > > Here's the scenario:
>>> >> > >
>>> >> > > The system is awake, and the user presses a key. The keyboard driver
>>> >> > > processes the keystroke and puts it in an input queue.  A user process
>>> >> > > reads it from the event queue, thereby emptying the queue.
>>> >> > >
>>> >> > > At that moment, the system decides to go into opportunistic suspend.
>>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>>> >> > > first step, userspace is frozen -- before the process has a chance to
>>> >> > > do anything with the keystroke it just read.  As a result, the system
>>> >> > > stays asleep until something else wakes it up, even though the
>>> >> > > keystroke was important and should have prevented it from sleeping.
>>> >> > >
>>> >> > > Suspend blockers protect against this scenario.  Here's how:
>>> >> > >
>>> >> > > The user process doesn't read the input queue directly; instead it
>>> >> > > does a select or poll.  When it sees there is data in the queue, it
>>> >> > > first acquires a suspend blocker and then reads the data.
>>> >> > >
>>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>>> >> > > blocker is active.  The user process can do whatever it wants with the
>>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>>> >> > > loops back to the select/poll call.
>>> >> > >
>>> >> >
>>> >> > What you describe can be done in userspace though, via a "suspend manager"
>>> >> > process. Tasks reading input events will post "busy" events to stop the
>>> >> > manager process from sending system into suspend. But this can be confined to
>>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>>> >> > to not go into suspend with full queues, but that is using existing kernel
>>> >> > APIs).
>>> >>
>>> >> I think that could be made to work.  And it might remove the need for
>>> >> the userspace suspend-blocker API, which would be an advantage.  It
>>> >> could even remove the need for the opportunistic-suspend workqueue --
>>> >> opportunistic suspends would be initiated by the "suspend manager"
>>> >> process instead of by the kernel.
>>> >>
>>> >> However you still have the issue of modifying the kernel drivers to
>>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>>> >> that is more or less equivalent to implementing kernel-level suspend
>>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>>> >> because it will prevent a suspend from starting if a queue is
>>> >> non-empty, instead of allowing the suspend to start and then aborting
>>> >> it partway through.)
>>> >>
>>> >> Maybe I'm missing something here...  No doubt someone will point it out
>>> >> if I am.
>>> >>
>>> >
>>> > Well, from my perspective that would limit changes to the evdev driver
>>> > (well, limited input core plumbing will be needed) but that is using the
>>> > current PM infrastructure. The HW driver changes will be limited to what
>>> > you described "type 2" in your other e-mail.
>>> >
>>> > Also, not suspending while events are in progress) is probably
>>> > beneficial for platforms other than Android as well. So unless I am
>>> > missing something this sounds like a win.
>>> >
>>>
>>> How would this limit the changes you need in the evdev driver? It need
>>> to block suspend when there are unprocessed events in some queues.
>>> Suspend blockers gives you an api to do this, without it, you check
>>> the queues in your suspend hook and abort suspend if they are not
>>> empty. Without suspend blockers you have no api to signal that it is
>>> OK to suspend again, so you are forcing the thread that tried to
>>> suspend to poll until you stop aborting suspend.
>>
>> No, you do not need to poll. You just set a timeout (short or long,
>> depending on your needs) and if no userspace task blocked suspend
>> durng that time you attempt to initiate suspend from your manager
>> process. If it succeeds - good, if not that means that more events came
>> your way and you have to do it later.
>>
>
> How is that not polling? If the user is holding down a key, the keypad
> driver has to block suspend, and user space will try to suspend again
> and again and again...

Then the userspace suspend manager should be a little more clever
and should not blindly retry continuously.

It should be more like a governor which makes some simple decisions
based on previous events, simple heuristics, uses timeouts etc.,

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

Arve Hjønnevåg <arve@android.com> writes:

> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>>> <dmitry.torokhov@gmail.com> wrote:
>>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>> >>
>>> >> > > Here's the scenario:
>>> >> > >
>>> >> > > The system is awake, and the user presses a key. The keyboard driver
>>> >> > > processes the keystroke and puts it in an input queue.  A user process
>>> >> > > reads it from the event queue, thereby emptying the queue.
>>> >> > >
>>> >> > > At that moment, the system decides to go into opportunistic suspend.
>>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>>> >> > > first step, userspace is frozen -- before the process has a chance to
>>> >> > > do anything with the keystroke it just read.  As a result, the system
>>> >> > > stays asleep until something else wakes it up, even though the
>>> >> > > keystroke was important and should have prevented it from sleeping.
>>> >> > >
>>> >> > > Suspend blockers protect against this scenario.  Here's how:
>>> >> > >
>>> >> > > The user process doesn't read the input queue directly; instead it
>>> >> > > does a select or poll.  When it sees there is data in the queue, it
>>> >> > > first acquires a suspend blocker and then reads the data.
>>> >> > >
>>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>>> >> > > blocker is active.  The user process can do whatever it wants with the
>>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>>> >> > > loops back to the select/poll call.
>>> >> > >
>>> >> >
>>> >> > What you describe can be done in userspace though, via a "suspend manager"
>>> >> > process. Tasks reading input events will post "busy" events to stop the
>>> >> > manager process from sending system into suspend. But this can be confined to
>>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>>> >> > to not go into suspend with full queues, but that is using existing kernel
>>> >> > APIs).
>>> >>
>>> >> I think that could be made to work.  And it might remove the need for
>>> >> the userspace suspend-blocker API, which would be an advantage.  It
>>> >> could even remove the need for the opportunistic-suspend workqueue --
>>> >> opportunistic suspends would be initiated by the "suspend manager"
>>> >> process instead of by the kernel.
>>> >>
>>> >> However you still have the issue of modifying the kernel drivers to
>>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>>> >> that is more or less equivalent to implementing kernel-level suspend
>>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>>> >> because it will prevent a suspend from starting if a queue is
>>> >> non-empty, instead of allowing the suspend to start and then aborting
>>> >> it partway through.)
>>> >>
>>> >> Maybe I'm missing something here...  No doubt someone will point it out
>>> >> if I am.
>>> >>
>>> >
>>> > Well, from my perspective that would limit changes to the evdev driver
>>> > (well, limited input core plumbing will be needed) but that is using the
>>> > current PM infrastructure. The HW driver changes will be limited to what
>>> > you described "type 2" in your other e-mail.
>>> >
>>> > Also, not suspending while events are in progress) is probably
>>> > beneficial for platforms other than Android as well. So unless I am
>>> > missing something this sounds like a win.
>>> >
>>>
>>> How would this limit the changes you need in the evdev driver? It need
>>> to block suspend when there are unprocessed events in some queues.
>>> Suspend blockers gives you an api to do this, without it, you check
>>> the queues in your suspend hook and abort suspend if they are not
>>> empty. Without suspend blockers you have no api to signal that it is
>>> OK to suspend again, so you are forcing the thread that tried to
>>> suspend to poll until you stop aborting suspend.
>>
>> No, you do not need to poll. You just set a timeout (short or long,
>> depending on your needs) and if no userspace task blocked suspend
>> durng that time you attempt to initiate suspend from your manager
>> process. If it succeeds - good, if not that means that more events came
>> your way and you have to do it later.
>>
>
> How is that not polling? If the user is holding down a key, the keypad
> driver has to block suspend, and user space will try to suspend again
> and again and again...

Then the userspace suspend manager should be a little more clever
and should not blindly retry continuously.

It should be more like a governor which makes some simple decisions
based on previous events, simple heuristics, uses timeouts etc.,

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
>> On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
>> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
>> > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
>> > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> > > > > > > I don't see a big difference between 2 and 3. You can use suspend
>> > > > > > > blockers to handle either.
>> > > > > > 
>> > > > > > You can, but they aren't necessary.  If 2 were the only reason for
>> > > > > > suspend blockers, I would say they shouldn't be merged.
>> > > > > > 
>> > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
>> > > > > > mechanism.  3 is perhaps the most important reason for using suspend
>> > > > > > blockers.
>> > > > > 
>> > > > > I do not see why 3 has to be implemented using suspend blockers either.
>> > > > > If you are concerned that event gets stuck somewhere in the stack make
>> > > > > sure that devices in the stack do not suspend while their queue is not
>> > > > > empty. This way if you try opportunistic suspend it will keep failing
>> > > > > until you drained all important queues.
>> > > > 
>> > > > Here's the scenario:
>> > > > 
>> > > > The system is awake, and the user presses a key. The keyboard driver
>> > > > processes the keystroke and puts it in an input queue.  A user process
>> > > > reads it from the event queue, thereby emptying the queue.
>> > > > 
>> > > > At that moment, the system decides to go into opportunistic suspend.
>> > > > Since the input queue is empty, there's nothing to stop it.  As the
>> > > > first step, userspace is frozen -- before the process has a chance to
>> > > > do anything with the keystroke it just read.  As a result, the system
>> > > > stays asleep until something else wakes it up, even though the
>> > > > keystroke was important and should have prevented it from sleeping.
>> > > > 
>> > > > Suspend blockers protect against this scenario.  Here's how:
>> > > > 
>> > > > The user process doesn't read the input queue directly; instead it
>> > > > does a select or poll.  When it sees there is data in the queue, it
>> > > > first acquires a suspend blocker and then reads the data.
>> > > > 
>> > > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> > > > blocker is active.  The user process can do whatever it wants with the
>> > > > keystroke.  When it is finished, it releases the suspend blocker and
>> > > > loops back to the select/poll call.
>> > > > 
>> > > 
>> > > What you describe can be done in userspace though, via a "suspend manager" 
>> > > process. Tasks reading input events will post "busy" events to stop the 
>> > > manager process from sending system into suspend. But this can be confined to 
>> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
>> > > to not go into suspend with full queues, but that is using existing kernel 
>> > > APIs).
>> > 
>> > For that to work, you'd have to make the user space suspend manager prevent
>> > key-reading processes from emptying the queue before it orders the kernel to
>> > put the system to sleep.  Otherwise it still is possible that the queue will be
>> > emptied right at the moment it writes to /sys/power/state and the scenario
>> > described by Alan is going to happen.
>> >
>> 
>> You do exactly the same as what Alan done, but in userspace - poll, post
>> "busy" event to suspend manager, read, process, retract "busy".
>> Basically you still have the suspend blocker, but it is confined to your
>> userspace.
>
> OK, now the question is why this is actually better.

A couple things come to mind...

1. Fixes problems for *all* kernel users, not just Android.

The kernel changes (refuse to suspend) would be done in a way that
would fix problems in the traditional suspend path as well as the
opportunistic suspend path, thus benefiting everyone.

2. Keep policy out of the kernel

A userspace suspend manager could implement _policy_ decisions in a
platform specific way, rather than having policy hard-coded into the
kernel.

Keeping the policy/governor in userspace would also allow various
governor techniques to be experimented with (polling/timeout
intervals, etc.) without having to patch the kernel.

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
>> On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
>> > On Tuesday 25 May 2010, Dmitry Torokhov wrote:
>> > > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
>> > > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> > > > > > > I don't see a big difference between 2 and 3. You can use suspend
>> > > > > > > blockers to handle either.
>> > > > > > 
>> > > > > > You can, but they aren't necessary.  If 2 were the only reason for
>> > > > > > suspend blockers, I would say they shouldn't be merged.
>> > > > > > 
>> > > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
>> > > > > > mechanism.  3 is perhaps the most important reason for using suspend
>> > > > > > blockers.
>> > > > > 
>> > > > > I do not see why 3 has to be implemented using suspend blockers either.
>> > > > > If you are concerned that event gets stuck somewhere in the stack make
>> > > > > sure that devices in the stack do not suspend while their queue is not
>> > > > > empty. This way if you try opportunistic suspend it will keep failing
>> > > > > until you drained all important queues.
>> > > > 
>> > > > Here's the scenario:
>> > > > 
>> > > > The system is awake, and the user presses a key. The keyboard driver
>> > > > processes the keystroke and puts it in an input queue.  A user process
>> > > > reads it from the event queue, thereby emptying the queue.
>> > > > 
>> > > > At that moment, the system decides to go into opportunistic suspend.
>> > > > Since the input queue is empty, there's nothing to stop it.  As the
>> > > > first step, userspace is frozen -- before the process has a chance to
>> > > > do anything with the keystroke it just read.  As a result, the system
>> > > > stays asleep until something else wakes it up, even though the
>> > > > keystroke was important and should have prevented it from sleeping.
>> > > > 
>> > > > Suspend blockers protect against this scenario.  Here's how:
>> > > > 
>> > > > The user process doesn't read the input queue directly; instead it
>> > > > does a select or poll.  When it sees there is data in the queue, it
>> > > > first acquires a suspend blocker and then reads the data.
>> > > > 
>> > > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> > > > blocker is active.  The user process can do whatever it wants with the
>> > > > keystroke.  When it is finished, it releases the suspend blocker and
>> > > > loops back to the select/poll call.
>> > > > 
>> > > 
>> > > What you describe can be done in userspace though, via a "suspend manager" 
>> > > process. Tasks reading input events will post "busy" events to stop the 
>> > > manager process from sending system into suspend. But this can be confined to 
>> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
>> > > to not go into suspend with full queues, but that is using existing kernel 
>> > > APIs).
>> > 
>> > For that to work, you'd have to make the user space suspend manager prevent
>> > key-reading processes from emptying the queue before it orders the kernel to
>> > put the system to sleep.  Otherwise it still is possible that the queue will be
>> > emptied right at the moment it writes to /sys/power/state and the scenario
>> > described by Alan is going to happen.
>> >
>> 
>> You do exactly the same as what Alan done, but in userspace - poll, post
>> "busy" event to suspend manager, read, process, retract "busy".
>> Basically you still have the suspend blocker, but it is confined to your
>> userspace.
>
> OK, now the question is why this is actually better.

A couple things come to mind...

1. Fixes problems for *all* kernel users, not just Android.

The kernel changes (refuse to suspend) would be done in a way that
would fix problems in the traditional suspend path as well as the
opportunistic suspend path, thus benefiting everyone.

2. Keep policy out of the kernel

A userspace suspend manager could implement _policy_ decisions in a
platform specific way, rather than having policy hard-coded into the
kernel.

Keeping the policy/governor in userspace would also allow various
governor techniques to be experimented with (polling/timeout
intervals, etc.) without having to patch the kernel.

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >> >>
>> >> >> > > Here's the scenario:
>> >> >> > >
>> >> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> >> > > reads it from the event queue, thereby emptying the queue.
>> >> >> > >
>> >> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> >> > > stays asleep until something else wakes it up, even though the
>> >> >> > > keystroke was important and should have prevented it from sleeping.
>> >> >> > >
>> >> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> >> > >
>> >> >> > > The user process doesn't read the input queue directly; instead it
>> >> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> >> > > first acquires a suspend blocker and then reads the data.
>> >> >> > >
>> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> >> > > loops back to the select/poll call.
>> >> >> > >
>> >> >> >
>> >> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> >> > manager process from sending system into suspend. But this can be confined to
>> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> >> > APIs).
>> >> >>
>> >> >> I think that could be made to work.  And it might remove the need for
>> >> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> >> process instead of by the kernel.
>> >> >>
>> >> >> However you still have the issue of modifying the kernel drivers to
>> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> >> that is more or less equivalent to implementing kernel-level suspend
>> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> >> because it will prevent a suspend from starting if a queue is
>> >> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> >> it partway through.)
>> >> >>
>> >> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> >> if I am.
>> >> >>
>> >> >
>> >> > Well, from my perspective that would limit changes to the evdev driver
>> >> > (well, limited input core plumbing will be needed) but that is using the
>> >> > current PM infrastructure. The HW driver changes will be limited to what
>> >> > you described "type 2" in your other e-mail.
>> >> >
>> >> > Also, not suspending while events are in progress) is probably
>> >> > beneficial for platforms other than Android as well. So unless I am
>> >> > missing something this sounds like a win.
>> >> >
>> >>
>> >> How would this limit the changes you need in the evdev driver? It need
>> >> to block suspend when there are unprocessed events in some queues.
>> >> Suspend blockers gives you an api to do this, without it, you check
>> >> the queues in your suspend hook and abort suspend if they are not
>> >> empty. Without suspend blockers you have no api to signal that it is
>> >> OK to suspend again, so you are forcing the thread that tried to
>> >> suspend to poll until you stop aborting suspend.
>> >
>> > No, you do not need to poll. You just set a timeout (short or long,
>> > depending on your needs) and if no userspace task blocked suspend
>> > durng that time you attempt to initiate suspend from your manager
>> > process. If it succeeds - good, if not that means that more events came
>> > your way and you have to do it later.
>> >
>>
>> How is that not polling? If the user is holding down a key, the keypad
>> driver has to block suspend, and user space will try to suspend again
>> and again and again...
>>
>
> If your userpsace is that stupid - sure. However, you can:
>
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.

You are missing the point. There are no event pending. The kernel
reported the key down event, it was handled, but the keypad driver is
still scanning to see if the user presses another key, or releases the
currently held key.

>
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.
>
> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.

No, the difference is that if a driver needs to prevent suspend for an
extended period of time, you don't have user space continuously
polling to see if it can suspend.

>
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.
>

That does not sound right.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >> >>
>> >> >> > > Here's the scenario:
>> >> >> > >
>> >> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> >> > > reads it from the event queue, thereby emptying the queue.
>> >> >> > >
>> >> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> >> > > stays asleep until something else wakes it up, even though the
>> >> >> > > keystroke was important and should have prevented it from sleeping.
>> >> >> > >
>> >> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> >> > >
>> >> >> > > The user process doesn't read the input queue directly; instead it
>> >> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> >> > > first acquires a suspend blocker and then reads the data.
>> >> >> > >
>> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> >> > > loops back to the select/poll call.
>> >> >> > >
>> >> >> >
>> >> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> >> > manager process from sending system into suspend. But this can be confined to
>> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> >> > APIs).
>> >> >>
>> >> >> I think that could be made to work.  And it might remove the need for
>> >> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> >> process instead of by the kernel.
>> >> >>
>> >> >> However you still have the issue of modifying the kernel drivers to
>> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> >> that is more or less equivalent to implementing kernel-level suspend
>> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> >> because it will prevent a suspend from starting if a queue is
>> >> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> >> it partway through.)
>> >> >>
>> >> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> >> if I am.
>> >> >>
>> >> >
>> >> > Well, from my perspective that would limit changes to the evdev driver
>> >> > (well, limited input core plumbing will be needed) but that is using the
>> >> > current PM infrastructure. The HW driver changes will be limited to what
>> >> > you described "type 2" in your other e-mail.
>> >> >
>> >> > Also, not suspending while events are in progress) is probably
>> >> > beneficial for platforms other than Android as well. So unless I am
>> >> > missing something this sounds like a win.
>> >> >
>> >>
>> >> How would this limit the changes you need in the evdev driver? It need
>> >> to block suspend when there are unprocessed events in some queues.
>> >> Suspend blockers gives you an api to do this, without it, you check
>> >> the queues in your suspend hook and abort suspend if they are not
>> >> empty. Without suspend blockers you have no api to signal that it is
>> >> OK to suspend again, so you are forcing the thread that tried to
>> >> suspend to poll until you stop aborting suspend.
>> >
>> > No, you do not need to poll. You just set a timeout (short or long,
>> > depending on your needs) and if no userspace task blocked suspend
>> > durng that time you attempt to initiate suspend from your manager
>> > process. If it succeeds - good, if not that means that more events came
>> > your way and you have to do it later.
>> >
>>
>> How is that not polling? If the user is holding down a key, the keypad
>> driver has to block suspend, and user space will try to suspend again
>> and again and again...
>>
>
> If your userpsace is that stupid - sure. However, you can:
>
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.

You are missing the point. There are no event pending. The kernel
reported the key down event, it was handled, but the keypad driver is
still scanning to see if the user presses another key, or releases the
currently held key.

>
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.
>
> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.

No, the difference is that if a driver needs to prevent suspend for an
extended period of time, you don't have user space continuously
polling to see if it can suspend.

>
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.
>

That does not sound right.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
> >> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> >> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> >> >> <dmitry.torokhov@gmail.com> wrote:
> >> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >> >> >>
> >> >> >> > > Here's the scenario:
> >> >> >> > >
> >> >> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> >> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> >> >> > > reads it from the event queue, thereby emptying the queue.
> >> >> >> > >
> >> >> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> >> >> > > first step, userspace is frozen -- before the process has a chance to
> >> >> >> > > do anything with the keystroke it just read.  As a result, the system
> >> >> >> > > stays asleep until something else wakes it up, even though the
> >> >> >> > > keystroke was important and should have prevented it from sleeping.
> >> >> >> > >
> >> >> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> >> >> > >
> >> >> >> > > The user process doesn't read the input queue directly; instead it
> >> >> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> >> >> > > first acquires a suspend blocker and then reads the data.
> >> >> >> > >
> >> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> >> >> > > blocker is active.  The user process can do whatever it wants with the
> >> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> >> >> > > loops back to the select/poll call.
> >> >> >> > >
> >> >> >> >
> >> >> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> >> >> > process. Tasks reading input events will post "busy" events to stop the
> >> >> >> > manager process from sending system into suspend. But this can be confined to
> >> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> >> >> > to not go into suspend with full queues, but that is using existing kernel
> >> >> >> > APIs).
> >> >> >>
> >> >> >> I think that could be made to work.  And it might remove the need for
> >> >> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> >> >> could even remove the need for the opportunistic-suspend workqueue --
> >> >> >> opportunistic suspends would be initiated by the "suspend manager"
> >> >> >> process instead of by the kernel.
> >> >> >>
> >> >> >> However you still have the issue of modifying the kernel drivers to
> >> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> >> >> that is more or less equivalent to implementing kernel-level suspend
> >> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> >> >> because it will prevent a suspend from starting if a queue is
> >> >> >> non-empty, instead of allowing the suspend to start and then aborting
> >> >> >> it partway through.)
> >> >> >>
> >> >> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> >> >> if I am.
> >> >> >>
> >> >> >
> >> >> > Well, from my perspective that would limit changes to the evdev driver
> >> >> > (well, limited input core plumbing will be needed) but that is using the
> >> >> > current PM infrastructure. The HW driver changes will be limited to what
> >> >> > you described "type 2" in your other e-mail.
> >> >> >
> >> >> > Also, not suspending while events are in progress) is probably
> >> >> > beneficial for platforms other than Android as well. So unless I am
> >> >> > missing something this sounds like a win.
> >> >> >
> >> >>
> >> >> How would this limit the changes you need in the evdev driver? It need
> >> >> to block suspend when there are unprocessed events in some queues.
> >> >> Suspend blockers gives you an api to do this, without it, you check
> >> >> the queues in your suspend hook and abort suspend if they are not
> >> >> empty. Without suspend blockers you have no api to signal that it is
> >> >> OK to suspend again, so you are forcing the thread that tried to
> >> >> suspend to poll until you stop aborting suspend.
> >> >
> >> > No, you do not need to poll. You just set a timeout (short or long,
> >> > depending on your needs) and if no userspace task blocked suspend
> >> > durng that time you attempt to initiate suspend from your manager
> >> > process. If it succeeds - good, if not that means that more events came
> >> > your way and you have to do it later.
> >> >
> >>
> >> How is that not polling? If the user is holding down a key, the keypad
> >> driver has to block suspend, and user space will try to suspend again
> >> and again and again...
> >>
> >
> > If your userpsace is that stupid - sure. However, you can:
> >
> > 1. Notify the suspend manager process that he rest of your userspace is
> > busy handling keystrokes so that it does not try to suspend while there
> > are events pending.
> 
> You are missing the point. There are no event pending. The kernel
> reported the key down event, it was handled, but the keypad driver is
> still scanning to see if the user presses another key,

Employ reasonable timeout.

> or releases the
> currently held key.
> 

Userspace consumer should wait for the key release and retract "busy"
once event is received and handled.

> >
> > 2. Wait a tiny bit after last application notified you that it finished
> > processing events.
> >
> > So basically the difference is that with in-kernel suspend blockers,
> > there is a tiny window where we haven't started the suspend yet but are
> > about to the driver has a chance to prevent entire system from starting
> > sleep.
> 
> No, the difference is that if a driver needs to prevent suspend for an
> extended period of time, you don't have user space continuously
> polling to see if it can suspend.

Why would a driver, on its own, prevent suspend for extended periods of
time? I think that the decision should originate from userspace, kernel
is here just to serve the requests.

> 
> >
> > Without the blocker we may start suspending and will stop midcycle. We
> > may be even better off in the end since we could leave some devices
> > still powered down after aborting system-wide suspend.
> >
> 
> That does not sound right.

Why doesn't it? If a device implements runtime PM it may chose remain in
powered-down mode even if system is awake.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
> >> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
> >> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
> >> >> <dmitry.torokhov@gmail.com> wrote:
> >> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
> >> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> >> >> >>
> >> >> >> > > Here's the scenario:
> >> >> >> > >
> >> >> >> > > The system is awake, and the user presses a key. The keyboard driver
> >> >> >> > > processes the keystroke and puts it in an input queue.  A user process
> >> >> >> > > reads it from the event queue, thereby emptying the queue.
> >> >> >> > >
> >> >> >> > > At that moment, the system decides to go into opportunistic suspend.
> >> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
> >> >> >> > > first step, userspace is frozen -- before the process has a chance to
> >> >> >> > > do anything with the keystroke it just read.  As a result, the system
> >> >> >> > > stays asleep until something else wakes it up, even though the
> >> >> >> > > keystroke was important and should have prevented it from sleeping.
> >> >> >> > >
> >> >> >> > > Suspend blockers protect against this scenario.  Here's how:
> >> >> >> > >
> >> >> >> > > The user process doesn't read the input queue directly; instead it
> >> >> >> > > does a select or poll.  When it sees there is data in the queue, it
> >> >> >> > > first acquires a suspend blocker and then reads the data.
> >> >> >> > >
> >> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> >> >> >> > > blocker is active.  The user process can do whatever it wants with the
> >> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
> >> >> >> > > loops back to the select/poll call.
> >> >> >> > >
> >> >> >> >
> >> >> >> > What you describe can be done in userspace though, via a "suspend manager"
> >> >> >> > process. Tasks reading input events will post "busy" events to stop the
> >> >> >> > manager process from sending system into suspend. But this can be confined to
> >> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> >> >> >> > to not go into suspend with full queues, but that is using existing kernel
> >> >> >> > APIs).
> >> >> >>
> >> >> >> I think that could be made to work.  And it might remove the need for
> >> >> >> the userspace suspend-blocker API, which would be an advantage.  It
> >> >> >> could even remove the need for the opportunistic-suspend workqueue --
> >> >> >> opportunistic suspends would be initiated by the "suspend manager"
> >> >> >> process instead of by the kernel.
> >> >> >>
> >> >> >> However you still have the issue of modifying the kernel drivers to
> >> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
> >> >> >> that is more or less equivalent to implementing kernel-level suspend
> >> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
> >> >> >> because it will prevent a suspend from starting if a queue is
> >> >> >> non-empty, instead of allowing the suspend to start and then aborting
> >> >> >> it partway through.)
> >> >> >>
> >> >> >> Maybe I'm missing something here...  No doubt someone will point it out
> >> >> >> if I am.
> >> >> >>
> >> >> >
> >> >> > Well, from my perspective that would limit changes to the evdev driver
> >> >> > (well, limited input core plumbing will be needed) but that is using the
> >> >> > current PM infrastructure. The HW driver changes will be limited to what
> >> >> > you described "type 2" in your other e-mail.
> >> >> >
> >> >> > Also, not suspending while events are in progress) is probably
> >> >> > beneficial for platforms other than Android as well. So unless I am
> >> >> > missing something this sounds like a win.
> >> >> >
> >> >>
> >> >> How would this limit the changes you need in the evdev driver? It need
> >> >> to block suspend when there are unprocessed events in some queues.
> >> >> Suspend blockers gives you an api to do this, without it, you check
> >> >> the queues in your suspend hook and abort suspend if they are not
> >> >> empty. Without suspend blockers you have no api to signal that it is
> >> >> OK to suspend again, so you are forcing the thread that tried to
> >> >> suspend to poll until you stop aborting suspend.
> >> >
> >> > No, you do not need to poll. You just set a timeout (short or long,
> >> > depending on your needs) and if no userspace task blocked suspend
> >> > durng that time you attempt to initiate suspend from your manager
> >> > process. If it succeeds - good, if not that means that more events came
> >> > your way and you have to do it later.
> >> >
> >>
> >> How is that not polling? If the user is holding down a key, the keypad
> >> driver has to block suspend, and user space will try to suspend again
> >> and again and again...
> >>
> >
> > If your userpsace is that stupid - sure. However, you can:
> >
> > 1. Notify the suspend manager process that he rest of your userspace is
> > busy handling keystrokes so that it does not try to suspend while there
> > are events pending.
> 
> You are missing the point. There are no event pending. The kernel
> reported the key down event, it was handled, but the keypad driver is
> still scanning to see if the user presses another key,

Employ reasonable timeout.

> or releases the
> currently held key.
> 

Userspace consumer should wait for the key release and retract "busy"
once event is received and handled.

> >
> > 2. Wait a tiny bit after last application notified you that it finished
> > processing events.
> >
> > So basically the difference is that with in-kernel suspend blockers,
> > there is a tiny window where we haven't started the suspend yet but are
> > about to the driver has a chance to prevent entire system from starting
> > sleep.
> 
> No, the difference is that if a driver needs to prevent suspend for an
> extended period of time, you don't have user space continuously
> polling to see if it can suspend.

Why would a driver, on its own, prevent suspend for extended periods of
time? I think that the decision should originate from userspace, kernel
is here just to serve the requests.

> 
> >
> > Without the blocker we may start suspending and will stop midcycle. We
> > may be even better off in the end since we could leave some devices
> > still powered down after aborting system-wide suspend.
> >
> 
> That does not sound right.

Why doesn't it? If a device implements runtime PM it may chose remain in
powered-down mode even if system is awake.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> >> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> >> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> >> >> <dmitry.torokhov@gmail.com> wrote:
>> >> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >> >> >>
>> >> >> >> > > Here's the scenario:
>> >> >> >> > >
>> >> >> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> >> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> >> >> > > reads it from the event queue, thereby emptying the queue.
>> >> >> >> > >
>> >> >> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> >> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> >> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> >> >> > > stays asleep until something else wakes it up, even though the
>> >> >> >> > > keystroke was important and should have prevented it from sleeping.
>> >> >> >> > >
>> >> >> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> >> >> > >
>> >> >> >> > > The user process doesn't read the input queue directly; instead it
>> >> >> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> >> >> > > first acquires a suspend blocker and then reads the data.
>> >> >> >> > >
>> >> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> >> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> >> >> > > loops back to the select/poll call.
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> >> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> >> >> > manager process from sending system into suspend. But this can be confined to
>> >> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> >> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> >> >> > APIs).
>> >> >> >>
>> >> >> >> I think that could be made to work.  And it might remove the need for
>> >> >> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> >> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> >> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> >> >> process instead of by the kernel.
>> >> >> >>
>> >> >> >> However you still have the issue of modifying the kernel drivers to
>> >> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> >> >> that is more or less equivalent to implementing kernel-level suspend
>> >> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> >> >> because it will prevent a suspend from starting if a queue is
>> >> >> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> >> >> it partway through.)
>> >> >> >>
>> >> >> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> >> >> if I am.
>> >> >> >>
>> >> >> >
>> >> >> > Well, from my perspective that would limit changes to the evdev driver
>> >> >> > (well, limited input core plumbing will be needed) but that is using the
>> >> >> > current PM infrastructure. The HW driver changes will be limited to what
>> >> >> > you described "type 2" in your other e-mail.
>> >> >> >
>> >> >> > Also, not suspending while events are in progress) is probably
>> >> >> > beneficial for platforms other than Android as well. So unless I am
>> >> >> > missing something this sounds like a win.
>> >> >> >
>> >> >>
>> >> >> How would this limit the changes you need in the evdev driver? It need
>> >> >> to block suspend when there are unprocessed events in some queues.
>> >> >> Suspend blockers gives you an api to do this, without it, you check
>> >> >> the queues in your suspend hook and abort suspend if they are not
>> >> >> empty. Without suspend blockers you have no api to signal that it is
>> >> >> OK to suspend again, so you are forcing the thread that tried to
>> >> >> suspend to poll until you stop aborting suspend.
>> >> >
>> >> > No, you do not need to poll. You just set a timeout (short or long,
>> >> > depending on your needs) and if no userspace task blocked suspend
>> >> > durng that time you attempt to initiate suspend from your manager
>> >> > process. If it succeeds - good, if not that means that more events came
>> >> > your way and you have to do it later.
>> >> >
>> >>
>> >> How is that not polling? If the user is holding down a key, the keypad
>> >> driver has to block suspend, and user space will try to suspend again
>> >> and again and again...
>> >>
>> >
>> > If your userpsace is that stupid - sure. However, you can:
>> >
>> > 1. Notify the suspend manager process that he rest of your userspace is
>> > busy handling keystrokes so that it does not try to suspend while there
>> > are events pending.
>>
>> You are missing the point. There are no event pending. The kernel
>> reported the key down event, it was handled, but the keypad driver is
>> still scanning to see if the user presses another key,
>
> Employ reasonable timeout.

Timeout for what? Stop trying to suspend altogether, stop scanning for
key changes, or a more "reasonable" poll interval?

>
>> or releases the
>> currently held key.
>>
>
> Userspace consumer should wait for the key release and retract "busy"
> once event is received and handled.
>

No it should not. User-space does not know if the key is coming from a
keypad driver that needs to actively scan the matrix while keys are
pressed.

>> >
>> > 2. Wait a tiny bit after last application notified you that it finished
>> > processing events.
>> >
>> > So basically the difference is that with in-kernel suspend blockers,
>> > there is a tiny window where we haven't started the suspend yet but are
>> > about to the driver has a chance to prevent entire system from starting
>> > sleep.
>>
>> No, the difference is that if a driver needs to prevent suspend for an
>> extended period of time, you don't have user space continuously
>> polling to see if it can suspend.
>
> Why would a driver, on its own, prevent suspend for extended periods of
> time? I think that the decision should originate from userspace, kernel
> is here just to serve the requests.
>

A driver prevents suspend if suspend would prevent it from working.
For instance, the gpio keypad matrix code prevents suspend when a key
is help down, since it has to activly scan the keypad for changes.
Only no-keys-pressed versus one-or-more-keys-pressed can be detected
with an interrupt.

>>
>> >
>> > Without the blocker we may start suspending and will stop midcycle. We
>> > may be even better off in the end since we could leave some devices
>> > still powered down after aborting system-wide suspend.
>> >
>>
>> That does not sound right.
>
> Why doesn't it? If a device implements runtime PM it may chose remain in
> powered-down mode even if system is awake.
>

If the device implements runtime PM it should already be powered-down
if it is not in use.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 03:37:48PM -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> >> > On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>> >> >> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>> >> >> <dmitry.torokhov@gmail.com> wrote:
>> >> >> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>> >> >> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>> >> >> >>
>> >> >> >> > > Here's the scenario:
>> >> >> >> > >
>> >> >> >> > > The system is awake, and the user presses a key. The keyboard driver
>> >> >> >> > > processes the keystroke and puts it in an input queue.  A user process
>> >> >> >> > > reads it from the event queue, thereby emptying the queue.
>> >> >> >> > >
>> >> >> >> > > At that moment, the system decides to go into opportunistic suspend.
>> >> >> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>> >> >> >> > > first step, userspace is frozen -- before the process has a chance to
>> >> >> >> > > do anything with the keystroke it just read.  As a result, the system
>> >> >> >> > > stays asleep until something else wakes it up, even though the
>> >> >> >> > > keystroke was important and should have prevented it from sleeping.
>> >> >> >> > >
>> >> >> >> > > Suspend blockers protect against this scenario.  Here's how:
>> >> >> >> > >
>> >> >> >> > > The user process doesn't read the input queue directly; instead it
>> >> >> >> > > does a select or poll.  When it sees there is data in the queue, it
>> >> >> >> > > first acquires a suspend blocker and then reads the data.
>> >> >> >> > >
>> >> >> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>> >> >> >> > > blocker is active.  The user process can do whatever it wants with the
>> >> >> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>> >> >> >> > > loops back to the select/poll call.
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> > What you describe can be done in userspace though, via a "suspend manager"
>> >> >> >> > process. Tasks reading input events will post "busy" events to stop the
>> >> >> >> > manager process from sending system into suspend. But this can be confined to
>> >> >> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>> >> >> >> > to not go into suspend with full queues, but that is using existing kernel
>> >> >> >> > APIs).
>> >> >> >>
>> >> >> >> I think that could be made to work.  And it might remove the need for
>> >> >> >> the userspace suspend-blocker API, which would be an advantage.  It
>> >> >> >> could even remove the need for the opportunistic-suspend workqueue --
>> >> >> >> opportunistic suspends would be initiated by the "suspend manager"
>> >> >> >> process instead of by the kernel.
>> >> >> >>
>> >> >> >> However you still have the issue of modifying the kernel drivers to
>> >> >> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>> >> >> >> that is more or less equivalent to implementing kernel-level suspend
>> >> >> >> blockers.  (The suspend blocker approach is slightly more efficient,
>> >> >> >> because it will prevent a suspend from starting if a queue is
>> >> >> >> non-empty, instead of allowing the suspend to start and then aborting
>> >> >> >> it partway through.)
>> >> >> >>
>> >> >> >> Maybe I'm missing something here...  No doubt someone will point it out
>> >> >> >> if I am.
>> >> >> >>
>> >> >> >
>> >> >> > Well, from my perspective that would limit changes to the evdev driver
>> >> >> > (well, limited input core plumbing will be needed) but that is using the
>> >> >> > current PM infrastructure. The HW driver changes will be limited to what
>> >> >> > you described "type 2" in your other e-mail.
>> >> >> >
>> >> >> > Also, not suspending while events are in progress) is probably
>> >> >> > beneficial for platforms other than Android as well. So unless I am
>> >> >> > missing something this sounds like a win.
>> >> >> >
>> >> >>
>> >> >> How would this limit the changes you need in the evdev driver? It need
>> >> >> to block suspend when there are unprocessed events in some queues.
>> >> >> Suspend blockers gives you an api to do this, without it, you check
>> >> >> the queues in your suspend hook and abort suspend if they are not
>> >> >> empty. Without suspend blockers you have no api to signal that it is
>> >> >> OK to suspend again, so you are forcing the thread that tried to
>> >> >> suspend to poll until you stop aborting suspend.
>> >> >
>> >> > No, you do not need to poll. You just set a timeout (short or long,
>> >> > depending on your needs) and if no userspace task blocked suspend
>> >> > durng that time you attempt to initiate suspend from your manager
>> >> > process. If it succeeds - good, if not that means that more events came
>> >> > your way and you have to do it later.
>> >> >
>> >>
>> >> How is that not polling? If the user is holding down a key, the keypad
>> >> driver has to block suspend, and user space will try to suspend again
>> >> and again and again...
>> >>
>> >
>> > If your userpsace is that stupid - sure. However, you can:
>> >
>> > 1. Notify the suspend manager process that he rest of your userspace is
>> > busy handling keystrokes so that it does not try to suspend while there
>> > are events pending.
>>
>> You are missing the point. There are no event pending. The kernel
>> reported the key down event, it was handled, but the keypad driver is
>> still scanning to see if the user presses another key,
>
> Employ reasonable timeout.

Timeout for what? Stop trying to suspend altogether, stop scanning for
key changes, or a more "reasonable" poll interval?

>
>> or releases the
>> currently held key.
>>
>
> Userspace consumer should wait for the key release and retract "busy"
> once event is received and handled.
>

No it should not. User-space does not know if the key is coming from a
keypad driver that needs to actively scan the matrix while keys are
pressed.

>> >
>> > 2. Wait a tiny bit after last application notified you that it finished
>> > processing events.
>> >
>> > So basically the difference is that with in-kernel suspend blockers,
>> > there is a tiny window where we haven't started the suspend yet but are
>> > about to the driver has a chance to prevent entire system from starting
>> > sleep.
>>
>> No, the difference is that if a driver needs to prevent suspend for an
>> extended period of time, you don't have user space continuously
>> polling to see if it can suspend.
>
> Why would a driver, on its own, prevent suspend for extended periods of
> time? I think that the decision should originate from userspace, kernel
> is here just to serve the requests.
>

A driver prevents suspend if suspend would prevent it from working.
For instance, the gpio keypad matrix code prevents suspend when a key
is help down, since it has to activly scan the keypad for changes.
Only no-keys-pressed versus one-or-more-keys-pressed can be detected
with an interrupt.

>>
>> >
>> > Without the blocker we may start suspending and will stop midcycle. We
>> > may be even better off in the end since we could leave some devices
>> > still powered down after aborting system-wide suspend.
>> >
>>
>> That does not sound right.
>
> Why doesn't it? If a device implements runtime PM it may chose remain in
> powered-down mode even if system is awake.
>

If the device implements runtime PM it should already be powered-down
if it is not in use.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Kevin Hilman <khilman@deeprootsystems.com>:
> Arve Hjønnevåg <arve@android.com> writes:
>
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>>>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>>>> <dmitry.torokhov@gmail.com> wrote:
>>>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>>>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>>> >>
>>>> >> > > Here's the scenario:
>>>> >> > >
>>>> >> > > The system is awake, and the user presses a key. The keyboard driver
>>>> >> > > processes the keystroke and puts it in an input queue.  A user process
>>>> >> > > reads it from the event queue, thereby emptying the queue.
>>>> >> > >
>>>> >> > > At that moment, the system decides to go into opportunistic suspend.
>>>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>>>> >> > > first step, userspace is frozen -- before the process has a chance to
>>>> >> > > do anything with the keystroke it just read.  As a result, the system
>>>> >> > > stays asleep until something else wakes it up, even though the
>>>> >> > > keystroke was important and should have prevented it from sleeping.
>>>> >> > >
>>>> >> > > Suspend blockers protect against this scenario.  Here's how:
>>>> >> > >
>>>> >> > > The user process doesn't read the input queue directly; instead it
>>>> >> > > does a select or poll.  When it sees there is data in the queue, it
>>>> >> > > first acquires a suspend blocker and then reads the data.
>>>> >> > >
>>>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>>>> >> > > blocker is active.  The user process can do whatever it wants with the
>>>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>>>> >> > > loops back to the select/poll call.
>>>> >> > >
>>>> >> >
>>>> >> > What you describe can be done in userspace though, via a "suspend manager"
>>>> >> > process. Tasks reading input events will post "busy" events to stop the
>>>> >> > manager process from sending system into suspend. But this can be confined to
>>>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>>>> >> > to not go into suspend with full queues, but that is using existing kernel
>>>> >> > APIs).
>>>> >>
>>>> >> I think that could be made to work.  And it might remove the need for
>>>> >> the userspace suspend-blocker API, which would be an advantage.  It
>>>> >> could even remove the need for the opportunistic-suspend workqueue --
>>>> >> opportunistic suspends would be initiated by the "suspend manager"
>>>> >> process instead of by the kernel.
>>>> >>
>>>> >> However you still have the issue of modifying the kernel drivers to
>>>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>>>> >> that is more or less equivalent to implementing kernel-level suspend
>>>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>>>> >> because it will prevent a suspend from starting if a queue is
>>>> >> non-empty, instead of allowing the suspend to start and then aborting
>>>> >> it partway through.)
>>>> >>
>>>> >> Maybe I'm missing something here...  No doubt someone will point it out
>>>> >> if I am.
>>>> >>
>>>> >
>>>> > Well, from my perspective that would limit changes to the evdev driver
>>>> > (well, limited input core plumbing will be needed) but that is using the
>>>> > current PM infrastructure. The HW driver changes will be limited to what
>>>> > you described "type 2" in your other e-mail.
>>>> >
>>>> > Also, not suspending while events are in progress) is probably
>>>> > beneficial for platforms other than Android as well. So unless I am
>>>> > missing something this sounds like a win.
>>>> >
>>>>
>>>> How would this limit the changes you need in the evdev driver? It need
>>>> to block suspend when there are unprocessed events in some queues.
>>>> Suspend blockers gives you an api to do this, without it, you check
>>>> the queues in your suspend hook and abort suspend if they are not
>>>> empty. Without suspend blockers you have no api to signal that it is
>>>> OK to suspend again, so you are forcing the thread that tried to
>>>> suspend to poll until you stop aborting suspend.
>>>
>>> No, you do not need to poll. You just set a timeout (short or long,
>>> depending on your needs) and if no userspace task blocked suspend
>>> durng that time you attempt to initiate suspend from your manager
>>> process. If it succeeds - good, if not that means that more events came
>>> your way and you have to do it later.
>>>
>>
>> How is that not polling? If the user is holding down a key, the keypad
>> driver has to block suspend, and user space will try to suspend again
>> and again and again...
>
> Then the userspace suspend manager should be a little more clever
> and should not blindly retry continuously.
>
> It should be more like a governor which makes some simple decisions
> based on previous events, simple heuristics, uses timeouts etc.,
>

So instead of the kernel suspending as soon as the last driver stops
blocking suspend, you want to add heuristics in user-space to guess
when suspend will succeed. This would, in my opinion, be a much worse
solution.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Kevin Hilman <khilman@deeprootsystems.com>:
> Arve Hjønnevåg <arve@android.com> writes:
>
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> On Tue, May 25, 2010 at 03:23:23PM -0700, Arve Hjønnevåg wrote:
>>>> On Tue, May 25, 2010 at 11:47 AM, Dmitry Torokhov
>>>> <dmitry.torokhov@gmail.com> wrote:
>>>> > On Tue, May 25, 2010 at 02:35:17PM -0400, Alan Stern wrote:
>>>> >> On Tue, 25 May 2010, Dmitry Torokhov wrote:
>>>> >>
>>>> >> > > Here's the scenario:
>>>> >> > >
>>>> >> > > The system is awake, and the user presses a key. The keyboard driver
>>>> >> > > processes the keystroke and puts it in an input queue.  A user process
>>>> >> > > reads it from the event queue, thereby emptying the queue.
>>>> >> > >
>>>> >> > > At that moment, the system decides to go into opportunistic suspend.
>>>> >> > > Since the input queue is empty, there's nothing to stop it.  As the
>>>> >> > > first step, userspace is frozen -- before the process has a chance to
>>>> >> > > do anything with the keystroke it just read.  As a result, the system
>>>> >> > > stays asleep until something else wakes it up, even though the
>>>> >> > > keystroke was important and should have prevented it from sleeping.
>>>> >> > >
>>>> >> > > Suspend blockers protect against this scenario.  Here's how:
>>>> >> > >
>>>> >> > > The user process doesn't read the input queue directly; instead it
>>>> >> > > does a select or poll.  When it sees there is data in the queue, it
>>>> >> > > first acquires a suspend blocker and then reads the data.
>>>> >> > >
>>>> >> > > Now the system _can't_ go into opportunistic suspend, because a suspend
>>>> >> > > blocker is active.  The user process can do whatever it wants with the
>>>> >> > > keystroke.  When it is finished, it releases the suspend blocker and
>>>> >> > > loops back to the select/poll call.
>>>> >> > >
>>>> >> >
>>>> >> > What you describe can be done in userspace though, via a "suspend manager"
>>>> >> > process. Tasks reading input events will post "busy" events to stop the
>>>> >> > manager process from sending system into suspend. But this can be confined to
>>>> >> > Android userspace, leaving the kernel as is (well, kernel needs to be modified
>>>> >> > to not go into suspend with full queues, but that is using existing kernel
>>>> >> > APIs).
>>>> >>
>>>> >> I think that could be made to work.  And it might remove the need for
>>>> >> the userspace suspend-blocker API, which would be an advantage.  It
>>>> >> could even remove the need for the opportunistic-suspend workqueue --
>>>> >> opportunistic suspends would be initiated by the "suspend manager"
>>>> >> process instead of by the kernel.
>>>> >>
>>>> >> However you still have the issue of modifying the kernel drivers to
>>>> >> disallow opportunistic suspend if their queues are non-empty.  Doing
>>>> >> that is more or less equivalent to implementing kernel-level suspend
>>>> >> blockers.  (The suspend blocker approach is slightly more efficient,
>>>> >> because it will prevent a suspend from starting if a queue is
>>>> >> non-empty, instead of allowing the suspend to start and then aborting
>>>> >> it partway through.)
>>>> >>
>>>> >> Maybe I'm missing something here...  No doubt someone will point it out
>>>> >> if I am.
>>>> >>
>>>> >
>>>> > Well, from my perspective that would limit changes to the evdev driver
>>>> > (well, limited input core plumbing will be needed) but that is using the
>>>> > current PM infrastructure. The HW driver changes will be limited to what
>>>> > you described "type 2" in your other e-mail.
>>>> >
>>>> > Also, not suspending while events are in progress) is probably
>>>> > beneficial for platforms other than Android as well. So unless I am
>>>> > missing something this sounds like a win.
>>>> >
>>>>
>>>> How would this limit the changes you need in the evdev driver? It need
>>>> to block suspend when there are unprocessed events in some queues.
>>>> Suspend blockers gives you an api to do this, without it, you check
>>>> the queues in your suspend hook and abort suspend if they are not
>>>> empty. Without suspend blockers you have no api to signal that it is
>>>> OK to suspend again, so you are forcing the thread that tried to
>>>> suspend to poll until you stop aborting suspend.
>>>
>>> No, you do not need to poll. You just set a timeout (short or long,
>>> depending on your needs) and if no userspace task blocked suspend
>>> durng that time you attempt to initiate suspend from your manager
>>> process. If it succeeds - good, if not that means that more events came
>>> your way and you have to do it later.
>>>
>>
>> How is that not polling? If the user is holding down a key, the keypad
>> driver has to block suspend, and user space will try to suspend again
>> and again and again...
>
> Then the userspace suspend manager should be a little more clever
> and should not blindly retry continuously.
>
> It should be more like a governor which makes some simple decisions
> based on previous events, simple heuristics, uses timeouts etc.,
>

So instead of the kernel suspending as soon as the last driver stops
blocking suspend, you want to add heuristics in user-space to guess
when suspend will succeed. This would, in my opinion, be a much worse
solution.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
> >>
> >> You are missing the point. There are no event pending. The kernel
> >> reported the key down event, it was handled, but the keypad driver is
> >> still scanning to see if the user presses another key,
> >
> > Employ reasonable timeout.
> 
> Timeout for what? Stop trying to suspend altogether, stop scanning for
> key changes, or a more "reasonable" poll interval?

Stop trying to suspend for a fraction of a second to see if user wants
to press another key.

> 
> >
> >> or releases the
> >> currently held key.
> >>
> >
> > Userspace consumer should wait for the key release and retract "busy"
> > once event is received and handled.
> >
> 
> No it should not. User-space does not know if the key is coming from a
> keypad driver that needs to actively scan the matrix while keys are
> pressed.

OTOH nor does kernel driver know whether system suspend should be
blocked while it is scanning. What should happen in I press KEY_SUSPEND?
Do we always want to wait till user releases it?

> 
> >> >
> >> > 2. Wait a tiny bit after last application notified you that it finished
> >> > processing events.
> >> >
> >> > So basically the difference is that with in-kernel suspend blockers,
> >> > there is a tiny window where we haven't started the suspend yet but are
> >> > about to the driver has a chance to prevent entire system from starting
> >> > sleep.
> >>
> >> No, the difference is that if a driver needs to prevent suspend for an
> >> extended period of time, you don't have user space continuously
> >> polling to see if it can suspend.
> >
> > Why would a driver, on its own, prevent suspend for extended periods of
> > time? I think that the decision should originate from userspace, kernel
> > is here just to serve the requests.
> >
> 
> A driver prevents suspend if suspend would prevent it from working.
> For instance, the gpio keypad matrix code prevents suspend when a key
> is help down, since it has to activly scan the keypad for changes.
> Only no-keys-pressed versus one-or-more-keys-pressed can be detected
> with an interrupt.
> 
> >>
> >> >
> >> > Without the blocker we may start suspending and will stop midcycle. We
> >> > may be even better off in the end since we could leave some devices
> >> > still powered down after aborting system-wide suspend.
> >> >
> >>
> >> That does not sound right.
> >
> > Why doesn't it? If a device implements runtime PM it may chose remain in
> > powered-down mode even if system is awake.
> >
> 
> If the device implements runtime PM it should already be powered-down
> if it is not in use.

It could have been in use but userspace-initiated suspend accelerated it
entering low power state.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
> >>
> >> You are missing the point. There are no event pending. The kernel
> >> reported the key down event, it was handled, but the keypad driver is
> >> still scanning to see if the user presses another key,
> >
> > Employ reasonable timeout.
> 
> Timeout for what? Stop trying to suspend altogether, stop scanning for
> key changes, or a more "reasonable" poll interval?

Stop trying to suspend for a fraction of a second to see if user wants
to press another key.

> 
> >
> >> or releases the
> >> currently held key.
> >>
> >
> > Userspace consumer should wait for the key release and retract "busy"
> > once event is received and handled.
> >
> 
> No it should not. User-space does not know if the key is coming from a
> keypad driver that needs to actively scan the matrix while keys are
> pressed.

OTOH nor does kernel driver know whether system suspend should be
blocked while it is scanning. What should happen in I press KEY_SUSPEND?
Do we always want to wait till user releases it?

> 
> >> >
> >> > 2. Wait a tiny bit after last application notified you that it finished
> >> > processing events.
> >> >
> >> > So basically the difference is that with in-kernel suspend blockers,
> >> > there is a tiny window where we haven't started the suspend yet but are
> >> > about to the driver has a chance to prevent entire system from starting
> >> > sleep.
> >>
> >> No, the difference is that if a driver needs to prevent suspend for an
> >> extended period of time, you don't have user space continuously
> >> polling to see if it can suspend.
> >
> > Why would a driver, on its own, prevent suspend for extended periods of
> > time? I think that the decision should originate from userspace, kernel
> > is here just to serve the requests.
> >
> 
> A driver prevents suspend if suspend would prevent it from working.
> For instance, the gpio keypad matrix code prevents suspend when a key
> is help down, since it has to activly scan the keypad for changes.
> Only no-keys-pressed versus one-or-more-keys-pressed can be detected
> with an interrupt.
> 
> >>
> >> >
> >> > Without the blocker we may start suspending and will stop midcycle. We
> >> > may be even better off in the end since we could leave some devices
> >> > still powered down after aborting system-wide suspend.
> >> >
> >>
> >> That does not sound right.
> >
> > Why doesn't it? If a device implements runtime PM it may chose remain in
> > powered-down mode even if system is awake.
> >
> 
> If the device implements runtime PM it should already be powered-down
> if it is not in use.

It could have been in use but userspace-initiated suspend accelerated it
entering low power state.

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
>> >>
>> >> You are missing the point. There are no event pending. The kernel
>> >> reported the key down event, it was handled, but the keypad driver is
>> >> still scanning to see if the user presses another key,
>> >
>> > Employ reasonable timeout.
>>
>> Timeout for what? Stop trying to suspend altogether, stop scanning for
>> key changes, or a more "reasonable" poll interval?
>
> Stop trying to suspend for a fraction of a second to see if user wants
> to press another key.
>

In other words, try to suspend several times a second until it succeeds.

>>
>> >
>> >> or releases the
>> >> currently held key.
>> >>
>> >
>> > Userspace consumer should wait for the key release and retract "busy"
>> > once event is received and handled.
>> >
>>
>> No it should not. User-space does not know if the key is coming from a
>> keypad driver that needs to actively scan the matrix while keys are
>> pressed.
>
> OTOH nor does kernel driver know whether system suspend should be
> blocked while it is scanning.

Yes it does, it cannot deliver wakeup keys if it suspends.

> What should happen in I press KEY_SUSPEND?
> Do we always want to wait till user releases it?

If KEY_SUSPEND is part of the keypad matrix, then yes.

>
>>
>> >> >
>> >> > 2. Wait a tiny bit after last application notified you that it finished
>> >> > processing events.
>> >> >
>> >> > So basically the difference is that with in-kernel suspend blockers,
>> >> > there is a tiny window where we haven't started the suspend yet but are
>> >> > about to the driver has a chance to prevent entire system from starting
>> >> > sleep.
>> >>
>> >> No, the difference is that if a driver needs to prevent suspend for an
>> >> extended period of time, you don't have user space continuously
>> >> polling to see if it can suspend.
>> >
>> > Why would a driver, on its own, prevent suspend for extended periods of
>> > time? I think that the decision should originate from userspace, kernel
>> > is here just to serve the requests.
>> >
>>
>> A driver prevents suspend if suspend would prevent it from working.
>> For instance, the gpio keypad matrix code prevents suspend when a key
>> is help down, since it has to activly scan the keypad for changes.
>> Only no-keys-pressed versus one-or-more-keys-pressed can be detected
>> with an interrupt.
>>
>> >>
>> >> >
>> >> > Without the blocker we may start suspending and will stop midcycle. We
>> >> > may be even better off in the end since we could leave some devices
>> >> > still powered down after aborting system-wide suspend.
>> >> >
>> >>
>> >> That does not sound right.
>> >
>> > Why doesn't it? If a device implements runtime PM it may chose remain in
>> > powered-down mode even if system is awake.
>> >
>>
>> If the device implements runtime PM it should already be powered-down
>> if it is not in use.
>
> It could have been in use but userspace-initiated suspend accelerated it
> entering low power state.
>

So you are suggesting we should repeatedly try to suspend the whole
system to accelerate runtime PM powering down devices? Why not power
the device down as soon as it is not in use?

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
>> >>
>> >> You are missing the point. There are no event pending. The kernel
>> >> reported the key down event, it was handled, but the keypad driver is
>> >> still scanning to see if the user presses another key,
>> >
>> > Employ reasonable timeout.
>>
>> Timeout for what? Stop trying to suspend altogether, stop scanning for
>> key changes, or a more "reasonable" poll interval?
>
> Stop trying to suspend for a fraction of a second to see if user wants
> to press another key.
>

In other words, try to suspend several times a second until it succeeds.

>>
>> >
>> >> or releases the
>> >> currently held key.
>> >>
>> >
>> > Userspace consumer should wait for the key release and retract "busy"
>> > once event is received and handled.
>> >
>>
>> No it should not. User-space does not know if the key is coming from a
>> keypad driver that needs to actively scan the matrix while keys are
>> pressed.
>
> OTOH nor does kernel driver know whether system suspend should be
> blocked while it is scanning.

Yes it does, it cannot deliver wakeup keys if it suspends.

> What should happen in I press KEY_SUSPEND?
> Do we always want to wait till user releases it?

If KEY_SUSPEND is part of the keypad matrix, then yes.

>
>>
>> >> >
>> >> > 2. Wait a tiny bit after last application notified you that it finished
>> >> > processing events.
>> >> >
>> >> > So basically the difference is that with in-kernel suspend blockers,
>> >> > there is a tiny window where we haven't started the suspend yet but are
>> >> > about to the driver has a chance to prevent entire system from starting
>> >> > sleep.
>> >>
>> >> No, the difference is that if a driver needs to prevent suspend for an
>> >> extended period of time, you don't have user space continuously
>> >> polling to see if it can suspend.
>> >
>> > Why would a driver, on its own, prevent suspend for extended periods of
>> > time? I think that the decision should originate from userspace, kernel
>> > is here just to serve the requests.
>> >
>>
>> A driver prevents suspend if suspend would prevent it from working.
>> For instance, the gpio keypad matrix code prevents suspend when a key
>> is help down, since it has to activly scan the keypad for changes.
>> Only no-keys-pressed versus one-or-more-keys-pressed can be detected
>> with an interrupt.
>>
>> >>
>> >> >
>> >> > Without the blocker we may start suspending and will stop midcycle. We
>> >> > may be even better off in the end since we could leave some devices
>> >> > still powered down after aborting system-wide suspend.
>> >> >
>> >>
>> >> That does not sound right.
>> >
>> > Why doesn't it? If a device implements runtime PM it may chose remain in
>> > powered-down mode even if system is awake.
>> >
>>
>> If the device implements runtime PM it should already be powered-down
>> if it is not in use.
>
> It could have been in use but userspace-initiated suspend accelerated it
> entering low power state.
>

So you are suggesting we should repeatedly try to suspend the whole
system to accelerate runtime PM powering down devices? Why not power
the device down as soon as it is not in use?

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 23:44 +0200, Rafael J. Wysocki wrote:
> 
> No, I don't really think it's going to be a small change.  The problem is that
> for the Android people changing user space is very hard, so I don't think
> this realy is an option, given that they would have to implement it themselves,
> test it, validate it on multiple different hardware platforms etc. and _then_
> resubmit the feature without any guarantee that it will be merged. 

So your position is basically that we're going to merge this stuff
because google doesn't want to expend effort into investigating a
potential saner solution?

So why don't we simply merge all the crap people throw at us and be done
with it.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 23:44 +0200, Rafael J. Wysocki wrote:
> 
> No, I don't really think it's going to be a small change.  The problem is that
> for the Android people changing user space is very hard, so I don't think
> this realy is an option, given that they would have to implement it themselves,
> test it, validate it on multiple different hardware platforms etc. and _then_
> resubmit the feature without any guarantee that it will be merged. 

So your position is basically that we're going to merge this stuff
because google doesn't want to expend effort into investigating a
potential saner solution?

So why don't we simply merge all the crap people throw at us and be done
with it.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote:
> The biggest problem here is not that it is hard to change our
> user-space, but that the proposed change is inferior to what we have
> now. It forces us to poll until all drivers stop aborting suspend. On
> one hand we have people telling us that all code that polls is broken
> and must be fixed (instead of suspending to limit the damage), and on
> the other hand we have people suggesting we implement opportunistic
> suspend by polling from user-space until suspend succeeds. 

No it does _not_. You're really not getting that Dmitry is proposing.


So your proposal is that when we wake userspace, it
opens /dev/suspend_blocker _before_ it consumes whatever event, consumes
the event, deals with the event, then closes the suspend_blocker. Then
the kernel, upon reaching a 0 suspend_blocker count, will try to suspend
again.


What Dmitry proposes is that, the app _before_ it consumes the event,
pokes at this suspend manager, it increases a blocker count, then
consumes the event (the kernel will _not_ auto-suspend), handles it and
then again pokes the suspend manager, this time decreasing the blocker
count.

The suspend manager will, upon reaching a 0 block count, suspend the
machine. If that fails, it means there's something to do, an app will
inc, work, dec its count, and it will try again once it reaches 0 again.

There is no polling what-so-ever in this model.

The only thing is that the kernel will not try to auto-suspend and there
is no user-space suspend blocker API.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote:
> The biggest problem here is not that it is hard to change our
> user-space, but that the proposed change is inferior to what we have
> now. It forces us to poll until all drivers stop aborting suspend. On
> one hand we have people telling us that all code that polls is broken
> and must be fixed (instead of suspending to limit the damage), and on
> the other hand we have people suggesting we implement opportunistic
> suspend by polling from user-space until suspend succeeds. 

No it does _not_. You're really not getting that Dmitry is proposing.


So your proposal is that when we wake userspace, it
opens /dev/suspend_blocker _before_ it consumes whatever event, consumes
the event, deals with the event, then closes the suspend_blocker. Then
the kernel, upon reaching a 0 suspend_blocker count, will try to suspend
again.


What Dmitry proposes is that, the app _before_ it consumes the event,
pokes at this suspend manager, it increases a blocker count, then
consumes the event (the kernel will _not_ auto-suspend), handles it and
then again pokes the suspend manager, this time decreasing the blocker
count.

The suspend manager will, upon reaching a 0 block count, suspend the
machine. If that fails, it means there's something to do, an app will
inc, work, dec its count, and it will try again once it reaches 0 again.

There is no polling what-so-ever in this model.

The only thing is that the kernel will not try to auto-suspend and there
is no user-space suspend blocker API.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 22:21 +0200, Rafael J. Wysocki wrote:
> 
> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any. 

A funny userspace API of questionable use (esp. with the advent of
better hardware and better runtime PM support) which we will have to
support forever seems like a big enough downside.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 22:21 +0200, Rafael J. Wysocki wrote:
> 
> Now, we can reject their patches, but that's not going to cause any progress
> to happen, realistically.  Quite on the contrary, Android will continue to use
> wakelocks and Android driver writers will continue to ignore the mainline
> and the gap between the two kernel lines will only get wider and wider over
> time.
> 
> And what really is the drawback if we merge the patches?  Quite frankly,
> I don't see any. 

A funny userspace API of questionable use (esp. with the advent of
better hardware and better runtime PM support) which we will have to
support forever seems like a big enough downside.

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> +To create a suspend blocker from user space, open the suspend_blocker
> special
> +device file:
> +
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +
> +then optionally call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> +
> +To activate the suspend blocker call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To deactivate it call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend blocker, close the device:
> +
> +    close(fd);

Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
the SET_NAME thing if you really care.

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> +To create a suspend blocker from user space, open the suspend_blocker
> special
> +device file:
> +
> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> +
> +then optionally call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> +
> +To activate the suspend blocker call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> +
> +To deactivate it call:
> +
> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> +
> +To destroy the suspend blocker, close the device:
> +
> +    close(fd);

Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
the SET_NAME thing if you really care.

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > This patch series adds a suspend-block api that provides the same
> > functionality as the android wakelock api. This version adds a
> > delay before suspending again if no suspend blockers were used
> > during the last suspend attempt.
> 
> Patches [1-6/8] applied to suspend-2.6/linux-next

So you're going to merge this junk?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > This patch series adds a suspend-block api that provides the same
> > functionality as the android wakelock api. This version adds a
> > delay before suspending again if no suspend blockers were used
> > during the last suspend attempt.
> 
> Patches [1-6/8] applied to suspend-2.6/linux-next

So you're going to merge this junk?


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > This of course will lead to a scattering of suspend blockers into any
> > drivers/subsystems considered "useful", which by looking through current
> > Android kernels is many of them.
> 
> That depends on the maintainers of these subsystems, who still have the power
> to reject requested changes. 

So as a scheduler maintainer I'm going to merge a patch that does a
suspend_blocker when the runqueue's aren't empty... how about that?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > This of course will lead to a scattering of suspend blockers into any
> > drivers/subsystems considered "useful", which by looking through current
> > Android kernels is many of them.
> 
> That depends on the maintainers of these subsystems, who still have the power
> to reject requested changes. 

So as a scheduler maintainer I'm going to merge a patch that does a
suspend_blocker when the runqueue's aren't empty... how about that?

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 10:42 +0200, Peter Zijlstra wrote:
> What Dmitry proposes is that, the app _before_ it consumes the event,
> pokes at this suspend manager, it increases a blocker count, then
> consumes the event (the kernel will _not_ auto-suspend), handles it and
> then again pokes the suspend manager, this time decreasing the blocker
> count.
> 
> The suspend manager will, upon reaching a 0 block count, suspend the
> machine. If that fails, it means there's something to do, an app will
> inc, work, dec its count, and it will try again once it reaches 0 again.

Alternatively the suspend manager could simply cancel the opportunistic
suspend mode on !0, and re-instate it on 0.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 10:42 +0200, Peter Zijlstra wrote:
> What Dmitry proposes is that, the app _before_ it consumes the event,
> pokes at this suspend manager, it increases a blocker count, then
> consumes the event (the kernel will _not_ auto-suspend), handles it and
> then again pokes the suspend manager, this time decreasing the blocker
> count.
> 
> The suspend manager will, upon reaching a 0 block count, suspend the
> machine. If that fails, it means there's something to do, an app will
> inc, work, dec its count, and it will try again once it reaches 0 again.

Alternatively the suspend manager could simply cancel the opportunistic
suspend mode on !0, and re-instate it on 0.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Florian Mickler]

On Wed, 26 May 2010 10:42:22 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote:
> > The biggest problem here is not that it is hard to change our
> > user-space, but that the proposed change is inferior to what we have
> > now. It forces us to poll until all drivers stop aborting suspend. On
> > one hand we have people telling us that all code that polls is broken
> > and must be fixed (instead of suspending to limit the damage), and on
> > the other hand we have people suggesting we implement opportunistic
> > suspend by polling from user-space until suspend succeeds. 
> 
> No it does _not_. You're really not getting that Dmitry is proposing.
> 
> 
> So your proposal is that when we wake userspace, it
> opens /dev/suspend_blocker _before_ it consumes whatever event, consumes
> the event, deals with the event, then closes the suspend_blocker. Then
> the kernel, upon reaching a 0 suspend_blocker count, will try to suspend
> again.
> 
> 
> What Dmitry proposes is that, the app _before_ it consumes the event,
> pokes at this suspend manager, it increases a blocker count, then
> consumes the event (the kernel will _not_ auto-suspend), handles it and
> then again pokes the suspend manager, this time decreasing the blocker
> count.
> 
> The suspend manager will, upon reaching a 0 block count, suspend the
> machine. If that fails, it means there's something to do, an app will
> inc, work, dec its count, and it will try again once it reaches 0 again.
> 
> There is no polling what-so-ever in this model.
> 
> The only thing is that the kernel will not try to auto-suspend and there
> is no user-space suspend blocker API.

There is polling, because the suspend manager in userspace doesn't have
the whole picture. i.e. it doesn't know if a suspend will be
successfull. 
So for aggressive suspending as a powersave-feature you need to poll
(i.e. retry upon failure). because you don't want to stay unsuspended. 

This discussion really is going in circles. You could all may well be
just posting references to postings by now, instead of actually writing
mails.

Cheers,
Flo

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Florian Mickler]

On Wed, 26 May 2010 10:42:22 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote:
> > The biggest problem here is not that it is hard to change our
> > user-space, but that the proposed change is inferior to what we have
> > now. It forces us to poll until all drivers stop aborting suspend. On
> > one hand we have people telling us that all code that polls is broken
> > and must be fixed (instead of suspending to limit the damage), and on
> > the other hand we have people suggesting we implement opportunistic
> > suspend by polling from user-space until suspend succeeds. 
> 
> No it does _not_. You're really not getting that Dmitry is proposing.
> 
> 
> So your proposal is that when we wake userspace, it
> opens /dev/suspend_blocker _before_ it consumes whatever event, consumes
> the event, deals with the event, then closes the suspend_blocker. Then
> the kernel, upon reaching a 0 suspend_blocker count, will try to suspend
> again.
> 
> 
> What Dmitry proposes is that, the app _before_ it consumes the event,
> pokes at this suspend manager, it increases a blocker count, then
> consumes the event (the kernel will _not_ auto-suspend), handles it and
> then again pokes the suspend manager, this time decreasing the blocker
> count.
> 
> The suspend manager will, upon reaching a 0 block count, suspend the
> machine. If that fails, it means there's something to do, an app will
> inc, work, dec its count, and it will try again once it reaches 0 again.
> 
> There is no polling what-so-ever in this model.
> 
> The only thing is that the kernel will not try to auto-suspend and there
> is no user-space suspend blocker API.

There is polling, because the suspend manager in userspace doesn't have
the whole picture. i.e. it doesn't know if a suspend will be
successfull. 
So for aggressive suspending as a powersave-feature you need to poll
(i.e. retry upon failure). because you don't want to stay unsuspended. 

This discussion really is going in circles. You could all may well be
just posting references to postings by now, instead of actually writing
mails.

Cheers,
Flo

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:

> There is polling, because the suspend manager in userspace doesn't have
> the whole picture. i.e. it doesn't know if a suspend will be
> successfull. 
> So for aggressive suspending as a powersave-feature you need to poll
> (i.e. retry upon failure). because you don't want to stay unsuspended. 

Clearly if it fails, there something to be done, right? So whoever does
the thing will communicate with the suspend manager that it's going to
do and has finished doing its thing, at which point it will try again.

That's event driven, not polled.

Also, if you want you can keep the kernel-side auto-suspend side, and
have the suspend manager clear on !0 and re-establish the auto-suspend
state on 0.

But you really don't need this device thingy.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:

> There is polling, because the suspend manager in userspace doesn't have
> the whole picture. i.e. it doesn't know if a suspend will be
> successfull. 
> So for aggressive suspending as a powersave-feature you need to poll
> (i.e. retry upon failure). because you don't want to stay unsuspended. 

Clearly if it fails, there something to be done, right? So whoever does
the thing will communicate with the suspend manager that it's going to
do and has finished doing its thing, at which point it will try again.

That's event driven, not polled.

Also, if you want you can keep the kernel-side auto-suspend side, and
have the suspend manager clear on !0 and re-establish the auto-suspend
state on 0.

But you really don't need this device thingy.

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:45:33 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> > On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > > This patch series adds a suspend-block api that provides the same
> > > functionality as the android wakelock api. This version adds a
> > > delay before suspending again if no suspend blockers were used
> > > during the last suspend attempt.
> > 
> > Patches [1-6/8] applied to suspend-2.6/linux-next
> 
> So you're going to merge this junk?
> 
> 

Yes. By now, everyone reading the posts should know all points.
Raffael obviously was part of this discussion and came to the decision
to merge it. 

My take of the discussion:
_IF_ you want to suspend aggressively, I don't see another
way.

The thing is, this is a paradigm change. Suspend is not anymore
controlled by userspace. In order to let userspace control/work with
this scheme, it needs to know when a suspend will be successfull or
poll:

1. kernel sees suspend may be possible on his side of things

2. kernel sends a message to userspace that i could be possibly
possible to suspend, but it may well be that by the time
userspace suspends it is not possible anymore

3. userspace decides to suspend. 

<- system suspends...  or not ..-> 

4. userspace retries ... retries ... retries ... 

And then you have the whole can of worms and races.



Or you have the suspend-blocker scheme:

1. kernel sees suspend is possible.
2. kernel suspends.
3. bingo.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:45:33 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> > On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > > This patch series adds a suspend-block api that provides the same
> > > functionality as the android wakelock api. This version adds a
> > > delay before suspending again if no suspend blockers were used
> > > during the last suspend attempt.
> > 
> > Patches [1-6/8] applied to suspend-2.6/linux-next
> 
> So you're going to merge this junk?
> 
> 

Yes. By now, everyone reading the posts should know all points.
Raffael obviously was part of this discussion and came to the decision
to merge it. 

My take of the discussion:
_IF_ you want to suspend aggressively, I don't see another
way.

The thing is, this is a paradigm change. Suspend is not anymore
controlled by userspace. In order to let userspace control/work with
this scheme, it needs to know when a suspend will be successfull or
poll:

1. kernel sees suspend may be possible on his side of things

2. kernel sends a message to userspace that i could be possibly
possible to suspend, but it may well be that by the time
userspace suspends it is not possible anymore

3. userspace decides to suspend. 

<- system suspends...  or not ..-> 

4. userspace retries ... retries ... retries ... 

And then you have the whole can of worms and races.



Or you have the suspend-blocker scheme:

1. kernel sees suspend is possible.
2. kernel suspends.
3. bingo.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> > This of course will lead to a scattering of suspend blockers into any
>> > drivers/subsystems considered "useful", which by looking through current
>> > Android kernels is many of them.
>>
>> That depends on the maintainers of these subsystems, who still have the power
>> to reject requested changes.
>
> So as a scheduler maintainer I'm going to merge a patch that does a
> suspend_blocker when the runqueue's aren't empty... how about that?
>

I don't know if you are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> > This of course will lead to a scattering of suspend blockers into any
>> > drivers/subsystems considered "useful", which by looking through current
>> > Android kernels is many of them.
>>
>> That depends on the maintainers of these subsystems, who still have the power
>> to reject requested changes.
>
> So as a scheduler maintainer I'm going to merge a patch that does a
> suspend_blocker when the runqueue's aren't empty... how about that?
>

I don't know if you are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> > This of course will lead to a scattering of suspend blockers into any
>> > drivers/subsystems considered "useful", which by looking through current
>> > Android kernels is many of them.
>>
>> That depends on the maintainers of these subsystems, who still have the power
>> to reject requested changes.
>
> So as a scheduler maintainer I'm going to merge a patch that does a
> suspend_blocker when the runqueue's aren't empty... how about that?
>

I don't know if you are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> >> > This of course will lead to a scattering of suspend blockers into any
> >> > drivers/subsystems considered "useful", which by looking through current
> >> > Android kernels is many of them.
> >>
> >> That depends on the maintainers of these subsystems, who still have the power
> >> to reject requested changes.
> >
> > So as a scheduler maintainer I'm going to merge a patch that does a
> > suspend_blocker when the runqueue's aren't empty... how about that?
> >
> 
> I don't know if you are serious, since the all the runqueues are never
> empty while suspending, this would disable opportunistic suspend
> altogether.

So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> >> > This of course will lead to a scattering of suspend blockers into any
> >> > drivers/subsystems considered "useful", which by looking through current
> >> > Android kernels is many of them.
> >>
> >> That depends on the maintainers of these subsystems, who still have the power
> >> to reject requested changes.
> >
> > So as a scheduler maintainer I'm going to merge a patch that does a
> > suspend_blocker when the runqueue's aren't empty... how about that?
> >
> 
> I don't know if you are serious, since the all the runqueues are never
> empty while suspending, this would disable opportunistic suspend
> altogether.

So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> >> > This of course will lead to a scattering of suspend blockers into any
> >> > drivers/subsystems considered "useful", which by looking through current
> >> > Android kernels is many of them.
> >>
> >> That depends on the maintainers of these subsystems, who still have the power
> >> to reject requested changes.
> >
> > So as a scheduler maintainer I'm going to merge a patch that does a
> > suspend_blocker when the runqueue's aren't empty... how about that?
> >
> 
> I don't know if you are serious, since the all the runqueues are never
> empty while suspending, this would disable opportunistic suspend
> altogether.

So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.


Thanks for your constructive feedback.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.


Thanks for your constructive feedback.

Brian
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 2:33 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:
>
>> There is polling, because the suspend manager in userspace doesn't have
>> the whole picture. i.e. it doesn't know if a suspend will be
>> successfull.
>> So for aggressive suspending as a powersave-feature you need to poll
>> (i.e. retry upon failure). because you don't want to stay unsuspended.
>
> Clearly if it fails, there something to be done, right? So whoever does
> the thing will communicate with the suspend manager that it's going to
> do and has finished doing its thing, at which point it will try again.
>

If you are talking about user-space code here, then that does not
work. Not all kernel events that need to block suspend make it to
user-space.

> That's event driven, not polled.
>
> Also, if you want you can keep the kernel-side auto-suspend side, and
> have the suspend manager clear on !0 and re-establish the auto-suspend
> state on 0.
>
> But you really don't need this device thingy.
>

I'm not sure what you are proposing that we use instead. Both
user-space and kernel code needs to block suspend. If we don't have
suspend blockers in the kernel then user-space needs to poll when a
driver blocks suspend by returning an error from its suspend hook.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 10:45:33 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> > > On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > > > This patch series adds a suspend-block api that provides the same
> > > > functionality as the android wakelock api. This version adds a
> > > > delay before suspending again if no suspend blockers were used
> > > > during the last suspend attempt.
> > > 
> > > Patches [1-6/8] applied to suspend-2.6/linux-next
> > 
> > So you're going to merge this junk?
> > 
> > 
> 
> Yes. By now, everyone reading the posts should know all points.
> Raffael obviously was part of this discussion and came to the decision
> to merge it. 
> 
> My take of the discussion:
> _IF_ you want to suspend aggressively, I don't see another
> way.
> 
> The thing is, this is a paradigm change. Suspend is not anymore
> controlled by userspace. In order to let userspace control/work with
> this scheme, it needs to know when a suspend will be successfull or
> poll:
> 
> 1. kernel sees suspend may be possible on his side of things
> 
> 2. kernel sends a message to userspace that i could be possibly
> possible to suspend, but it may well be that by the time
> userspace suspends it is not possible anymore
> 
> 3. userspace decides to suspend. 
> 
> <- system suspends...  or not ..-> 
> 
> 4. userspace retries ... retries ... retries ... 
> 
> And then you have the whole can of worms and races.

I don't see any races, nor retry loops.

There is always the race of an event arriving whilst in the process of
suspending, that is not solved by either the kernel nor user part of
suspend-blockers. The only thing is not to loose the event.

You simply have to deal with that, the suspend gets canceled, you do
deal with the event, and suspend again. How does making that 'retry' as
you call it happen from a kernel thread or from a userspace thread any
difference?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 10:45:33 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote:
> > > On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> > > > This patch series adds a suspend-block api that provides the same
> > > > functionality as the android wakelock api. This version adds a
> > > > delay before suspending again if no suspend blockers were used
> > > > during the last suspend attempt.
> > > 
> > > Patches [1-6/8] applied to suspend-2.6/linux-next
> > 
> > So you're going to merge this junk?
> > 
> > 
> 
> Yes. By now, everyone reading the posts should know all points.
> Raffael obviously was part of this discussion and came to the decision
> to merge it. 
> 
> My take of the discussion:
> _IF_ you want to suspend aggressively, I don't see another
> way.
> 
> The thing is, this is a paradigm change. Suspend is not anymore
> controlled by userspace. In order to let userspace control/work with
> this scheme, it needs to know when a suspend will be successfull or
> poll:
> 
> 1. kernel sees suspend may be possible on his side of things
> 
> 2. kernel sends a message to userspace that i could be possibly
> possible to suspend, but it may well be that by the time
> userspace suspends it is not possible anymore
> 
> 3. userspace decides to suspend. 
> 
> <- system suspends...  or not ..-> 
> 
> 4. userspace retries ... retries ... retries ... 
> 
> And then you have the whole can of worms and races.

I don't see any races, nor retry loops.

There is always the race of an event arriving whilst in the process of
suspending, that is not solved by either the kernel nor user part of
suspend-blockers. The only thing is not to loose the event.

You simply have to deal with that, the suspend gets canceled, you do
deal with the event, and suspend again. How does making that 'retry' as
you call it happen from a kernel thread or from a userspace thread any
difference?


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 2:33 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:
>
>> There is polling, because the suspend manager in userspace doesn't have
>> the whole picture. i.e. it doesn't know if a suspend will be
>> successfull.
>> So for aggressive suspending as a powersave-feature you need to poll
>> (i.e. retry upon failure). because you don't want to stay unsuspended.
>
> Clearly if it fails, there something to be done, right? So whoever does
> the thing will communicate with the suspend manager that it's going to
> do and has finished doing its thing, at which point it will try again.
>

If you are talking about user-space code here, then that does not
work. Not all kernel events that need to block suspend make it to
user-space.

> That's event driven, not polled.
>
> Also, if you want you can keep the kernel-side auto-suspend side, and
> have the suspend manager clear on !0 and re-establish the auto-suspend
> state on 0.
>
> But you really don't need this device thingy.
>

I'm not sure what you are proposing that we use instead. Both
user-space and kernel code needs to block suspend. If we don't have
suspend blockers in the kernel then user-space needs to poll when a
driver blocks suspend by returning an error from its suspend hook.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering of suspend blockers into any
> > >> > drivers/subsystems considered "useful", which by looking through current
> > >> > Android kernels is many of them.
> > >>
> > >> That depends on the maintainers of these subsystems, who still have the power
> > >> to reject requested changes.
> > >
> > > So as a scheduler maintainer I'm going to merge a patch that does a
> > > suspend_blocker when the runqueue's aren't empty... how about that?
> > >
> > 
> > I don't know if you are serious, since the all the runqueues are never
> > empty while suspending, this would disable opportunistic suspend
> > altogether.
> 
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.

Hi Peter!

This was already mentioned in one of these threads. 

The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.

So anything relying on (all) userspace solves a different problem.

Cheers,
Flo




> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering of suspend blockers into any
> > >> > drivers/subsystems considered "useful", which by looking through current
> > >> > Android kernels is many of them.
> > >>
> > >> That depends on the maintainers of these subsystems, who still have the power
> > >> to reject requested changes.
> > >
> > > So as a scheduler maintainer I'm going to merge a patch that does a
> > > suspend_blocker when the runqueue's aren't empty... how about that?
> > >
> > 
> > I don't know if you are serious, since the all the runqueues are never
> > empty while suspending, this would disable opportunistic suspend
> > altogether.
> 
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.

Hi Peter!

This was already mentioned in one of these threads. 

The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.

So anything relying on (all) userspace solves a different problem.

Cheers,
Flo




> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering of suspend blockers into any
> > >> > drivers/subsystems considered "useful", which by looking through current
> > >> > Android kernels is many of them.
> > >>
> > >> That depends on the maintainers of these subsystems, who still have the power
> > >> to reject requested changes.
> > >
> > > So as a scheduler maintainer I'm going to merge a patch that does a
> > > suspend_blocker when the runqueue's aren't empty... how about that?
> > >
> > 
> > I don't know if you are serious, since the all the runqueues are never
> > empty while suspending, this would disable opportunistic suspend
> > altogether.
> 
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.

Hi Peter!

This was already mentioned in one of these threads. 

The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.

So anything relying on (all) userspace solves a different problem.

Cheers,
Flo




> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.
>

I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.
>

I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:54 -0700, Arve Hjønnevåg wrote:
> 
> I'm not sure what you are proposing that we use instead. Both
> user-space and kernel code needs to block suspend. If we don't have
> suspend blockers in the kernel then user-space needs to poll when a
> driver blocks suspend by returning an error from its suspend hook. 

In particular I'm suggesting you ditch the /dev/suspend_block thing.

With a single suspend manager process that manages the suspend state you
can achieve the same goal.

When the suspend manager has a !0 busy-task count, it ensures the kernel
won't auto-suspend, when it again reaches a 0 busy-task count, it
re-instates the auto-suspend feature.

That's pretty much what that device would do too.

Ideally we would not do the auto-suspend thing at all and have
runtime-PM improved. Not running apps when they expect to run is like
the world turned upside down.

'Evil' apps could always report themselves as blocker anyway.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:54 -0700, Arve Hjønnevåg wrote:
> 
> I'm not sure what you are proposing that we use instead. Both
> user-space and kernel code needs to block suspend. If we don't have
> suspend blockers in the kernel then user-space needs to poll when a
> driver blocks suspend by returning an error from its suspend hook. 

In particular I'm suggesting you ditch the /dev/suspend_block thing.

With a single suspend manager process that manages the suspend state you
can achieve the same goal.

When the suspend manager has a !0 busy-task count, it ensures the kernel
won't auto-suspend, when it again reaches a 0 busy-task count, it
re-instates the auto-suspend feature.

That's pretty much what that device would do too.

Ideally we would not do the auto-suspend thing at all and have
runtime-PM improved. Not running apps when they expect to run is like
the world turned upside down.

'Evil' apps could always report themselves as blocker anyway.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.
> 
> So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.
> 
> So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:

> I was not talking about our user-space code. Suspend has to be called
> by a running thread, so at least one runqueue is not empty.

But why would you need to suspend if the machine is fully idle?

Is it because you're using broken hardware that has lower power
consumption in suspend state as in idle?

Couldn't you make the runtime-pm smarter and utilize the suspend states?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:

> I was not talking about our user-space code. Suspend has to be called
> by a running thread, so at least one runqueue is not empty.

But why would you need to suspend if the machine is fully idle?

Is it because you're using broken hardware that has lower power
consumption in suspend state as in idle?

Couldn't you make the runtime-pm smarter and utilize the suspend states?
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 02:54 -0700, Arve Hjønnevåg wrote:
>>
>> I'm not sure what you are proposing that we use instead. Both
>> user-space and kernel code needs to block suspend. If we don't have
>> suspend blockers in the kernel then user-space needs to poll when a
>> driver blocks suspend by returning an error from its suspend hook.
>
> In particular I'm suggesting you ditch the /dev/suspend_block thing.
>
> With a single suspend manager process that manages the suspend state you
> can achieve the same goal.
>

Yes we don't need the /dev interface, but it is useful. Without it any
program that needs to block suspend has to make a blocking ipc call
into the suspend manager process. Android already does this for java
code, but system processes written in C block suspend directly with
the kernel since they cannot use the java APIs.

> When the suspend manager has a !0 busy-task count, it ensures the kernel
> won't auto-suspend, when it again reaches a 0 busy-task count, it
> re-instates the auto-suspend feature.
>
> That's pretty much what that device would do too.
>
> Ideally we would not do the auto-suspend thing at all and have
> runtime-PM improved. Not running apps when they expect to run is like
> the world turned upside down.
>
> 'Evil' apps could always report themselves as blocker anyway.
>

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 02:54 -0700, Arve Hjønnevåg wrote:
>>
>> I'm not sure what you are proposing that we use instead. Both
>> user-space and kernel code needs to block suspend. If we don't have
>> suspend blockers in the kernel then user-space needs to poll when a
>> driver blocks suspend by returning an error from its suspend hook.
>
> In particular I'm suggesting you ditch the /dev/suspend_block thing.
>
> With a single suspend manager process that manages the suspend state you
> can achieve the same goal.
>

Yes we don't need the /dev interface, but it is useful. Without it any
program that needs to block suspend has to make a blocking ipc call
into the suspend manager process. Android already does this for java
code, but system processes written in C block suspend directly with
the kernel since they cannot use the java APIs.

> When the suspend manager has a !0 busy-task count, it ensures the kernel
> won't auto-suspend, when it again reaches a 0 busy-task count, it
> re-instates the auto-suspend feature.
>
> That's pretty much what that device would do too.
>
> Ideally we would not do the auto-suspend thing at all and have
> runtime-PM improved. Not running apps when they expect to run is like
> the world turned upside down.
>
> 'Evil' apps could always report themselves as blocker anyway.
>

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> > 
> > So anything relying on (all) userspace solves a different problem.
> 
> So what stops an application from grabbing a suspend blocker?

Well, I don't own any android devices, but  If I read this all
correctly, an app can request the permission to grab an suspend blocker
at installation time. ("This application is requesting permission to
keep the device from sleeping, thus possibly reducing your battery
time. Are you shure you want to continue? [Yes,No]")

every app grabbing a suspend blocker is showing
up in a "these programs stop suspend" kind of battery-app and are thus
well accounted for. _And the user knows who to blame_.

Maybe this is implemented via fs-permissions? Anyway, I'm shure,
that the access control uses a well established method. :)  

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> > 
> > So anything relying on (all) userspace solves a different problem.
> 
> So what stops an application from grabbing a suspend blocker?

Well, I don't own any android devices, but  If I read this all
correctly, an app can request the permission to grab an suspend blocker
at installation time. ("This application is requesting permission to
keep the device from sleeping, thus possibly reducing your battery
time. Are you shure you want to continue? [Yes,No]")

every app grabbing a suspend blocker is showing
up in a "these programs stop suspend" kind of battery-app and are thus
well accounted for. _And the user knows who to blame_.

Maybe this is implemented via fs-permissions? Anyway, I'm shure,
that the access control uses a well established method. :)  

Cheers,
Flo

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
> > With a single suspend manager process that manages the suspend state you
> > can achieve the same goal.
> >
> 
> Yes we don't need the /dev interface, but it is useful. Without it any
> program that needs to block suspend has to make a blocking ipc call
> into the suspend manager process. Android already does this for java
> code, but system processes written in C block suspend directly with
> the kernel since they cannot use the java APIs. 

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C
app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or
whatever.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
> > With a single suspend manager process that manages the suspend state you
> > can achieve the same goal.
> >
> 
> Yes we don't need the /dev interface, but it is useful. Without it any
> program that needs to block suspend has to make a blocking ipc call
> into the suspend manager process. Android already does this for java
> code, but system processes written in C block suspend directly with
> the kernel since they cannot use the java APIs. 

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C
app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or
whatever.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
>
>> I was not talking about our user-space code. Suspend has to be called
>> by a running thread, so at least one runqueue is not empty.
>
> But why would you need to suspend if the machine is fully idle?
>

I have never seen a system that is fully idle for hours or even minutes.

> Is it because you're using broken hardware that has lower power
> consumption in suspend state as in idle?
>

Initially, yes, but for shipping android phones, no.

> Couldn't you make the runtime-pm smarter and utilize the suspend states?
>

I don't think runtime-pm is relevant here. We don't use suspend to
power down devices that are not in use, we use suspend to enter system
power states that we cannot enter from idle, and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
>
>> I was not talking about our user-space code. Suspend has to be called
>> by a running thread, so at least one runqueue is not empty.
>
> But why would you need to suspend if the machine is fully idle?
>

I have never seen a system that is fully idle for hours or even minutes.

> Is it because you're using broken hardware that has lower power
> consumption in suspend state as in idle?
>

Initially, yes, but for shipping android phones, no.

> Couldn't you make the runtime-pm smarter and utilize the suspend states?
>

I don't think runtime-pm is relevant here. We don't use suspend to
power down devices that are not in use, we use suspend to enter system
power states that we cannot enter from idle, and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
>
>> I was not talking about our user-space code. Suspend has to be called
>> by a running thread, so at least one runqueue is not empty.
>
> But why would you need to suspend if the machine is fully idle?
>

I have never seen a system that is fully idle for hours or even minutes.

> Is it because you're using broken hardware that has lower power
> consumption in suspend state as in idle?
>

Initially, yes, but for shipping android phones, no.

> Couldn't you make the runtime-pm smarter and utilize the suspend states?
>

I don't think runtime-pm is relevant here. We don't use suspend to
power down devices that are not in use, we use suspend to enter system
power states that we cannot enter from idle, and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>> > With a single suspend manager process that manages the suspend state you
>> > can achieve the same goal.
>>
>> Yes we don't need the /dev interface, but it is useful. Without it any
>> program that needs to block suspend has to make a blocking ipc call
>> into the suspend manager process. Android already does this for java
>> code, but system processes written in C block suspend directly with
>> the kernel since they cannot use the java APIs.

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> So provide a C interface to it as well?
>
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

Yup, I don't quite get Arve's argument either. C code can interact
with Java code (and vice versa) just fine in userspace.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>> > With a single suspend manager process that manages the suspend state you
>> > can achieve the same goal.
>>
>> Yes we don't need the /dev interface, but it is useful. Without it any
>> program that needs to block suspend has to make a blocking ipc call
>> into the suspend manager process. Android already does this for java
>> code, but system processes written in C block suspend directly with
>> the kernel since they cannot use the java APIs.

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> So provide a C interface to it as well?
>
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

Yup, I don't quite get Arve's argument either. C code can interact
with Java code (and vice versa) just fine in userspace.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>> > With a single suspend manager process that manages the suspend state you
>> > can achieve the same goal.
>> >
>>
>> Yes we don't need the /dev interface, but it is useful. Without it any
>> program that needs to block suspend has to make a blocking ipc call
>> into the suspend manager process. Android already does this for java
>> code, but system processes written in C block suspend directly with
>> the kernel since they cannot use the java APIs.
>
> So provide a C interface to it as well?
>

We could, but the result would be that any program that needs to block
suspend has to be android specific.

> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.
>


-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>> > With a single suspend manager process that manages the suspend state you
>> > can achieve the same goal.
>> >
>>
>> Yes we don't need the /dev interface, but it is useful. Without it any
>> program that needs to block suspend has to make a blocking ipc call
>> into the suspend manager process. Android already does this for java
>> code, but system processes written in C block suspend directly with
>> the kernel since they cannot use the java APIs.
>
> So provide a C interface to it as well?
>

We could, but the result would be that any program that needs to block
suspend has to be android specific.

> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.
>


-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:

> and on systems where the
> same power state can be used from idle and suspend, we use suspend so
> we can stay in the low power state for minutes to hours instead of
> milliseconds to seconds.

So don't you think working on making it possible for systems to be idle
_that_ long would improve things for everybody? as opposed to this
auto-suspend which only improves matters for those that (can) use it?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:

> and on systems where the
> same power state can be used from idle and suspend, we use suspend so
> we can stay in the low power state for minutes to hours instead of
> milliseconds to seconds.

So don't you think working on making it possible for systems to be idle
_that_ long would improve things for everybody? as opposed to this
auto-suspend which only improves matters for those that (can) use it?


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

2010/5/26 Arve Hjønnevåg <arve@android.com>:
>> So provide a C interface to it as well?
>
> We could, but the result would be that any program that needs to block
> suspend has to be android specific.

Why? You could put the userspace daemon to tools/suspend-manager, for example?

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

2010/5/26 Arve Hjønnevåg <arve@android.com>:
>> So provide a C interface to it as well?
>
> We could, but the result would be that any program that needs to block
> suspend has to be android specific.

Why? You could put the userspace daemon to tools/suspend-manager, for example?

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

As we've stated a number of times in the several weeks of discussion
(this time around) of this patchset, we are all in favor of improving
runtime pm, finding and resolving issues that prevent idle, and
heading toward ever lower power states in idle -- after all, this
benefits our battery life in the cases when the system is not
suspended as well as moving us closer to a future where the power
savings between actively entering suspend and not doing so approach
zero.  Aggressively entering the lowest possible power state at all
times is our goal here.

At the moment, the power savings from opportunistic suspend do
directly lead to improved battery life, and there are some advantages
to this model in the face of a non-optimal userspace (as we encounter
in a world where there are not restrictions on what applications users
may install and run).

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

As we've stated a number of times in the several weeks of discussion
(this time around) of this patchset, we are all in favor of improving
runtime pm, finding and resolving issues that prevent idle, and
heading toward ever lower power states in idle -- after all, this
benefits our battery life in the cases when the system is not
suspended as well as moving us closer to a future where the power
savings between actively entering suspend and not doing so approach
zero.  Aggressively entering the lowest possible power state at all
times is our goal here.

At the moment, the power savings from opportunistic suspend do
directly lead to improved battery life, and there are some advantages
to this model in the face of a non-optimal userspace (as we encounter
in a world where there are not restrictions on what applications users
may install and run).

Brian
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

I'm not preventing anyone from working on improving this. Currently
both the kernel and our user-space code polls way too much. I don't
think it is reasonable to demand that no one should run any user-space
code with periodic timers when we have not even fixed the kernel to
not do this.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

I'm not preventing anyone from working on improving this. Currently
both the kernel and our user-space code polls way too much. I don't
think it is reasonable to demand that no one should run any user-space
code with periodic timers when we have not even fixed the kernel to
not do this.

-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
>> +To create a suspend blocker from user space, open the suspend_blocker
>> special
>> +device file:
>> +
>> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
>> +
>> +then optionally call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
>> +
>> +To activate the suspend blocker call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
>> +
>> +To deactivate it call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
>> +
>> +To destroy the suspend blocker, close the device:
>> +
>> +    close(fd);
>
> Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> the SET_NAME thing if you really care.
>

That would be very inefficient.

-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
>> +To create a suspend blocker from user space, open the suspend_blocker
>> special
>> +device file:
>> +
>> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
>> +
>> +then optionally call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
>> +
>> +To activate the suspend blocker call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
>> +
>> +To deactivate it call:
>> +
>> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
>> +
>> +To destroy the suspend blocker, close the device:
>> +
>> +    close(fd);
>
> Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> the SET_NAME thing if you really care.
>

That would be very inefficient.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >
> >> and on systems where the
> >> same power state can be used from idle and suspend, we use suspend so
> >> we can stay in the low power state for minutes to hours instead of
> >> milliseconds to seconds.
> >
> > So don't you think working on making it possible for systems to be idle
> > _that_ long would improve things for everybody? as opposed to this
> > auto-suspend which only improves matters for those that (can) use it?
> 
> I'm not preventing anyone from working on improving this. Currently
> both the kernel and our user-space code polls way too much. I don't
> think it is reasonable to demand that no one should run any user-space
> code with periodic timers when we have not even fixed the kernel to
> not do this.

All I'm saying is that merging a stop-gap measure will decrease the
urgency and thus the time spend fixing the actual issues while adding
the burden of maintaining this stop-gap measure.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >
> >> and on systems where the
> >> same power state can be used from idle and suspend, we use suspend so
> >> we can stay in the low power state for minutes to hours instead of
> >> milliseconds to seconds.
> >
> > So don't you think working on making it possible for systems to be idle
> > _that_ long would improve things for everybody? as opposed to this
> > auto-suspend which only improves matters for those that (can) use it?
> 
> I'm not preventing anyone from working on improving this. Currently
> both the kernel and our user-space code polls way too much. I don't
> think it is reasonable to demand that no one should run any user-space
> code with periodic timers when we have not even fixed the kernel to
> not do this.

All I'm saying is that merging a stop-gap measure will decrease the
urgency and thus the time spend fixing the actual issues while adding
the burden of maintaining this stop-gap measure.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >
> >> and on systems where the
> >> same power state can be used from idle and suspend, we use suspend so
> >> we can stay in the low power state for minutes to hours instead of
> >> milliseconds to seconds.
> >
> > So don't you think working on making it possible for systems to be idle
> > _that_ long would improve things for everybody? as opposed to this
> > auto-suspend which only improves matters for those that (can) use it?
> 
> I'm not preventing anyone from working on improving this. Currently
> both the kernel and our user-space code polls way too much. I don't
> think it is reasonable to demand that no one should run any user-space
> code with periodic timers when we have not even fixed the kernel to
> not do this.

All I'm saying is that merging a stop-gap measure will decrease the
urgency and thus the time spend fixing the actual issues while adding
the burden of maintaining this stop-gap measure.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:47 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> >> +To create a suspend blocker from user space, open the suspend_blocker
> >> special
> >> +device file:
> >> +
> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> >> +
> >> +then optionally call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> >> +
> >> +To activate the suspend blocker call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> >> +
> >> +To deactivate it call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> >> +
> >> +To destroy the suspend blocker, close the device:
> >> +
> >> +    close(fd);
> >
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> >
> 
> That would be very inefficient.

How so? Anyway, since you admitted this thing isn't needed at all, I say
we remove it altogether.

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:47 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> >> +To create a suspend blocker from user space, open the suspend_blocker
> >> special
> >> +device file:
> >> +
> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> >> +
> >> +then optionally call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> >> +
> >> +To activate the suspend blocker call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> >> +
> >> +To deactivate it call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> >> +
> >> +To destroy the suspend blocker, close the device:
> >> +
> >> +    close(fd);
> >
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> >
> 
> That would be very inefficient.

How so? Anyway, since you admitted this thing isn't needed at all, I say
we remove it altogether.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Florian Mickler]

On Wed, 26 May 2010 03:47:27 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> >> +To create a suspend blocker from user space, open the suspend_blocker
> >> special
> >> +device file:
> >> +
> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> >> +
> >> +then optionally call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> >> +
> >> +To activate the suspend blocker call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> >> +
> >> +To deactivate it call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> >> +
> >> +To destroy the suspend blocker, close the device:
> >> +
> >> +    close(fd);
> >
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> >
> 
> That would be very inefficient.
> 

Also I think it is intended to enforce named suspend blockers. (For
debugging/accounting purposes).

Cheers,
Flo

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Florian Mickler]

On Wed, 26 May 2010 03:47:27 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> >> +To create a suspend blocker from user space, open the suspend_blocker
> >> special
> >> +device file:
> >> +
> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> >> +
> >> +then optionally call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> >> +
> >> +To activate the suspend blocker call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> >> +
> >> +To deactivate it call:
> >> +
> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> >> +
> >> +To destroy the suspend blocker, close the device:
> >> +
> >> +    close(fd);
> >
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> >
> 
> That would be very inefficient.
> 

Also I think it is intended to enforce named suspend blockers. (For
debugging/accounting purposes).

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >
>> >> and on systems where the
>> >> same power state can be used from idle and suspend, we use suspend so
>> >> we can stay in the low power state for minutes to hours instead of
>> >> milliseconds to seconds.
>> >
>> > So don't you think working on making it possible for systems to be idle
>> > _that_ long would improve things for everybody? as opposed to this
>> > auto-suspend which only improves matters for those that (can) use it?
>>
>> I'm not preventing anyone from working on improving this. Currently
>> both the kernel and our user-space code polls way too much. I don't
>> think it is reasonable to demand that no one should run any user-space
>> code with periodic timers when we have not even fixed the kernel to
>> not do this.
>
> All I'm saying is that merging a stop-gap measure will decrease the
> urgency and thus the time spend fixing the actual issues while adding
> the burden of maintaining this stop-gap measure.
>

Fixing the actually issue means fixing all user-space code, and
replacing most x86 hardware. I don't think keeping this feature out of
the kernel will significantly accelerate this.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >
>> >> and on systems where the
>> >> same power state can be used from idle and suspend, we use suspend so
>> >> we can stay in the low power state for minutes to hours instead of
>> >> milliseconds to seconds.
>> >
>> > So don't you think working on making it possible for systems to be idle
>> > _that_ long would improve things for everybody? as opposed to this
>> > auto-suspend which only improves matters for those that (can) use it?
>>
>> I'm not preventing anyone from working on improving this. Currently
>> both the kernel and our user-space code polls way too much. I don't
>> think it is reasonable to demand that no one should run any user-space
>> code with periodic timers when we have not even fixed the kernel to
>> not do this.
>
> All I'm saying is that merging a stop-gap measure will decrease the
> urgency and thus the time spend fixing the actual issues while adding
> the burden of maintaining this stop-gap measure.
>

Fixing the actually issue means fixing all user-space code, and
replacing most x86 hardware. I don't think keeping this feature out of
the kernel will significantly accelerate this.

-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:51 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 03:47:27 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
> 
> > 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > >> +To create a suspend blocker from user space, open the suspend_blocker
> > >> special
> > >> +device file:
> > >> +
> > >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > >> +
> > >> +then optionally call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > >> +
> > >> +To activate the suspend blocker call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > >> +
> > >> +To deactivate it call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > >> +
> > >> +To destroy the suspend blocker, close the device:
> > >> +
> > >> +    close(fd);
> > >
> > > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > > the SET_NAME thing if you really care.
> > >
> > 
> > That would be very inefficient.
> > 
> 
> Also I think it is intended to enforce named suspend blockers. (For
> debugging/accounting purposes).

I don't think the code as proposed mandates you SET_NAME, and I didn't
propose killing that off, you can still SET_NAME after you open() and
acquire the thing.

Anyway, the whole point is moot since its simply not needed at all.

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:51 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 03:47:27 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
> 
> > 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > >> +To create a suspend blocker from user space, open the suspend_blocker
> > >> special
> > >> +device file:
> > >> +
> > >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > >> +
> > >> +then optionally call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > >> +
> > >> +To activate the suspend blocker call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > >> +
> > >> +To deactivate it call:
> > >> +
> > >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > >> +
> > >> +To destroy the suspend blocker, close the device:
> > >> +
> > >> +    close(fd);
> > >
> > > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > > the SET_NAME thing if you really care.
> > >
> > 
> > That would be very inefficient.
> > 
> 
> Also I think it is intended to enforce named suspend blockers. (For
> debugging/accounting purposes).

I don't think the code as proposed mandates you SET_NAME, and I didn't
propose killing that off, you can still SET_NAME after you open() and
acquire the thing.

Anyway, the whole point is moot since its simply not needed at all.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: 
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> >> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >> >
> >> >> and on systems where the
> >> >> same power state can be used from idle and suspend, we use suspend so
> >> >> we can stay in the low power state for minutes to hours instead of
> >> >> milliseconds to seconds.
> >> >
> >> > So don't you think working on making it possible for systems to be idle
> >> > _that_ long would improve things for everybody? as opposed to this
> >> > auto-suspend which only improves matters for those that (can) use it?
> >>
> >> I'm not preventing anyone from working on improving this. Currently
> >> both the kernel and our user-space code polls way too much. I don't
> >> think it is reasonable to demand that no one should run any user-space
> >> code with periodic timers when we have not even fixed the kernel to
> >> not do this.
> >
> > All I'm saying is that merging a stop-gap measure will decrease the
> > urgency and thus the time spend fixing the actual issues while adding
> > the burden of maintaining this stop-gap measure.
> >
> 
> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
near fast enough for this to be usable.

My laptop still takes several seconds to suspend (Lenovo T500), and
resume (aside from some userspace bustage) takes the same amount of
time. That is quick enough for manual suspend, but I'd hate it to try
and auto-suspend.

Getting longer idle periods however is something that everybody benefits
from. On x86 we're nowhere close to hitting the max idle time of the
platform, you get _tons_ of wakeups on current 'desktop' software.

But x86 being a PITA shouldn't stop people from working on this, there's
plenty other architectures out there, I remember fixing a NO_HZ bug with
davem on sparc64 because his niagra had cores idling for very long times
indeed. 

So yes, I do think merging this will delay the effort in fixing
userspace, simply because all the mobile/embedded folks don't care about
it anymore.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: 
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> >> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >> >
> >> >> and on systems where the
> >> >> same power state can be used from idle and suspend, we use suspend so
> >> >> we can stay in the low power state for minutes to hours instead of
> >> >> milliseconds to seconds.
> >> >
> >> > So don't you think working on making it possible for systems to be idle
> >> > _that_ long would improve things for everybody? as opposed to this
> >> > auto-suspend which only improves matters for those that (can) use it?
> >>
> >> I'm not preventing anyone from working on improving this. Currently
> >> both the kernel and our user-space code polls way too much. I don't
> >> think it is reasonable to demand that no one should run any user-space
> >> code with periodic timers when we have not even fixed the kernel to
> >> not do this.
> >
> > All I'm saying is that merging a stop-gap measure will decrease the
> > urgency and thus the time spend fixing the actual issues while adding
> > the burden of maintaining this stop-gap measure.
> >
> 
> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
near fast enough for this to be usable.

My laptop still takes several seconds to suspend (Lenovo T500), and
resume (aside from some userspace bustage) takes the same amount of
time. That is quick enough for manual suspend, but I'd hate it to try
and auto-suspend.

Getting longer idle periods however is something that everybody benefits
from. On x86 we're nowhere close to hitting the max idle time of the
platform, you get _tons_ of wakeups on current 'desktop' software.

But x86 being a PITA shouldn't stop people from working on this, there's
plenty other architectures out there, I remember fixing a NO_HZ bug with
davem on sparc64 because his niagra had cores idling for very long times
indeed. 

So yes, I do think merging this will delay the effort in fixing
userspace, simply because all the mobile/embedded folks don't care about
it anymore.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 1/8] PM: Opportunistic suspend support.

[Vitaly Wool]

2010/5/26 Arve Hjønnevåg <arve@android.com>:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>>> > With a single suspend manager process that manages the suspend state you
>>> > can achieve the same goal.
>>> >
>>>
>>> Yes we don't need the /dev interface, but it is useful. Without it any
>>> program that needs to block suspend has to make a blocking ipc call
>>> into the suspend manager process. Android already does this for java
>>> code, but system processes written in C block suspend directly with
>>> the kernel since they cannot use the java APIs.
>>
>> So provide a C interface to it as well?
>>
>
> We could, but the result would be that any program that needs to block
> suspend has to be android specific.

Just a suspicion, but... The things you're saying don't make sense to
me other than if you're fighting with GPL in userspace here.

~Vitaly

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Vitaly Wool]

2010/5/26 Arve Hjønnevåg <arve@android.com>:
> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>>> > With a single suspend manager process that manages the suspend state you
>>> > can achieve the same goal.
>>> >
>>>
>>> Yes we don't need the /dev interface, but it is useful. Without it any
>>> program that needs to block suspend has to make a blocking ipc call
>>> into the suspend manager process. Android already does this for java
>>> code, but system processes written in C block suspend directly with
>>> the kernel since they cannot use the java APIs.
>>
>> So provide a C interface to it as well?
>>
>
> We could, but the result would be that any program that needs to block
> suspend has to be android specific.

Just a suspicion, but... The things you're saying don't make sense to
me other than if you're fighting with GPL in userspace here.

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:

>> So why again was this such a great scheme? Go fix your userspace to not
>> not run when not needed.
>
> Hi Peter!
>
> This was already mentioned in one of these threads.
>
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.

I don't see this as a valid point. Everyone can run a different kernel
where nothing will just work. Are you aiming protection against that
as well?

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:

>> So why again was this such a great scheme? Go fix your userspace to not
>> not run when not needed.
>
> Hi Peter!
>
> This was already mentioned in one of these threads.
>
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.

I don't see this as a valid point. Everyone can run a different kernel
where nothing will just work. Are you aiming protection against that
as well?

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/26 Arve Hjønnevåg <arve@android.com>:

> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

But if this feature gets merged, I bet you'll find another 100 reasons
to not fix the actual issue. I wouldn't say so if you haven't provided
the irrelevant points already, like "replacing x86 hardware". You're
trying to merge the approach which makes the bad way of handing things
the easiest way. This shouldn't get in as it is IMO.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/26 Arve Hjønnevåg <arve@android.com>:

> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

But if this feature gets merged, I bet you'll find another 100 reasons
to not fix the actual issue. I wouldn't say so if you haven't provided
the irrelevant points already, like "replacing x86 hardware". You're
trying to merge the approach which makes the bad way of handing things
the easiest way. This shouldn't get in as it is IMO.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:54:37 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote:
> > _IF_ you want to suspend aggressively, I don't see another
> > way.
> > 
> > The thing is, this is a paradigm change. Suspend is not anymore
> > controlled by userspace. In order to let userspace control/work with
> > this scheme, it needs to know when a suspend will be successfull or
> > poll:
> > 
> > 1. kernel sees suspend may be possible on his side of things
> > 
> > 2. kernel sends a message to userspace that i could be possibly
> > possible to suspend, but it may well be that by the time
> > userspace suspends it is not possible anymore
> > 
> > 3. userspace decides to suspend. 
> > 
> > <- system suspends...  or not ..-> 
> > 
> > 4. userspace retries ... retries ... retries ... 
> > 
> > And then you have the whole can of worms and races.
> 
> I don't see any races, nor retry loops. 

What about the worms?  :)

I referred to retrying steps 1 through 3 as being the loop. 

> 
> There is always the race of an event arriving whilst in the process of
> suspending, that is not solved by either the kernel nor user part of
> suspend-blockers. The only thing is not to loose the event.
> 
> You simply have to deal with that, the suspend gets canceled, you do
> deal with the event, and suspend again. How does making that 'retry' as
> you call it happen from a kernel thread or from a userspace thread any
> difference?
> 
You have a point there. But what follows?

You either need to let userspace know that the kernel is now able to
suspend or you let the kernel know that userspace is now able to
suspend.
Else you can not make a well informed suspend-decision and have to
guess and retry.

Why not look at blocking and unblocking as these events you want
to have? Without wiggle room and retrying.

And not having to route through userspace simplifies the auto-suspend
scheme further.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:54:37 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote:
> > _IF_ you want to suspend aggressively, I don't see another
> > way.
> > 
> > The thing is, this is a paradigm change. Suspend is not anymore
> > controlled by userspace. In order to let userspace control/work with
> > this scheme, it needs to know when a suspend will be successfull or
> > poll:
> > 
> > 1. kernel sees suspend may be possible on his side of things
> > 
> > 2. kernel sends a message to userspace that i could be possibly
> > possible to suspend, but it may well be that by the time
> > userspace suspends it is not possible anymore
> > 
> > 3. userspace decides to suspend. 
> > 
> > <- system suspends...  or not ..-> 
> > 
> > 4. userspace retries ... retries ... retries ... 
> > 
> > And then you have the whole can of worms and races.
> 
> I don't see any races, nor retry loops. 

What about the worms?  :)

I referred to retrying steps 1 through 3 as being the loop. 

> 
> There is always the race of an event arriving whilst in the process of
> suspending, that is not solved by either the kernel nor user part of
> suspend-blockers. The only thing is not to loose the event.
> 
> You simply have to deal with that, the suspend gets canceled, you do
> deal with the event, and suspend again. How does making that 'retry' as
> you call it happen from a kernel thread or from a userspace thread any
> difference?
> 
You have a point there. But what follows?

You either need to let userspace know that the kernel is now able to
suspend or you let the kernel know that userspace is now able to
suspend.
Else you can not make a well informed suspend-decision and have to
guess and retry.

Why not look at blocking and unblocking as these events you want
to have? Without wiggle room and retrying.

And not having to route through userspace simplifies the auto-suspend
scheme further.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 13:18:51 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> >> So why again was this such a great scheme? Go fix your userspace to not
> >> not run when not needed.
> >
> > Hi Peter!
> >
> > This was already mentioned in one of these threads.
> >
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> 
> I don't see this as a valid point. Everyone can run a different kernel
> where nothing will just work. Are you aiming protection against that
> as well?
> 
> ~Vitaly

This is not "protection". This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 13:18:51 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> >> So why again was this such a great scheme? Go fix your userspace to not
> >> not run when not needed.
> >
> > Hi Peter!
> >
> > This was already mentioned in one of these threads.
> >
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> 
> I don't see this as a valid point. Everyone can run a different kernel
> where nothing will just work. Are you aiming protection against that
> as well?
> 
> ~Vitaly

This is not "protection". This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:

> This is not "protection". This is functioning properly in a real world
> scenario. Why would the user change the kernel, if the device would be
> buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down
his device and sucks the battery as a vampire (Except maybe he's a
moron)? ;)

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:

> This is not "protection". This is functioning properly in a real world
> scenario. Why would the user change the kernel, if the device would be
> buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down
his device and sucks the battery as a vampire (Except maybe he's a
moron)? ;)

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > This is not "protection". This is functioning properly in a real world
> > scenario. Why would the user change the kernel, if the device would be
> > buggy after that? (Except maybe he is a geek)
> 
> Hmm... Why would the user continue to use the program if it slows down
> his device and sucks the battery as a vampire (Except maybe he's a
> moron)? ;)
> 
> ~Vitaly

Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power? 

Most users don't even grasp the simple concept of different "programs".
They just have a device and click here and there and are happy. 

Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)

And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > This is not "protection". This is functioning properly in a real world
> > scenario. Why would the user change the kernel, if the device would be
> > buggy after that? (Except maybe he is a geek)
> 
> Hmm... Why would the user continue to use the program if it slows down
> his device and sucks the battery as a vampire (Except maybe he's a
> moron)? ;)
> 
> ~Vitaly

Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power? 

Most users don't even grasp the simple concept of different "programs".
They just have a device and click here and there and are happy. 

Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)

And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

hi,

On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
>And if you have two kernels, one with which your device is dead after 1
>hour and one with which your device is dead after 10 hours. Which would
>you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good 
power management even for badly written applications. They should work, 
of course, but there's no assumption that the kernel should cope with 
those applications and provide good battery usage on those cases.

You can install and run anything on the device, and they will work as 
they should (they will be scheduled and will be processed) but you can't 
expect the kernel to prevent that application from waking up the CPU 
every 10 ms simply because someone didn't think straight while writting 
the app.

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

hi,

On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
>And if you have two kernels, one with which your device is dead after 1
>hour and one with which your device is dead after 10 hours. Which would
>you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good 
power management even for badly written applications. They should work, 
of course, but there's no assumption that the kernel should cope with 
those applications and provide good battery usage on those cases.

You can install and run anything on the device, and they will work as 
they should (they will be scheduled and will be processed) but you can't 
expect the kernel to prevent that application from waking up the CPU 
every 10 ms simply because someone didn't think straight while writting 
the app.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> hi,
> 
> On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> >And if you have two kernels, one with which your device is dead after 1
> >hour and one with which your device is dead after 10 hours. Which would
> >you prefer? I mean really... this is ridiculous.
> 
> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.
> 
> You can install and run anything on the device, and they will work as 
> they should (they will be scheduled and will be processed) but you can't 
> expect the kernel to prevent that application from waking up the CPU 
> every 10 ms simply because someone didn't think straight while writting 
> the app.
> 

But then someone at the user side has to know what he is doing. 

I fear, if you target mass market without central distribution
channels, you can not assume that much.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> hi,
> 
> On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> >And if you have two kernels, one with which your device is dead after 1
> >hour and one with which your device is dead after 10 hours. Which would
> >you prefer? I mean really... this is ridiculous.
> 
> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.
> 
> You can install and run anything on the device, and they will work as 
> they should (they will be scheduled and will be processed) but you can't 
> expect the kernel to prevent that application from waking up the CPU 
> every 10 ms simply because someone didn't think straight while writting 
> the app.
> 

But then someone at the user side has to know what he is doing. 

I fear, if you target mass market without central distribution
channels, you can not assume that much.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

Yet...

> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.

This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS and platform people to improve their
bits of it.

> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.

The mobile space probably doesn't care too much about many of the large
bloated desktop apps anyway and traditional embedded generally has a very
small fixed application set where the optimise both halves of the system
together.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

Yet...

> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.

This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS and platform people to improve their
bits of it.

> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.

The mobile space probably doesn't care too much about many of the large
bloated desktop apps anyway and traditional embedded generally has a very
small fixed application set where the optimise both halves of the system
together.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
>But then someone at the user side has to know what he is doing.
>
>I fear, if you target mass market without central distribution
>channels, you can not assume that much.

and that's enough to push hacks into the kernel ? I don't think so. Do 
it like apple and prevent multi-tasking for any non-apple applications 
:-p

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
>But then someone at the user side has to know what he is doing.
>
>I fear, if you target mass market without central distribution
>channels, you can not assume that much.

and that's enough to push hacks into the kernel ? I don't think so. Do 
it like apple and prevent multi-tasking for any non-apple applications 
:-p

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 15:29:32 +0300
> Felipe Balbi <felipe.balbi@nokia.com> wrote:
> 
> > hi,
> > 
> > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > >And if you have two kernels, one with which your device is dead after 1
> > >hour and one with which your device is dead after 10 hours. Which would
> > >you prefer? I mean really... this is ridiculous.
> > 
> > What I find ridiculous is the assumption that kernel should provide good 
> > power management even for badly written applications. They should work, 
> > of course, but there's no assumption that the kernel should cope with 
> > those applications and provide good battery usage on those cases.
> > 
> > You can install and run anything on the device, and they will work as 
> > they should (they will be scheduled and will be processed) but you can't 
> > expect the kernel to prevent that application from waking up the CPU 
> > every 10 ms simply because someone didn't think straight while writting 
> > the app.
> > 
> 
> But then someone at the user side has to know what he is doing. 
> 
> I fear, if you target mass market without central distribution
> channels, you can not assume that much.

Provide the developers and users with tools. 

Notify the users that their phone is using power at an unadvised rate
due to proglet $foo.

Also, if you can integrate into the development environment and provide
developers instant feedback on suckage of their app they can react and
fix before letting users run into the issue.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 15:29:32 +0300
> Felipe Balbi <felipe.balbi@nokia.com> wrote:
> 
> > hi,
> > 
> > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > >And if you have two kernels, one with which your device is dead after 1
> > >hour and one with which your device is dead after 10 hours. Which would
> > >you prefer? I mean really... this is ridiculous.
> > 
> > What I find ridiculous is the assumption that kernel should provide good 
> > power management even for badly written applications. They should work, 
> > of course, but there's no assumption that the kernel should cope with 
> > those applications and provide good battery usage on those cases.
> > 
> > You can install and run anything on the device, and they will work as 
> > they should (they will be scheduled and will be processed) but you can't 
> > expect the kernel to prevent that application from waking up the CPU 
> > every 10 ms simply because someone didn't think straight while writting 
> > the app.
> > 
> 
> But then someone at the user side has to know what he is doing. 
> 
> I fear, if you target mass market without central distribution
> channels, you can not assume that much.

Provide the developers and users with tools. 

Notify the users that their phone is using power at an unadvised rate
due to proglet $foo.

Also, if you can integrate into the development environment and provide
developers instant feedback on suckage of their app they can react and
fix before letting users run into the issue.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Matthew Garrett]

While this approach could be made to work, it's ugly in other ways. 
After wakeup, userspace has to pause for a while before it can trigger 
another sleep in order to give all the apps an opportunity to check for 
wakeup events and block suspend if they wish to. That's additional 
runtime that doesn't exist in the kernel-mediated case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Matthew Garrett]

While this approach could be made to work, it's ugly in other ways. 
After wakeup, userspace has to pause for a while before it can trigger 
another sleep in order to give all the apps an opportunity to check for 
wakeup events and block suspend if they wish to. That's additional 
runtime that doesn't exist in the kernel-mediated case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:

> This is an area where machines are improving and where the ability to
> do stuff like autosuspend, the technology like the OLPC screen and so on
> create an incentive for the BIOS and platform people to improve their
> bits of it.

But do you think its a sensible thing to do? Explicitly not running
runnable tasks just sounds wrong. Also, at the extreme end, super fast
suspend is basically an efficient idle mode.

Why would the code holding suspend blockers be any more or less
important than any other piece of runnable code.

In fact, having runnable but non suspend blocking tasks around will
delay the completion of the suspend blocker, so will we start removing
those?

This whole thing introduces an artificial segregation of code. My 'cool'
code is more important than your 'uncool' code. Without a clear
definition of what makes code cool or not.

> > So yes, I do think merging this will delay the effort in fixing
> > userspace, simply because all the mobile/embedded folks don't care about
> > it anymore.
> 
> The mobile space probably doesn't care too much about many of the large
> bloated desktop apps anyway and traditional embedded generally has a very
> small fixed application set where the optimise both halves of the system
> together.

Sure, but at least we share the kernel. It was said that the kernel
generates too many wakeups (and iwlagn certainly is the top most waker
on my laptop). Improvements to the kernel will benefit all, regardless
of whatever userspace we run.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:

> This is an area where machines are improving and where the ability to
> do stuff like autosuspend, the technology like the OLPC screen and so on
> create an incentive for the BIOS and platform people to improve their
> bits of it.

But do you think its a sensible thing to do? Explicitly not running
runnable tasks just sounds wrong. Also, at the extreme end, super fast
suspend is basically an efficient idle mode.

Why would the code holding suspend blockers be any more or less
important than any other piece of runnable code.

In fact, having runnable but non suspend blocking tasks around will
delay the completion of the suspend blocker, so will we start removing
those?

This whole thing introduces an artificial segregation of code. My 'cool'
code is more important than your 'uncool' code. Without a clear
definition of what makes code cool or not.

> > So yes, I do think merging this will delay the effort in fixing
> > userspace, simply because all the mobile/embedded folks don't care about
> > it anymore.
> 
> The mobile space probably doesn't care too much about many of the large
> bloated desktop apps anyway and traditional embedded generally has a very
> small fixed application set where the optimise both halves of the system
> together.

Sure, but at least we share the kernel. It was said that the kernel
generates too many wakeups (and iwlagn certainly is the top most waker
on my laptop). Improvements to the kernel will benefit all, regardless
of whatever userspace we run.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> Hi,
> 
> On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
> >But then someone at the user side has to know what he is doing.
> >
> >I fear, if you target mass market without central distribution
> >channels, you can not assume that much.
> 
> and that's enough to push hacks into the kernel ? I don't think so. Do 
> it like apple and prevent multi-tasking for any non-apple applications 
> :-p
> 
:) 

It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other. So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So
you should be happy there. 

Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.

Also I expect there to be synergies between android development and
mainline kernel development _only_ if android development can use
mainline kernel.

And as for the quality of the "hack": I think you find this ugly, just
because you don't like the concept of degrading user space guaranties on
timers and stuff. 

But look at it this way: Suspend blockers are a way for the kernel
to make user space programs accountable for using the resource "power".
If a user space program needs the "traditional" guaranties for
functioning properly, it needs to take a suspend blocker. But _THEN_ it
better be well behaved. This is a kind of contract between userspace
and kernelspace.

On the other hand, if I don't need these traditional guaranties on
timers and stuff, I don't have to know device specific things about
power consumption. I can just use whatever facilities the programming
language provides without needing to worry about low level details.

This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like). 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> Hi,
> 
> On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
> >But then someone at the user side has to know what he is doing.
> >
> >I fear, if you target mass market without central distribution
> >channels, you can not assume that much.
> 
> and that's enough to push hacks into the kernel ? I don't think so. Do 
> it like apple and prevent multi-tasking for any non-apple applications 
> :-p
> 
:) 

It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other. So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So
you should be happy there. 

Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.

Also I expect there to be synergies between android development and
mainline kernel development _only_ if android development can use
mainline kernel.

And as for the quality of the "hack": I think you find this ugly, just
because you don't like the concept of degrading user space guaranties on
timers and stuff. 

But look at it this way: Suspend blockers are a way for the kernel
to make user space programs accountable for using the resource "power".
If a user space program needs the "traditional" guaranties for
functioning properly, it needs to take a suspend blocker. But _THEN_ it
better be well behaved. This is a kind of contract between userspace
and kernelspace.

On the other hand, if I don't need these traditional guaranties on
timers and stuff, I don't have to know device specific things about
power consumption. I can just use whatever facilities the programming
language provides without needing to worry about low level details.

This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like). 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
>
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a
production system. So do it here as well. Make sure the hack is well
isolated and local. You can even submit it to the mainline, better as
a configuration option, _unless_ it is a *framework* that provokes
writing code in an ugly and unsafe way.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
>
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a
production system. So do it here as well. Make sure the hack is well
isolated and local. You can even submit it to the mainline, better as
a configuration option, _unless_ it is a *framework* that provokes
writing code in an ugly and unsafe way.

~Vitaly

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 13:49 +0100, Matthew Garrett wrote:

Lack of quoting makes it hard to see what your 'this' refers to. I'll
assume its the userspace suspend manager.

> While this approach could be made to work, it's ugly in other ways. 
> After wakeup, userspace has to pause for a while before it can trigger 
> another sleep in order to give all the apps an opportunity to check for 
> wakeup events and block suspend if they wish to. That's additional 
> runtime that doesn't exist in the kernel-mediated case.

I fail to see why. In both cases the woken userspace will contact a
central governing task, either the kernel or the userspace suspend
manager, and inform it there is work to be done, and please don't
suspend now.

Also, since we did get woken, there clearly is work to do and we should
only try suspending again once someone did inform us of completing it.

In both cases, once the event is fully handled, will there be
communication of this fact and suspend can be attempted.

I don't see a reason to 'wait' for anything -- except maybe speculate on
the avgerage wakeup rate and decide not to suspend quite yet.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 13:49 +0100, Matthew Garrett wrote:

Lack of quoting makes it hard to see what your 'this' refers to. I'll
assume its the userspace suspend manager.

> While this approach could be made to work, it's ugly in other ways. 
> After wakeup, userspace has to pause for a while before it can trigger 
> another sleep in order to give all the apps an opportunity to check for 
> wakeup events and block suspend if they wish to. That's additional 
> runtime that doesn't exist in the kernel-mediated case.

I fail to see why. In both cases the woken userspace will contact a
central governing task, either the kernel or the userspace suspend
manager, and inform it there is work to be done, and please don't
suspend now.

Also, since we did get woken, there clearly is work to do and we should
only try suspending again once someone did inform us of completing it.

In both cases, once the event is fully handled, will there be
communication of this fact and suspend can be attempted.

I don't see a reason to 'wait' for anything -- except maybe speculate on
the avgerage wakeup rate and decide not to suspend quite yet.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 15:29:32 +0300
> > Felipe Balbi <felipe.balbi@nokia.com> wrote:
> > 
> > > hi,
> > > 
> > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > > >And if you have two kernels, one with which your device is dead after 1
> > > >hour and one with which your device is dead after 10 hours. Which would
> > > >you prefer? I mean really... this is ridiculous.
> > > 
> > > What I find ridiculous is the assumption that kernel should provide good 
> > > power management even for badly written applications. They should work, 
> > > of course, but there's no assumption that the kernel should cope with 
> > > those applications and provide good battery usage on those cases.
> > > 
> > > You can install and run anything on the device, and they will work as 
> > > they should (they will be scheduled and will be processed) but you can't 
> > > expect the kernel to prevent that application from waking up the CPU 
> > > every 10 ms simply because someone didn't think straight while writting 
> > > the app.
> > > 
> > 
> > But then someone at the user side has to know what he is doing. 
> > 
> > I fear, if you target mass market without central distribution
> > channels, you can not assume that much.
> 
> Provide the developers and users with tools. 
> 
> Notify the users that their phone is using power at an unadvised rate
> due to proglet $foo.
> 
> Also, if you can integrate into the development environment and provide
> developers instant feedback on suckage of their app they can react and
> fix before letting users run into the issue.
> 

Yeah. And I personally agree with you there. But this is a policy
decision that should not prevent android from doing it differently.
The kernel can not win if it does not try to integrate any use of it.
After all, we are a free comunity and if someone wants to use it their
way, why not allow for it? (As long as it does not directly impact other
uses)

The best solution wins, but not by decision of some kernel
development gatekeepers, but because it is superior. There are no clear
markings of the better solution. Time will tell.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 15:29:32 +0300
> > Felipe Balbi <felipe.balbi@nokia.com> wrote:
> > 
> > > hi,
> > > 
> > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > > >And if you have two kernels, one with which your device is dead after 1
> > > >hour and one with which your device is dead after 10 hours. Which would
> > > >you prefer? I mean really... this is ridiculous.
> > > 
> > > What I find ridiculous is the assumption that kernel should provide good 
> > > power management even for badly written applications. They should work, 
> > > of course, but there's no assumption that the kernel should cope with 
> > > those applications and provide good battery usage on those cases.
> > > 
> > > You can install and run anything on the device, and they will work as 
> > > they should (they will be scheduled and will be processed) but you can't 
> > > expect the kernel to prevent that application from waking up the CPU 
> > > every 10 ms simply because someone didn't think straight while writting 
> > > the app.
> > > 
> > 
> > But then someone at the user side has to know what he is doing. 
> > 
> > I fear, if you target mass market without central distribution
> > channels, you can not assume that much.
> 
> Provide the developers and users with tools. 
> 
> Notify the users that their phone is using power at an unadvised rate
> due to proglet $foo.
> 
> Also, if you can integrate into the development environment and provide
> developers instant feedback on suckage of their app they can react and
> fix before letting users run into the issue.
> 

Yeah. And I personally agree with you there. But this is a policy
decision that should not prevent android from doing it differently.
The kernel can not win if it does not try to integrate any use of it.
After all, we are a free comunity and if someone wants to use it their
way, why not allow for it? (As long as it does not directly impact other
uses)

The best solution wins, but not by decision of some kernel
development gatekeepers, but because it is superior. There are no clear
markings of the better solution. Time will tell.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:

> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other.

That's exactly what we always do. If we were not to do so, the kernel
would be a bloated incoherent piece of crap.

>  So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

I really think we should not do so. Let them help in fixing the real
issue instead of creating a new class of userspace that is more
important than another.

> But look at it this way: Suspend blockers are a way for the kernel
> to make user space programs accountable for using the resource "power".

How is userspace without suspend blockers not accountable? We can easily
account runtime and in fact have several ways to do so.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:

> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other.

That's exactly what we always do. If we were not to do so, the kernel
would be a bloated incoherent piece of crap.

>  So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

I really think we should not do so. Let them help in fixing the real
issue instead of creating a new class of userspace that is more
important than another.

> But look at it this way: Suspend blockers are a way for the kernel
> to make user space programs accountable for using the resource "power".

How is userspace without suspend blockers not accountable? We can easily
account runtime and in fact have several ways to do so.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away
screaming.

We most certainly do not want to integrate _any_ use.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away
screaming.

We most certainly do not want to integrate _any_ use.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

The problem you have is that this is policy. If I have the device wired
to a big screen and I want cows bouncing on it I'll be most upset if
instead it suspends. What you are essentially arguing for is for the
kernel to disobey the userspace. It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app
can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You
cannot solve a social problem with technology". In this case you have a
social/economic problem which is crap code. You solve it with an
economics solution - creative incentives not to produce crap code like
boxes that keep popping up saying "App XYZ is using all your battery" and
red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense
if you look at it from a different starting point. The starting point
being this: We have idling logic in the kernel and improving this helps
everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of
  suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is
  just a really deep idle in truth anyway) might break wakeups
  requirements because a device has wake dependencies due to hardware
  design (eg a port that has no electronics to kick the box out of
  suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the
phone runs the appstore code via something like

		setpidle(getpid(), something);
		exec()

where 'something' is a value with meaning to both user space and to the
existing idling logic in the kernel that basically says to what extent it
is permitted to block idling/suspend. That also seems to tie into some of
the realtime + idle problems. This I think deals with Kevin Hillman's
thoughts on dealing with untrustworthy app code more cleanly and avoids
the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in
their current situation they require that the power level doesn't drop
below some limit unless user requested. This is really important because
the platform vendor of the phone/pda/tablet whatever effectively owns the
kernel - so it's *their* problem, *their* control, *their* hardware and
they can make it work as best for the device. Best of all it means its
all free software stuff so if the vendor screws up you can still fix your
phone. 

Implementation-wise it probably ties into setpidle, its simply that a task
has a pair of idle values, a dynamic one and a base one, the dynamic one
being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. "Static" simply means it's not been made fast enough yet but
its just a policy divide dependant on the users 'acceptable' resume time
(which for hard RT may just as well rule out some more usual power states)

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

The problem you have is that this is policy. If I have the device wired
to a big screen and I want cows bouncing on it I'll be most upset if
instead it suspends. What you are essentially arguing for is for the
kernel to disobey the userspace. It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app
can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You
cannot solve a social problem with technology". In this case you have a
social/economic problem which is crap code. You solve it with an
economics solution - creative incentives not to produce crap code like
boxes that keep popping up saying "App XYZ is using all your battery" and
red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense
if you look at it from a different starting point. The starting point
being this: We have idling logic in the kernel and improving this helps
everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of
  suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is
  just a really deep idle in truth anyway) might break wakeups
  requirements because a device has wake dependencies due to hardware
  design (eg a port that has no electronics to kick the box out of
  suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the
phone runs the appstore code via something like

		setpidle(getpid(), something);
		exec()

where 'something' is a value with meaning to both user space and to the
existing idling logic in the kernel that basically says to what extent it
is permitted to block idling/suspend. That also seems to tie into some of
the realtime + idle problems. This I think deals with Kevin Hillman's
thoughts on dealing with untrustworthy app code more cleanly and avoids
the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in
their current situation they require that the power level doesn't drop
below some limit unless user requested. This is really important because
the platform vendor of the phone/pda/tablet whatever effectively owns the
kernel - so it's *their* problem, *their* control, *their* hardware and
they can make it work as best for the device. Best of all it means its
all free software stuff so if the vendor screws up you can still fix your
phone. 

Implementation-wise it probably ties into setpidle, its simply that a task
has a pair of idle values, a dynamic one and a base one, the dynamic one
being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. "Static" simply means it's not been made fast enough yet but
its just a policy divide dependant on the users 'acceptable' resume time
(which for hard RT may just as well rule out some more usual power states)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

That seems to me to be conflating models of behaviour and implementations.

> This is a _big_ plus for attracting 3rd party programs. (And of course
> the thing you don't like). 

You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

That seems to me to be conflating models of behaviour and implementations.

> This is a _big_ plus for attracting 3rd party programs. (And of course
> the thing you don't like). 

You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous.
> 
> You almost always need to "hack" the mainline software for a
> production system. So do it here as well. Make sure the hack is well
> isolated and local. You can even submit it to the mainline, better as
> a configuration option, _unless_ it is a *framework* that provokes
> writing code in an ugly and unsafe way.
> 
> ~Vitaly

I don't think that the in-kernel suspend block is a bad idea. 

You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
Regardless of opportunistic suspend or not. This way, you don't have to
try-and-fail on a suspend request and thus making suspending
potentially more robust or allowing for a "suspend as soon as
possible" semantic (which is probably a good idea, if you have to grab
your laptop in a hurry to get away).

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous.
> 
> You almost always need to "hack" the mainline software for a
> production system. So do it here as well. Make sure the hack is well
> isolated and local. You can even submit it to the mainline, better as
> a configuration option, _unless_ it is a *framework* that provokes
> writing code in an ugly and unsafe way.
> 
> ~Vitaly

I don't think that the in-kernel suspend block is a bad idea. 

You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
Regardless of opportunistic suspend or not. This way, you don't have to
try-and-fail on a suspend request and thus making suspending
potentially more robust or allowing for a "suspend as soon as
possible" semantic (which is probably a good idea, if you have to grab
your laptop in a hurry to get away).

Cheers,
Flo

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Matthew Garrett]

On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:

> I fail to see why. In both cases the woken userspace will contact a
> central governing task, either the kernel or the userspace suspend
> manager, and inform it there is work to be done, and please don't
> suspend now.

Thinking about this, you're right - we don't have to wait, but that does 
result in another problem. Imagine we get two wakeup events 
approximately simultaneously. In the kernel-level universe the kernel 
knows when both have been handled. In the user-level universe, we may 
have one task schedule, bump the count, handle the event, drop the count 
and then we attempt a suspend again because the second event handler 
hasn't had an opportunity to run yet. We'll then attempt a suspend and 
immediately bounce back up. That's kind of wasteful, although it'd be 
somewhat mitigated by checking that right at the top of suspend entry 
and returning -EAGAIN or similar.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Matthew Garrett]

On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:

> I fail to see why. In both cases the woken userspace will contact a
> central governing task, either the kernel or the userspace suspend
> manager, and inform it there is work to be done, and please don't
> suspend now.

Thinking about this, you're right - we don't have to wait, but that does 
result in another problem. Imagine we get two wakeup events 
approximately simultaneously. In the kernel-level universe the kernel 
knows when both have been handled. In the user-level universe, we may 
have one task schedule, bump the count, handle the event, drop the count 
and then we attempt a suspend again because the second event handler 
hasn't had an opportunity to run yet. We'll then attempt a suspend and 
immediately bounce back up. That's kind of wasteful, although it'd be 
somewhat mitigated by checking that right at the top of suspend entry 
and returning -EAGAIN or similar.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> > The kernel can not win if it does not try to integrate any use of it.
> 
> If we'd integrate every patch that came to lkml, you'd run away
> screaming.
> 
> We most certainly do not want to integrate _any_ use.

We most certainly do want to integrate any use that is not harmful to
others.

I don't buy the argument that this is harmful. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> > The kernel can not win if it does not try to integrate any use of it.
> 
> If we'd integrate every patch that came to lkml, you'd run away
> screaming.
> 
> We most certainly do not want to integrate _any_ use.

We most certainly do want to integrate any use that is not harmful to
others.

I don't buy the argument that this is harmful. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:19:42 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:


> > This is a _big_ plus for attracting 3rd party programs. (And of course
> > the thing you don't like). 
> 
> You would do better to concentrate on technical issues that the
> assignment of malicious intent to other parties.
> 
> Alan

This was nothing the kind of! He explicitly said this:

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.

And I responded that if the kernel would do this, then that would
be a "_big_ plus for attracting 3d party programs". 

I had no intent in attacking anyone or putting word's in someones mouth.
Sorry if this was unclearly written.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:19:42 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:


> > This is a _big_ plus for attracting 3rd party programs. (And of course
> > the thing you don't like). 
> 
> You would do better to concentrate on technical issues that the
> assignment of malicious intent to other parties.
> 
> Alan

This was nothing the kind of! He explicitly said this:

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.

And I responded that if the kernel would do this, then that would
be a "_big_ plus for attracting 3d party programs". 

I had no intent in attacking anyone or putting word's in someones mouth.
Sorry if this was unclearly written.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Alan,

On Wed, 26 May 2010, Alan Cox wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I completely agree. 

We have already proven that the social pressure on crappy applications
works. When NOHZ was merged into the kernel we got no effect at all
because a big percentage of user space applications just used timers
at will and without any thoughts, also it unveiled busy polling and
other horrible coding constructs. So what happened ? Arjan created
powertop which lets the user analyse the worst offenders in his
system. As a result the offending apps got fixed rapidly simply
because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can
influence the app writers simply by voting and setting up public lists
of apps which are crappy or excellent. All it needs is a nice powertop
tool for the phone which allows the users to identify the crap on
their phones. That provides much more incentive - especially for
commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
is just counter productive as it signals to the app provider: Go
ahead, keep on coding crap!

That's not a solution, that's just capitulation. 

It's absurd that some folks believe that giving up the most efficient
tool to apply pressure to crappy app providers is a good idea.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Alan,

On Wed, 26 May 2010, Alan Cox wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I completely agree. 

We have already proven that the social pressure on crappy applications
works. When NOHZ was merged into the kernel we got no effect at all
because a big percentage of user space applications just used timers
at will and without any thoughts, also it unveiled busy polling and
other horrible coding constructs. So what happened ? Arjan created
powertop which lets the user analyse the worst offenders in his
system. As a result the offending apps got fixed rapidly simply
because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can
influence the app writers simply by voting and setting up public lists
of apps which are crappy or excellent. All it needs is a nice powertop
tool for the phone which allows the users to identify the crap on
their phones. That provides much more incentive - especially for
commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
is just counter productive as it signals to the app provider: Go
ahead, keep on coding crap!

That's not a solution, that's just capitulation. 

It's absurd that some folks believe that giving up the most efficient
tool to apply pressure to crappy app providers is a good idea.

Thanks,

	tglx

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > How is that not polling? If the user is holding down a key, the keypad
> > driver has to block suspend, and user space will try to suspend again
> > and again and again...
> > 
> 
> If your userpsace is that stupid - sure. However, you can:
> 
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.
> 
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.

This is more complicated than necessary.  Arve is wrong; my suggested 
design does not require polling.

The reason is simple: When a user process initiates an opportunistic 
suspend, you make it wait in an interruptible sleep until all the 
kernel suspend blockers are released.  No polling.  If another user 
thread decides in the meantime that it needs to block the suspend, it 
sends a signal to the power manager process.

In fact, other threads should signal the power manager process whenever 
they want to block or unblock suspends.  That way the power manager 
process can spend all its time sleeping, without doing any polling.

> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.
> 
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.

That's not so easy.  The design of the PM core requires that when the 
system wakes up from suspend (or from an aborted suspend attempt), all 
devices should go to full-power-on.  This is explained in section 6 of
Documentation/power/runtime_pm.txt.

The decision over whether to use kernel-space suspend blockers vs. 
aborting suspends when queues are non-empty comes down to a tradeoff:

	Suspend blockers involve a little more code (to create,
	destroy, enable, and disable them) plus a little extra
	runtime overhead each time an event occurs.  (Some people
	may object to this extra overhead, although so far nobody
	in this discussion has done so.)

	Suspend blockers eliminate the extra overhead involved in
	starting suspends that are just going to be aborted.

	Suspend blockers offer extra debugging and accountability
	(the user can find out which subsystems are responsible for
	keeping the system awake).

Which way you think the tradeoff should go is a subjective decision.  I 
think that kernel suspend blockers are acceptable.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > How is that not polling? If the user is holding down a key, the keypad
> > driver has to block suspend, and user space will try to suspend again
> > and again and again...
> > 
> 
> If your userpsace is that stupid - sure. However, you can:
> 
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.
> 
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.

This is more complicated than necessary.  Arve is wrong; my suggested 
design does not require polling.

The reason is simple: When a user process initiates an opportunistic 
suspend, you make it wait in an interruptible sleep until all the 
kernel suspend blockers are released.  No polling.  If another user 
thread decides in the meantime that it needs to block the suspend, it 
sends a signal to the power manager process.

In fact, other threads should signal the power manager process whenever 
they want to block or unblock suspends.  That way the power manager 
process can spend all its time sleeping, without doing any polling.

> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.
> 
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.

That's not so easy.  The design of the PM core requires that when the 
system wakes up from suspend (or from an aborted suspend attempt), all 
devices should go to full-power-on.  This is explained in section 6 of
Documentation/power/runtime_pm.txt.

The decision over whether to use kernel-space suspend blockers vs. 
aborting suspends when queues are non-empty comes down to a tradeoff:

	Suspend blockers involve a little more code (to create,
	destroy, enable, and disable them) plus a little extra
	runtime overhead each time an event occurs.  (Some people
	may object to this extra overhead, although so far nobody
	in this discussion has done so.)

	Suspend blockers eliminate the extra overhead involved in
	starting suspends that are just going to be aborted.

	Suspend blockers offer extra debugging and accountability
	(the user can find out which subsystems are responsible for
	keeping the system awake).

Which way you think the tradeoff should go is a subjective decision.  I 
think that kernel suspend blockers are acceptable.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Wed, 26 May 2010, Florian Mickler wrote:

> I don't think that the in-kernel suspend block is a bad idea. 
> 
> You could probably use the suspend-blockers unconditionally in the
> suspend framework to indicate if a suspend is possible or not.

That's not how it works.  Drivers aren't supposed to abort
unconditional suspend -- not without a really good reason (for example,
the device received a wakeup event before it was fully suspended).  In
short, suspends should be considered to be _always_ possible.

> Regardless of opportunistic suspend or not. This way, you don't have to
> try-and-fail on a suspend request and thus making suspending
> potentially more robust or allowing for a "suspend as soon as
> possible" semantic (which is probably a good idea, if you have to grab
> your laptop in a hurry to get away).

That's different.  Suspend blockers could block (not abort!) regular 
suspends, just as they do opportunistic suspends.

But why should they?  I mean, if userspace wants to initiate a suspend
that is capable of being blocked by a kernel suspend blocker, then all
it has to do is initiate an opportunistic suspend instead of a normal
suspend.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Wed, 26 May 2010, Florian Mickler wrote:

> I don't think that the in-kernel suspend block is a bad idea. 
> 
> You could probably use the suspend-blockers unconditionally in the
> suspend framework to indicate if a suspend is possible or not.

That's not how it works.  Drivers aren't supposed to abort
unconditional suspend -- not without a really good reason (for example,
the device received a wakeup event before it was fully suspended).  In
short, suspends should be considered to be _always_ possible.

> Regardless of opportunistic suspend or not. This way, you don't have to
> try-and-fail on a suspend request and thus making suspending
> potentially more robust or allowing for a "suspend as soon as
> possible" semantic (which is probably a good idea, if you have to grab
> your laptop in a hurry to get away).

That's different.  Suspend blockers could block (not abort!) regular 
suspends, just as they do opportunistic suspends.

But why should they?  I mean, if userspace wants to initiate a suspend
that is capable of being blocked by a kernel suspend blocker, then all
it has to do is initiate an opportunistic suspend instead of a normal
suspend.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Wed, 26 May 2010, Florian Mickler wrote:

> I don't think that the in-kernel suspend block is a bad idea. 
> 
> You could probably use the suspend-blockers unconditionally in the
> suspend framework to indicate if a suspend is possible or not.

That's not how it works.  Drivers aren't supposed to abort
unconditional suspend -- not without a really good reason (for example,
the device received a wakeup event before it was fully suspended).  In
short, suspends should be considered to be _always_ possible.

> Regardless of opportunistic suspend or not. This way, you don't have to
> try-and-fail on a suspend request and thus making suspending
> potentially more robust or allowing for a "suspend as soon as
> possible" semantic (which is probably a good idea, if you have to grab
> your laptop in a hurry to get away).

That's different.  Suspend blockers could block (not abort!) regular 
suspends, just as they do opportunistic suspends.

But why should they?  I mean, if userspace wants to initiate a suspend
that is capable of being blocked by a kernel suspend blocker, then all
it has to do is initiate an opportunistic suspend instead of a normal
suspend.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:16:12 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.

<<If you want to use the rare resource "power" you have to take a
suspend blocker. By this you assert that you are a well written
application. If you are not well written, you will get the worst of our
red-amber-green powermeter scores we have.>>

On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel.
it is something new. Something which currently only the android
userspace implements / supports. If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do 

echo "opportunistic" > /sys/power/policy 

in the first place.

This "optionally being badly written, who cares?" is a new feature the
kernel can provide to applications. 

That said, your proposed alternative implementation scheme looks like
another possible approach.


> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
> 
> - You don't know which processes should be ignored for the purpose of
>   suspend (except for kernel threads) and there is no way to set this
> 
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>   just a really deep idle in truth anyway) might break wakeups
>   requirements because a device has wake dependencies due to hardware
>   design (eg a port that has no electronics to kick the box out of
>   suspend into running). This is a problem we have already. [1]
> 
> That maps onto two existing ideas
> 
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like
> 
> 		setpidle(getpid(), something);
> 		exec()
> 
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
> 
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone. 
> 
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
> 
> Alan

How does this address the loss of wakeup events while using suspend? 
(For example the 2 issues formulated by Alan Stern in [1])

cheers,
Flo

[1]http://lkml.org/lkml/2010/5/21/458

p.s.: 
dmk@schatten /usr/src/linux $ grep -r "setpidle" .
dmk@schatten /usr/src/linux $ 

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:16:12 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.

<<If you want to use the rare resource "power" you have to take a
suspend blocker. By this you assert that you are a well written
application. If you are not well written, you will get the worst of our
red-amber-green powermeter scores we have.>>

On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel.
it is something new. Something which currently only the android
userspace implements / supports. If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do 

echo "opportunistic" > /sys/power/policy 

in the first place.

This "optionally being badly written, who cares?" is a new feature the
kernel can provide to applications. 

That said, your proposed alternative implementation scheme looks like
another possible approach.


> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
> 
> - You don't know which processes should be ignored for the purpose of
>   suspend (except for kernel threads) and there is no way to set this
> 
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>   just a really deep idle in truth anyway) might break wakeups
>   requirements because a device has wake dependencies due to hardware
>   design (eg a port that has no electronics to kick the box out of
>   suspend into running). This is a problem we have already. [1]
> 
> That maps onto two existing ideas
> 
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like
> 
> 		setpidle(getpid(), something);
> 		exec()
> 
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
> 
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone. 
> 
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
> 
> Alan

How does this address the loss of wakeup events while using suspend? 
(For example the 2 issues formulated by Alan Stern in [1])

cheers,
Flo

[1]http://lkml.org/lkml/2010/5/21/458

p.s.: 
dmk@schatten /usr/src/linux $ grep -r "setpidle" .
dmk@schatten /usr/src/linux $ 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > Implementation-wise it probably ties into setpidle, its simply that a task
> > has a pair of idle values, a dynamic one and a base one, the dynamic one
> > being the base one but updatable temporarily by drivers.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

By not suspending obviously.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > Implementation-wise it probably ties into setpidle, its simply that a task
> > has a pair of idle values, a dynamic one and a base one, the dynamic one
> > being the base one but updatable temporarily by drivers.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

By not suspending obviously.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

That's backwards.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

That's backwards.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
How about we don't merge that junk and don't give you the opportunity to
do silly things like that? :-)

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
How about we don't merge that junk and don't give you the opportunity to
do silly things like that? :-)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)

Completely agree with this.

I used the static/dynamic names out of habit, but since on most
embedded devices, there is really no difference in hardware power
state, I agree that the difference is only a matter of wakeup latency.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)

Completely agree with this.

I used the static/dynamic names out of habit, but since on most
embedded devices, there is really no difference in hardware power
state, I agree that the difference is only a matter of wakeup latency.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
> > > Really, what are you getting at? Do you deny that there are programs,
> > > that prevent a device from sleeping? (Just think of the bouncing
> > > cows app)
> > > 
> > > And if you have two kernels, one with which your device is dead after 1
> > > hour and one with which your device is dead after 10 hours. Which would
> > > you prefer? I mean really... this is ridiculous. 
> > 
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends. What you are essentially arguing for is for the
> > kernel to disobey the userspace. It's as ridiculous (albeit usually less
> > damaging) as a file system saying "Ooh thats a rude file name, the app
> > can't have meant it, I'll put your document soemwhere else"
> > 
> > The whole API feels wrong to me. It's breaking rule #1 of technology "You
> > cannot solve a social problem with technology". In this case you have a
> > social/economic problem which is crap code. You solve it with an
> > economics solution - creative incentives not to produce crap code like
> > boxes that keep popping up saying "App XYZ is using all your battery" and
> > red-amber-green powermeter scores in app stores.
> 
> I completely agree. 
> 
> We have already proven that the social pressure on crappy applications
> works. When NOHZ was merged into the kernel we got no effect at all
> because a big percentage of user space applications just used timers
> at will and without any thoughts, also it unveiled busy polling and
> other horrible coding constructs. So what happened ? Arjan created
> powertop which lets the user analyse the worst offenders in his
> system. As a result the offending apps got fixed rapidly simply
> because no maintainer wanted to be on top of the powertop sh*tlist.
> 
> In the mobile app space it's basically the same problem. Users can
> influence the app writers simply by voting and setting up public lists
> of apps which are crappy or excellent. All it needs is a nice powertop
> tool for the phone which allows the users to identify the crap on
> their phones. That provides much more incentive - especially for
> commercial players - to fix their crappy code.
> 
> Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
> is just counter productive as it signals to the app provider: Go
> ahead, keep on coding crap!
> 
> That's not a solution, that's just capitulation. 
> 
> It's absurd that some folks believe that giving up the most efficient
> tool to apply pressure to crappy app providers is a good idea.

I couldn't agree more with both of you. I also have stated that a
powertop application with a fancy UI would do the job. Also building
some sort of power estimations on the SDK would allow the developer the
have fast feedback about potential power consumption caused by his app
on the device.

On top of that, the app stores can use the same power estimation
"technology" to rate apps automatically and even reject apps that are
waaaay too badly written.

I also feel that kernel shouldn't have to deal, fix, hide bad behavior
from apps.

-- 
balbi

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
> > > Really, what are you getting at? Do you deny that there are programs,
> > > that prevent a device from sleeping? (Just think of the bouncing
> > > cows app)
> > > 
> > > And if you have two kernels, one with which your device is dead after 1
> > > hour and one with which your device is dead after 10 hours. Which would
> > > you prefer? I mean really... this is ridiculous. 
> > 
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends. What you are essentially arguing for is for the
> > kernel to disobey the userspace. It's as ridiculous (albeit usually less
> > damaging) as a file system saying "Ooh thats a rude file name, the app
> > can't have meant it, I'll put your document soemwhere else"
> > 
> > The whole API feels wrong to me. It's breaking rule #1 of technology "You
> > cannot solve a social problem with technology". In this case you have a
> > social/economic problem which is crap code. You solve it with an
> > economics solution - creative incentives not to produce crap code like
> > boxes that keep popping up saying "App XYZ is using all your battery" and
> > red-amber-green powermeter scores in app stores.
> 
> I completely agree. 
> 
> We have already proven that the social pressure on crappy applications
> works. When NOHZ was merged into the kernel we got no effect at all
> because a big percentage of user space applications just used timers
> at will and without any thoughts, also it unveiled busy polling and
> other horrible coding constructs. So what happened ? Arjan created
> powertop which lets the user analyse the worst offenders in his
> system. As a result the offending apps got fixed rapidly simply
> because no maintainer wanted to be on top of the powertop sh*tlist.
> 
> In the mobile app space it's basically the same problem. Users can
> influence the app writers simply by voting and setting up public lists
> of apps which are crappy or excellent. All it needs is a nice powertop
> tool for the phone which allows the users to identify the crap on
> their phones. That provides much more incentive - especially for
> commercial players - to fix their crappy code.
> 
> Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
> is just counter productive as it signals to the app provider: Go
> ahead, keep on coding crap!
> 
> That's not a solution, that's just capitulation. 
> 
> It's absurd that some folks believe that giving up the most efficient
> tool to apply pressure to crappy app providers is a good idea.

I couldn't agree more with both of you. I also have stated that a
powertop application with a fancy UI would do the job. Also building
some sort of power estimations on the SDK would allow the developer the
have fast feedback about potential power consumption caused by his app
on the device.

On top of that, the app stores can use the same power estimation
"technology" to rate apps automatically and even reject apps that are
waaaay too badly written.

I also feel that kernel shouldn't have to deal, fix, hide bad behavior
from apps.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > I'm not saying that your argument is not valid. But why don't you look
> > at suspend blockers as a contract between userspace and kernelspace? An
> > Opt-In to the current guarantees the kernel provides in the non-suspend
> > case.
> 
> That's backwards.

I think that's the point of it. 

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > I'm not saying that your argument is not valid. But why don't you look
> > at suspend blockers as a contract between userspace and kernelspace? An
> > Opt-In to the current guarantees the kernel provides in the non-suspend
> > case.
> 
> That's backwards.

I think that's the point of it. 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 17:15:47 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > I'm not saying that your argument is not valid. But why don't you look
> > > at suspend blockers as a contract between userspace and kernelspace? An
> > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > case.
> > 
> > That's backwards.
> 
> I think that's the point of it. 

Apparently, and you're not accepting that we're telling you we think its
a singularly bad idea. Alan seems to have the skill to clearly explain
why, I suggest you re-read his emails again.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 17:15:47 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > I'm not saying that your argument is not valid. But why don't you look
> > > at suspend blockers as a contract between userspace and kernelspace? An
> > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > case.
> > 
> > That's backwards.
> 
> I think that's the point of it. 

Apparently, and you're not accepting that we're telling you we think its
a singularly bad idea. Alan seems to have the skill to clearly explain
why, I suggest you re-read his emails again.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

It is a contract - but not the right one. You are removing autonomy from
the kernel when only the kernel can measure the full picture and when the
kernel is actually supposed to be responsible for resource management.

> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.

Even the the model is wrong.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android

Disagree. It's an arbitary and misleading divide that happens to reflect
a specific vendors current phones. Worse yet it may not reflect their own
future products. It assumes for example that their is some power level
that is 'suspend' that is singular, application understood and can be
effectively user space managed. Big assumptions and not ones that seem to
be sensible.

It also breaks another rule - when the hardware changes your application
blocker policies will be wrong. Do you want multiple hand optimised
copies of each app ? Take a look at what happened to CPU designs where
the assumption was you'd recompile the app for each CPU version to get
any useful performance.

If you are instead expressing it as "must be able to respond in time X"
and "must be able to wake up from an event on an active device" then your
interface is generic and hardware independant.

If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the
kernel to decide how best to do that. It will vary by hardware. On todays
desktop PC thats probably a low power state limit. On some current
embedded hardware it might be a special deep sleep mode. On one or two
devices it might be 'suspend'. It might also be that the properties have
been set to 2 seconds already so it gets told it can't have 0.3.

The app cannot be allowed to know platform specific stuff or your
portability comes apart and you end up with a disaster area where each
app only comes on a subset of devices. Express the requirement right and
you get a simple clean interface that continues to work.

Express it wrong and you get a mess.

> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 

Thats a very big hammer and it doesn't express what I actually want,
which is to allow the cows to run as efficiently as possible.
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.

But you can do this properly by having a per process idle requirement,
and that can encompass things like hard real time as well (or even
gaming). The suspend blockers break all the global policy, don't solve
real time and don't allow for sensible expansion models. They don't solve
our existing wakeup versus device problems either.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

In this environment the problem cannot occur in the first place unless
there are kernel code bugs, if there are then they are in GPL code and can
be fixed. But you are mixing up interfaces and implementations which I
find is usually a bad idea. Doing the right thing badly gives you an
interface to an implementation you can later fix. Doing the wrong thing
well leaves you stuck down a hole.

> p.s.: 
> dmk@schatten /usr/src/linux $ grep -r "setpidle" .

Yes I know - no point having a new function which has an in use name is
there ? It's trivial to add per process idling or wakeup requirements.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

It is a contract - but not the right one. You are removing autonomy from
the kernel when only the kernel can measure the full picture and when the
kernel is actually supposed to be responsible for resource management.

> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.

Even the the model is wrong.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android

Disagree. It's an arbitary and misleading divide that happens to reflect
a specific vendors current phones. Worse yet it may not reflect their own
future products. It assumes for example that their is some power level
that is 'suspend' that is singular, application understood and can be
effectively user space managed. Big assumptions and not ones that seem to
be sensible.

It also breaks another rule - when the hardware changes your application
blocker policies will be wrong. Do you want multiple hand optimised
copies of each app ? Take a look at what happened to CPU designs where
the assumption was you'd recompile the app for each CPU version to get
any useful performance.

If you are instead expressing it as "must be able to respond in time X"
and "must be able to wake up from an event on an active device" then your
interface is generic and hardware independant.

If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the
kernel to decide how best to do that. It will vary by hardware. On todays
desktop PC thats probably a low power state limit. On some current
embedded hardware it might be a special deep sleep mode. On one or two
devices it might be 'suspend'. It might also be that the properties have
been set to 2 seconds already so it gets told it can't have 0.3.

The app cannot be allowed to know platform specific stuff or your
portability comes apart and you end up with a disaster area where each
app only comes on a subset of devices. Express the requirement right and
you get a simple clean interface that continues to work.

Express it wrong and you get a mess.

> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 

Thats a very big hammer and it doesn't express what I actually want,
which is to allow the cows to run as efficiently as possible.
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.

But you can do this properly by having a per process idle requirement,
and that can encompass things like hard real time as well (or even
gaming). The suspend blockers break all the global policy, don't solve
real time and don't allow for sensible expansion models. They don't solve
our existing wakeup versus device problems either.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

In this environment the problem cannot occur in the first place unless
there are kernel code bugs, if there are then they are in GPL code and can
be fixed. But you are mixing up interfaces and implementations which I
find is usually a bad idea. Doing the right thing badly gives you an
interface to an implementation you can later fix. Doing the wrong thing
well leaves you stuck down a hole.

> p.s.: 
> dmk@schatten /usr/src/linux $ grep -r "setpidle" .

Yes I know - no point having a new function which has an in use name is
there ? It's trivial to add per process idling or wakeup requirements.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 17:15:47 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > I'm not saying that your argument is not valid. But why don't you look
> > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > case.
> > > 
> > > That's backwards.
> > 
> > I think that's the point of it. 
> 
> Apparently, and you're not accepting that we're telling you we think its
> a singularly bad idea. Alan seems to have the skill to clearly explain
> why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they
have more content than yours. So it takes longer. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 17:15:47 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > I'm not saying that your argument is not valid. But why don't you look
> > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > case.
> > > 
> > > That's backwards.
> > 
> > I think that's the point of it. 
> 
> Apparently, and you're not accepting that we're telling you we think its
> a singularly bad idea. Alan seems to have the skill to clearly explain
> why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they
have more content than yours. So it takes longer. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Wed, 26 May 2010 17:45:00 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > > On Wed, 26 May 2010 17:15:47 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > > I'm not saying that your argument is not valid. But why don't you look
> > > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > > case.
> > > > 
> > > > That's backwards.
> > > 
> > > I think that's the point of it. 
> > 
> > Apparently, and you're not accepting that we're telling you we think its
> > a singularly bad idea. Alan seems to have the skill to clearly explain
> > why, I suggest you re-read his emails again.
> 
> I'm sorry if I offend you. I indeed read Alan's emails. It's just they
> have more content than yours. So it takes longer. 
> 
> Cheers,
> Flo

p.s.: also they encourage me to think more before answering. 

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Wed, 26 May 2010 17:45:00 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > > On Wed, 26 May 2010 17:15:47 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > > I'm not saying that your argument is not valid. But why don't you look
> > > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > > case.
> > > > 
> > > > That's backwards.
> > > 
> > > I think that's the point of it. 
> > 
> > Apparently, and you're not accepting that we're telling you we think its
> > a singularly bad idea. Alan seems to have the skill to clearly explain
> > why, I suggest you re-read his emails again.
> 
> I'm sorry if I offend you. I indeed read Alan's emails. It's just they
> have more content than yours. So it takes longer. 
> 
> Cheers,
> Flo

p.s.: also they encourage me to think more before answering. 

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
> Yup, I don't quite get Arve's argument either. C code can interact
> with Java code (and vice versa) just fine in userspace.

This is an incorrect statement.  It's possible for java to call C via
the JNI, even though there are quite a few gotchas that mean not just
*any* C code can do it (been there, tripped over some of them, although
they were all ultimately ironed out).  It's very difficult for C to call
directly into Java without being specially coded because it involves
creating and managing a JVM (so in general, arbitrary C code can't do
this).  The usual way we do C -> Java is process to process via some
intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
very messy for a mobile device.

On Wed, 2010-05-26 at 12:21 +0200, Peter Zijlstra wrote:
> So provide a C interface to it as well?

The way Android is currently coded, all user space suspend blocks are
handled in Java code at what's called the Frameworks layer (Frameworks
is the Java API for apps) this is also how the suspend permissions are
managed and presented to the user.  The few C applications which block
suspend just manipulate the device directly.

> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
> 
> Or make the suspend manager a C proglet and provide a JNI interface,
> or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't
think that's feasible on a reasonable timescale.  Android does have the
concept of special sockets that can be used to communicate from less to
more privileged processes (it has a very segmented runtime model), so
these might be usable ... they have a drawback that they're essentially
named pipes, so no multiplexing, but one per suspend influencing C
process shouldn't be a huge burden.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
> Yup, I don't quite get Arve's argument either. C code can interact
> with Java code (and vice versa) just fine in userspace.

This is an incorrect statement.  It's possible for java to call C via
the JNI, even though there are quite a few gotchas that mean not just
*any* C code can do it (been there, tripped over some of them, although
they were all ultimately ironed out).  It's very difficult for C to call
directly into Java without being specially coded because it involves
creating and managing a JVM (so in general, arbitrary C code can't do
this).  The usual way we do C -> Java is process to process via some
intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
very messy for a mobile device.

On Wed, 2010-05-26 at 12:21 +0200, Peter Zijlstra wrote:
> So provide a C interface to it as well?

The way Android is currently coded, all user space suspend blocks are
handled in Java code at what's called the Frameworks layer (Frameworks
is the Java API for apps) this is also how the suspend permissions are
managed and presented to the user.  The few C applications which block
suspend just manipulate the device directly.

> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
> 
> Or make the suspend manager a C proglet and provide a JNI interface,
> or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't
think that's feasible on a reasonable timescale.  Android does have the
concept of special sockets that can be used to communicate from less to
more privileged processes (it has a very segmented runtime model), so
these might be usable ... they have a drawback that they're essentially
named pipes, so no multiplexing, but one per suspend influencing C
process shouldn't be a huge burden.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > Or make the suspend manager a C proglet and provide a JNI interface,
> > or whatever.
> 
> It's a fairly large piece of code to try to rewrite in C, so I don't
> think that's feasible on a reasonable timescale.  Android does have the
> concept of special sockets that can be used to communicate from less to
> more privileged processes (it has a very segmented runtime model), so
> these might be usable ... they have a drawback that they're essentially
> named pipes, so no multiplexing, but one per suspend influencing C
> process shouldn't be a huge burden. 

It wouldn't need to convert the whole Frameworks layer into C, just
enough to manage the suspend state.

Anyway, I think there's been enough arguments against even the concept
of opportunistic/auto-suspend, and I for one will object with a NAK if
Rafael send this to Linus.

The whole idea of segregating userspace like that, and not letting
runnable thing run is very ill considered indeed.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > Or make the suspend manager a C proglet and provide a JNI interface,
> > or whatever.
> 
> It's a fairly large piece of code to try to rewrite in C, so I don't
> think that's feasible on a reasonable timescale.  Android does have the
> concept of special sockets that can be used to communicate from less to
> more privileged processes (it has a very segmented runtime model), so
> these might be usable ... they have a drawback that they're essentially
> named pipes, so no multiplexing, but one per suspend influencing C
> process shouldn't be a huge burden. 

It wouldn't need to convert the whole Frameworks layer into C, just
enough to manage the suspend state.

Anyway, I think there's been enough arguments against even the concept
of opportunistic/auto-suspend, and I for one will object with a NAK if
Rafael send this to Linus.

The whole idea of segregating userspace like that, and not letting
runnable thing run is very ill considered indeed.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

Peter Zijlstra <peterz@infradead.org> writes:

> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

It's already been submitted to Linus for 2.6.35, but not on LKML:

  https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025811.html

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Kevin Hilman]

Peter Zijlstra <peterz@infradead.org> writes:

> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

It's already been submitted to Linus for 2.6.35, but not on LKML:

  https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025811.html

Kevin

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 18:28 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > or whatever.
> > 
> > It's a fairly large piece of code to try to rewrite in C, so I don't
> > think that's feasible on a reasonable timescale.  Android does have the
> > concept of special sockets that can be used to communicate from less to
> > more privileged processes (it has a very segmented runtime model), so
> > these might be usable ... they have a drawback that they're essentially
> > named pipes, so no multiplexing, but one per suspend influencing C
> > process shouldn't be a huge burden. 
> 
> It wouldn't need to convert the whole Frameworks layer into C, just
> enough to manage the suspend state.

That's actually what I was saying ... converting the whole frameworks
would be impossible.  I'm saying the suspend state manager is still a
large piece of work.

> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

Well, I suppose that's your prerogative.

> The whole idea of segregating userspace like that, and not letting
> runnable thing run is very ill considered indeed.

OK, so this is an approach difference.  I see it as controlling an
application resource problem, which is similar to quotas on filesystems.
The opinion divide seems to come down to those who think the application
stack has to be fixed before a working device can be released, and those
who want to make the devices work now and supply pressure to fix the
applications as well.

I fail to see how, in an environment where the whole value of the device
is the third party supplied applications that the former view is
reasonable.  I equally fail to see how the latter is achievable without
segregating userspace into trusted and untrusted and taking action to
curb the power consumption of untrusted applications.

Given that I'm in the latter category, I think suspend blockers is a
reasonable solution to an existing problem.  I like Alan's idea of
restricting the API into a single user space program so we contain the
API contamination ... but realistically that's mostly the current
suspend blockers anyway.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 18:28 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > or whatever.
> > 
> > It's a fairly large piece of code to try to rewrite in C, so I don't
> > think that's feasible on a reasonable timescale.  Android does have the
> > concept of special sockets that can be used to communicate from less to
> > more privileged processes (it has a very segmented runtime model), so
> > these might be usable ... they have a drawback that they're essentially
> > named pipes, so no multiplexing, but one per suspend influencing C
> > process shouldn't be a huge burden. 
> 
> It wouldn't need to convert the whole Frameworks layer into C, just
> enough to manage the suspend state.

That's actually what I was saying ... converting the whole frameworks
would be impossible.  I'm saying the suspend state manager is still a
large piece of work.

> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

Well, I suppose that's your prerogative.

> The whole idea of segregating userspace like that, and not letting
> runnable thing run is very ill considered indeed.

OK, so this is an approach difference.  I see it as controlling an
application resource problem, which is similar to quotas on filesystems.
The opinion divide seems to come down to those who think the application
stack has to be fixed before a working device can be released, and those
who want to make the devices work now and supply pressure to fix the
applications as well.

I fail to see how, in an environment where the whole value of the device
is the third party supplied applications that the former view is
reasonable.  I equally fail to see how the latter is achievable without
segregating userspace into trusted and untrusted and taking action to
curb the power consumption of untrusted applications.

Given that I'm in the latter category, I think suspend blockers is a
reasonable solution to an existing problem.  I like Alan's idea of
restricting the API into a single user space program so we contain the
API contamination ... but realistically that's mostly the current
suspend blockers anyway.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > or whatever.
> > 
> > It's a fairly large piece of code to try to rewrite in C, so I don't
> > think that's feasible on a reasonable timescale.  Android does have the
> > concept of special sockets that can be used to communicate from less to
> > more privileged processes (it has a very segmented runtime model), so
> > these might be usable ... they have a drawback that they're essentially
> > named pipes, so no multiplexing, but one per suspend influencing C
> > process shouldn't be a huge burden. 
> 
> It wouldn't need to convert the whole Frameworks layer into C, just
> enough to manage the suspend state.
> 
> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't
currently see it in the archive.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > or whatever.
> > 
> > It's a fairly large piece of code to try to rewrite in C, so I don't
> > think that's feasible on a reasonable timescale.  Android does have the
> > concept of special sockets that can be used to communicate from less to
> > more privileged processes (it has a very segmented runtime model), so
> > these might be usable ... they have a drawback that they're essentially
> > named pipes, so no multiplexing, but one per suspend influencing C
> > process shouldn't be a huge burden. 
> 
> It wouldn't need to convert the whole Frameworks layer into C, just
> enough to manage the suspend state.
> 
> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't
currently see it in the archive.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> Given that I'm in the latter category, I think suspend blockers is a
> reasonable solution to an existing problem.  I like Alan's idea of
> restricting the API into a single user space program so we contain the
> API contamination ... but realistically that's mostly the current
> suspend blockers anyway. 

There's a _large_ difference between resource limits and these wonky
suspend blockers.

The main and most important one being that suspend is a global property
and can/will hurt sensible tasks. It puts the whole task model upside
down.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> Given that I'm in the latter category, I think suspend blockers is a
> reasonable solution to an existing problem.  I like Alan's idea of
> restricting the API into a single user space program so we contain the
> API contamination ... but realistically that's mostly the current
> suspend blockers anyway. 

There's a _large_ difference between resource limits and these wonky
suspend blockers.

The main and most important one being that suspend is a global property
and can/will hurt sensible tasks. It puts the whole task model upside
down.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > or whatever.
> > > 
> > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > think that's feasible on a reasonable timescale.  Android does have the
> > > concept of special sockets that can be used to communicate from less to
> > > more privileged processes (it has a very segmented runtime model), so
> > > these might be usable ... they have a drawback that they're essentially
> > > named pipes, so no multiplexing, but one per suspend influencing C
> > > process shouldn't be a huge burden. 
> > 
> > It wouldn't need to convert the whole Frameworks layer into C, just
> > enough to manage the suspend state.
> > 
> > Anyway, I think there's been enough arguments against even the concept
> > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > Rafael send this to Linus.
> 
> It was submitted already. I tried to followup with NAK, but can't
> currently see it in the archive.

It was apparently hidden on some funky list. Hiding pull requests is bad
enough, but hiding pull requests for contended features is just plain
wrong.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > or whatever.
> > > 
> > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > think that's feasible on a reasonable timescale.  Android does have the
> > > concept of special sockets that can be used to communicate from less to
> > > more privileged processes (it has a very segmented runtime model), so
> > > these might be usable ... they have a drawback that they're essentially
> > > named pipes, so no multiplexing, but one per suspend influencing C
> > > process shouldn't be a huge burden. 
> > 
> > It wouldn't need to convert the whole Frameworks layer into C, just
> > enough to manage the suspend state.
> > 
> > Anyway, I think there's been enough arguments against even the concept
> > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > Rafael send this to Linus.
> 
> It was submitted already. I tried to followup with NAK, but can't
> currently see it in the archive.

It was apparently hidden on some funky list. Hiding pull requests is bad
enough, but hiding pull requests for contended features is just plain
wrong.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > Given that I'm in the latter category, I think suspend blockers is a
> > reasonable solution to an existing problem.  I like Alan's idea of
> > restricting the API into a single user space program so we contain the
> > API contamination ... but realistically that's mostly the current
> > suspend blockers anyway. 
> 
> There's a _large_ difference between resource limits and these wonky
> suspend blockers.

Well, you have policy and then you have implementation ... suspend
blockers just looks like an implementation to me.  It seems to be
reasonably well suited in that regard ... after all, we kill processes
that exhaust memory for instance or cut off write privileges to those
that go over quota.  Preventing power hungry processes from consuming
power by not allowing them to run until there's a wakeup event is fairly
gentle by those standards.

> The main and most important one being that suspend is a global property
> and can/will hurt sensible tasks. It puts the whole task model upside
> down.

OK, so I believe you have an android phone ... it already implements
this model ... specifically what are the problems on that platform this
causes?

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > Given that I'm in the latter category, I think suspend blockers is a
> > reasonable solution to an existing problem.  I like Alan's idea of
> > restricting the API into a single user space program so we contain the
> > API contamination ... but realistically that's mostly the current
> > suspend blockers anyway. 
> 
> There's a _large_ difference between resource limits and these wonky
> suspend blockers.

Well, you have policy and then you have implementation ... suspend
blockers just looks like an implementation to me.  It seems to be
reasonably well suited in that regard ... after all, we kill processes
that exhaust memory for instance or cut off write privileges to those
that go over quota.  Preventing power hungry processes from consuming
power by not allowing them to run until there's a wakeup event is fairly
gentle by those standards.

> The main and most important one being that suspend is a global property
> and can/will hurt sensible tasks. It puts the whole task model upside
> down.

OK, so I believe you have an android phone ... it already implements
this model ... specifically what are the problems on that platform this
causes?

James

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Florian,

On Wed, 26 May 2010, Florian Mickler wrote:
>
> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.
> 
> This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to
express that in various ways already today. Admittedly it's far from
perfect, but that can be fixed by adding interfaces which allow the
power aware coder to express the requirements of his application
actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the
kernel which is stupid, as there are more options to efficiently save
power than those two. While current android devices might not provide
them, later hardware will have it and any atom based device has them
already.

So what the kernel needs to know to make better decisions are things
like:

  - how much slack can timers have (exisiting interface)
  - how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to
make better decisions versus power states, grouping timers, race to
idle and other things which influence the power consumption based on
the hardware you are running on.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android
> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.
> 
> This "optionally being badly written, who cares?" is a new feature the
> kernel can provide to applications. 

It's a misfeature which the kernel should not provide at all. It sends
out the completely wrong message: Hey, we can deal with your crappy
code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space,
it's completely backwards and will backfire in no time. 

The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Florian,

On Wed, 26 May 2010, Florian Mickler wrote:
>
> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.
> 
> This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to
express that in various ways already today. Admittedly it's far from
perfect, but that can be fixed by adding interfaces which allow the
power aware coder to express the requirements of his application
actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the
kernel which is stupid, as there are more options to efficiently save
power than those two. While current android devices might not provide
them, later hardware will have it and any atom based device has them
already.

So what the kernel needs to know to make better decisions are things
like:

  - how much slack can timers have (exisiting interface)
  - how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to
make better decisions versus power states, grouping timers, race to
idle and other things which influence the power consumption based on
the hardware you are running on.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android
> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.
> 
> This "optionally being badly written, who cares?" is a new feature the
> kernel can provide to applications. 

It's a misfeature which the kernel should not provide at all. It sends
out the completely wrong message: Hey, we can deal with your crappy
code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space,
it's completely backwards and will backfire in no time. 

The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.

Thanks,

	tglx

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:14 -0500, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > Given that I'm in the latter category, I think suspend blockers is a
> > > reasonable solution to an existing problem.  I like Alan's idea of
> > > restricting the API into a single user space program so we contain the
> > > API contamination ... but realistically that's mostly the current
> > > suspend blockers anyway. 
> > 
> > There's a _large_ difference between resource limits and these wonky
> > suspend blockers.
> 
> Well, you have policy and then you have implementation ... suspend
> blockers just looks like an implementation to me.  It seems to be
> reasonably well suited in that regard ... after all, we kill processes
> that exhaust memory for instance or cut off write privileges to those
> that go over quota.  Preventing power hungry processes from consuming
> power by not allowing them to run until there's a wakeup event is fairly
> gentle by those standards.

The difference is that the limit should be per task. In this model a
process that only runs a little still gets suspended.

> > The main and most important one being that suspend is a global property
> > and can/will hurt sensible tasks. It puts the whole task model upside
> > down.
> 
> OK, so I believe you have an android phone ... it already implements
> this model ... specifically what are the problems on that platform this
> causes?

I do not have one, nor have I ever written an application for it (nor
will I likely ever do that, since I detest Java), but I would expect an
application to run when its runnable.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:14 -0500, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > Given that I'm in the latter category, I think suspend blockers is a
> > > reasonable solution to an existing problem.  I like Alan's idea of
> > > restricting the API into a single user space program so we contain the
> > > API contamination ... but realistically that's mostly the current
> > > suspend blockers anyway. 
> > 
> > There's a _large_ difference between resource limits and these wonky
> > suspend blockers.
> 
> Well, you have policy and then you have implementation ... suspend
> blockers just looks like an implementation to me.  It seems to be
> reasonably well suited in that regard ... after all, we kill processes
> that exhaust memory for instance or cut off write privileges to those
> that go over quota.  Preventing power hungry processes from consuming
> power by not allowing them to run until there's a wakeup event is fairly
> gentle by those standards.

The difference is that the limit should be per task. In this model a
process that only runs a little still gets suspended.

> > The main and most important one being that suspend is a global property
> > and can/will hurt sensible tasks. It puts the whole task model upside
> > down.
> 
> OK, so I believe you have an android phone ... it already implements
> this model ... specifically what are the problems on that platform this
> causes?

I do not have one, nor have I ever written an application for it (nor
will I likely ever do that, since I detest Java), but I would expect an
application to run when its runnable.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > or whatever.
> > > > 
> > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > concept of special sockets that can be used to communicate from less to
> > > > more privileged processes (it has a very segmented runtime model), so
> > > > these might be usable ... they have a drawback that they're essentially
> > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > process shouldn't be a huge burden. 
> > > 
> > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > enough to manage the suspend state.
> > > 
> > > Anyway, I think there's been enough arguments against even the concept
> > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > Rafael send this to Linus.
> > 
> > It was submitted already. I tried to followup with NAK, but can't
> > currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

> It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the
height of obfuscation.  Plus almost everyone who objected was on the cc
list.

>  Hiding pull requests is bad enough, but hiding pull requests for
> contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure
for this subsystem.  I do think cc'ing lkml is good practise (having
been yelled at for not doing that in the past) but it's certainly not
universal practise.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > or whatever.
> > > > 
> > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > concept of special sockets that can be used to communicate from less to
> > > > more privileged processes (it has a very segmented runtime model), so
> > > > these might be usable ... they have a drawback that they're essentially
> > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > process shouldn't be a huge burden. 
> > > 
> > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > enough to manage the suspend state.
> > > 
> > > Anyway, I think there's been enough arguments against even the concept
> > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > Rafael send this to Linus.
> > 
> > It was submitted already. I tried to followup with NAK, but can't
> > currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

> It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the
height of obfuscation.  Plus almost everyone who objected was on the cc
list.

>  Hiding pull requests is bad enough, but hiding pull requests for
> contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure
for this subsystem.  I do think cc'ing lkml is good practise (having
been yelled at for not doing that in the past) but it's certainly not
universal practise.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

Hi James,

On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
>> Yup, I don't quite get Arve's argument either. C code can interact
>> with Java code (and vice versa) just fine in userspace.

On Wed, May 26, 2010 at 7:18 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
> This is an incorrect statement.  It's possible for java to call C via
> the JNI, even though there are quite a few gotchas that mean not just
> *any* C code can do it (been there, tripped over some of them, although
> they were all ultimately ironed out).  It's very difficult for C to call
> directly into Java without being specially coded because it involves
> creating and managing a JVM (so in general, arbitrary C code can't do
> this).  The usual way we do C -> Java is process to process via some
> intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
> very messy for a mobile device.

Incorrect statement how exactly? A JVM can do mmap(), for example,
just fine through FileChannel.map() so there's no need for
heavy-weight RPC. Furthermore, the whole discussion is moot anyway as
Android runs Dalvik which can be hacked to support whatever
communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is
hard" nonsense and concentrate on real issues?

                               Pekka

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

Hi James,

On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
>> Yup, I don't quite get Arve's argument either. C code can interact
>> with Java code (and vice versa) just fine in userspace.

On Wed, May 26, 2010 at 7:18 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
> This is an incorrect statement.  It's possible for java to call C via
> the JNI, even though there are quite a few gotchas that mean not just
> *any* C code can do it (been there, tripped over some of them, although
> they were all ultimately ironed out).  It's very difficult for C to call
> directly into Java without being specially coded because it involves
> creating and managing a JVM (so in general, arbitrary C code can't do
> this).  The usual way we do C -> Java is process to process via some
> intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
> very messy for a mobile device.

Incorrect statement how exactly? A JVM can do mmap(), for example,
just fine through FileChannel.map() so there's no need for
heavy-weight RPC. Furthermore, the whole discussion is moot anyway as
Android runs Dalvik which can be hacked to support whatever
communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is
hard" nonsense and concentrate on real issues?

                               Pekka

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

On Wed 2010-05-26 12:14:02, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > Given that I'm in the latter category, I think suspend blockers is a
> > > reasonable solution to an existing problem.  I like Alan's idea of
> > > restricting the API into a single user space program so we contain the
> > > API contamination ... but realistically that's mostly the current
> > > suspend blockers anyway. 
> > 
> > There's a _large_ difference between resource limits and these wonky
> > suspend blockers.
> 
> Well, you have policy and then you have implementation ... suspend
> blockers just looks like an implementation to me.  It seems to be
> reasonably well suited in that regard ... after all, we kill processes
> that exhaust memory for instance or cut off write privileges to those
> that go over quota.  Preventing power hungry processes from consuming
> power by not allowing them to run until there's a wakeup event is fairly
> gentle by those standards.

Well, generic mechanism would stop processes when they run over
something -- not arbitrarily link it to device wakeup.

> > The main and most important one being that suspend is a global property
> > and can/will hurt sensible tasks. It puts the whole task model upside
> > down.
> 
> OK, so I believe you have an android phone ... it already implements
> this model ... specifically what are the problems on that platform this
> causes?

Besides that it is not linux system at all?

Yes, with custom userspace it works extremely nicely.

Had anyone even tried running oportunistic suspend on normal desktop?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

On Wed 2010-05-26 12:14:02, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > Given that I'm in the latter category, I think suspend blockers is a
> > > reasonable solution to an existing problem.  I like Alan's idea of
> > > restricting the API into a single user space program so we contain the
> > > API contamination ... but realistically that's mostly the current
> > > suspend blockers anyway. 
> > 
> > There's a _large_ difference between resource limits and these wonky
> > suspend blockers.
> 
> Well, you have policy and then you have implementation ... suspend
> blockers just looks like an implementation to me.  It seems to be
> reasonably well suited in that regard ... after all, we kill processes
> that exhaust memory for instance or cut off write privileges to those
> that go over quota.  Preventing power hungry processes from consuming
> power by not allowing them to run until there's a wakeup event is fairly
> gentle by those standards.

Well, generic mechanism would stop processes when they run over
something -- not arbitrarily link it to device wakeup.

> > The main and most important one being that suspend is a global property
> > and can/will hurt sensible tasks. It puts the whole task model upside
> > down.
> 
> OK, so I believe you have an android phone ... it already implements
> this model ... specifically what are the problems on that platform this
> causes?

Besides that it is not linux system at all?

Yes, with custom userspace it works extremely nicely.

Had anyone even tried running oportunistic suspend on normal desktop?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:23 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 12:14 -0500, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > > Given that I'm in the latter category, I think suspend blockers is a
> > > > reasonable solution to an existing problem.  I like Alan's idea of
> > > > restricting the API into a single user space program so we contain the
> > > > API contamination ... but realistically that's mostly the current
> > > > suspend blockers anyway. 
> > > 
> > > There's a _large_ difference between resource limits and these wonky
> > > suspend blockers.
> > 
> > Well, you have policy and then you have implementation ... suspend
> > blockers just looks like an implementation to me.  It seems to be
> > reasonably well suited in that regard ... after all, we kill processes
> > that exhaust memory for instance or cut off write privileges to those
> > that go over quota.  Preventing power hungry processes from consuming
> > power by not allowing them to run until there's a wakeup event is fairly
> > gentle by those standards.
> 
> The difference is that the limit should be per task.

How?  You've got two different limits ... one the power the application
should be consuming when doing useful work for the user and the other is
the idle power.  A badly constructed app may only be bad on idle
power ... how is the scheduler going to detect this, exactly?  And what
do we do to applications we've detected are over consuming idle power?

>  In this model a
> process that only runs a little still gets suspended.

That's why I think it looks like a reasonable solution.  For this to
work, I agree you have to have all events the user is interested in wake
the system up ... but on most embedded platforms, they do.

> > > The main and most important one being that suspend is a global property
> > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > down.
> > 
> > OK, so I believe you have an android phone ... it already implements
> > this model ... specifically what are the problems on that platform this
> > causes?
> 
> I do not have one, nor have I ever written an application for it (nor
> will I likely ever do that, since I detest Java), but I would expect an
> application to run when its runnable.

OK, so I've got one ... tell me what I should see and I'll try to
reproduce.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:23 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 12:14 -0500, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > > > Given that I'm in the latter category, I think suspend blockers is a
> > > > reasonable solution to an existing problem.  I like Alan's idea of
> > > > restricting the API into a single user space program so we contain the
> > > > API contamination ... but realistically that's mostly the current
> > > > suspend blockers anyway. 
> > > 
> > > There's a _large_ difference between resource limits and these wonky
> > > suspend blockers.
> > 
> > Well, you have policy and then you have implementation ... suspend
> > blockers just looks like an implementation to me.  It seems to be
> > reasonably well suited in that regard ... after all, we kill processes
> > that exhaust memory for instance or cut off write privileges to those
> > that go over quota.  Preventing power hungry processes from consuming
> > power by not allowing them to run until there's a wakeup event is fairly
> > gentle by those standards.
> 
> The difference is that the limit should be per task.

How?  You've got two different limits ... one the power the application
should be consuming when doing useful work for the user and the other is
the idle power.  A badly constructed app may only be bad on idle
power ... how is the scheduler going to detect this, exactly?  And what
do we do to applications we've detected are over consuming idle power?

>  In this model a
> process that only runs a little still gets suspended.

That's why I think it looks like a reasonable solution.  For this to
work, I agree you have to have all events the user is interested in wake
the system up ... but on most embedded platforms, they do.

> > > The main and most important one being that suspend is a global property
> > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > down.
> > 
> > OK, so I believe you have an android phone ... it already implements
> > this model ... specifically what are the problems on that platform this
> > causes?
> 
> I do not have one, nor have I ever written an application for it (nor
> will I likely ever do that, since I detest Java), but I would expect an
> application to run when its runnable.

OK, so I've got one ... tell me what I should see and I'll try to
reproduce.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 20:25 +0300, Pekka Enberg wrote:
> Hi James,
> 
> On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
> >> Yup, I don't quite get Arve's argument either. C code can interact
> >> with Java code (and vice versa) just fine in userspace.
> 
> On Wed, May 26, 2010 at 7:18 PM, James Bottomley
> <James.Bottomley@suse.de> wrote:
> > This is an incorrect statement.  It's possible for java to call C via
> > the JNI, even though there are quite a few gotchas that mean not just
> > *any* C code can do it (been there, tripped over some of them, although
> > they were all ultimately ironed out).  It's very difficult for C to call
> > directly into Java without being specially coded because it involves
> > creating and managing a JVM (so in general, arbitrary C code can't do
> > this).  The usual way we do C -> Java is process to process via some
> > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
> > very messy for a mobile device.
> 
> Incorrect statement how exactly? A JVM can do mmap(), for example,
> just fine through FileChannel.map() so there's no need for
> heavy-weight RPC.

Incorrect in that an arbitrary C application can't link to a java API.
mmap and some other messaging (like signals) is just another form of
IPC ... the list I gave wasn't exhaustive.

>  Furthermore, the whole discussion is moot anyway as
> Android runs Dalvik which can be hacked to support whatever
> communication mechanism is the best choice here.
> 
> So can we drop the whole "we need to do it in kernel because Java is
> hard" nonsense and concentrate on real issues?

I've lost you.  This argument seems to hinge on whether or not you
believe that suspend in any form is a solution to the rogue app
problem ... whether it's implemented in Java or C is an ancillary issue.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 20:25 +0300, Pekka Enberg wrote:
> Hi James,
> 
> On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
> >> Yup, I don't quite get Arve's argument either. C code can interact
> >> with Java code (and vice versa) just fine in userspace.
> 
> On Wed, May 26, 2010 at 7:18 PM, James Bottomley
> <James.Bottomley@suse.de> wrote:
> > This is an incorrect statement.  It's possible for java to call C via
> > the JNI, even though there are quite a few gotchas that mean not just
> > *any* C code can do it (been there, tripped over some of them, although
> > they were all ultimately ironed out).  It's very difficult for C to call
> > directly into Java without being specially coded because it involves
> > creating and managing a JVM (so in general, arbitrary C code can't do
> > this).  The usual way we do C -> Java is process to process via some
> > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
> > very messy for a mobile device.
> 
> Incorrect statement how exactly? A JVM can do mmap(), for example,
> just fine through FileChannel.map() so there's no need for
> heavy-weight RPC.

Incorrect in that an arbitrary C application can't link to a java API.
mmap and some other messaging (like signals) is just another form of
IPC ... the list I gave wasn't exhaustive.

>  Furthermore, the whole discussion is moot anyway as
> Android runs Dalvik which can be hacked to support whatever
> communication mechanism is the best choice here.
> 
> So can we drop the whole "we need to do it in kernel because Java is
> hard" nonsense and concentrate on real issues?

I've lost you.  This argument seems to hinge on whether or not you
believe that suspend in any form is a solution to the rogue app
problem ... whether it's implemented in Java or C is an ancillary issue.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

Hi!

> > > > The main and most important one being that suspend is a global property
> > > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > > down.
> > > 
> > > OK, so I believe you have an android phone ... it already implements
> > > this model ... specifically what are the problems on that platform this
> > > causes?
> > 
> > I do not have one, nor have I ever written an application for it (nor
> > will I likely ever do that, since I detest Java), but I would expect an
> > application to run when its runnable.
> 
> OK, so I've got one ... tell me what I should see and I'll try to
> reproduce.

Umm... try to boot ordinary distro and see how it copes with
opportunistic suspend?

I do have android here, and of course it work well with custom
userland. Question is: can common distro be reasonably modified to
work with suspend blockers, in a way that's backward compatible?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

Hi!

> > > > The main and most important one being that suspend is a global property
> > > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > > down.
> > > 
> > > OK, so I believe you have an android phone ... it already implements
> > > this model ... specifically what are the problems on that platform this
> > > causes?
> > 
> > I do not have one, nor have I ever written an application for it (nor
> > will I likely ever do that, since I detest Java), but I would expect an
> > application to run when its runnable.
> 
> OK, so I've got one ... tell me what I should see and I'll try to
> reproduce.

Umm... try to boot ordinary distro and see how it copes with
opportunistic suspend?

I do have android here, and of course it work well with custom
userland. Question is: can common distro be reasonably modified to
work with suspend blockers, in a way that's backward compatible?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Thomas Gleixner]

On Wed, 26 May 2010, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > or whatever.
> > > > > 
> > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > concept of special sockets that can be used to communicate from less to
> > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > these might be usable ... they have a drawback that they're essentially
> > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > process shouldn't be a huge burden. 
> > > > 
> > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > enough to manage the suspend state.
> > > > 
> > > > Anyway, I think there's been enough arguments against even the concept
> > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > Rafael send this to Linus.
> > > 
> > > It was submitted already. I tried to followup with NAK, but can't
> > > currently see it in the archive.
> 
> You mean this one:
> 
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> 
> ?
> 
> > It was apparently hidden on some funky list.
> 
> Sending a PM pull request to the PM list doesn't really strike me as the
> height of obfuscation.  Plus almost everyone who objected was on the cc
> list.
> 
> >  Hiding pull requests is bad enough, but hiding pull requests for
> > contended features is just plain wrong.
> 
> I don't think it's a conspiracy ... just standard operating procedure
> for this subsystem.  I do think cc'ing lkml is good practise (having
> been yelled at for not doing that in the past) but it's certainly not
> universal practise.

At least it would be good style for a topic which is

   1) contended like this one

   2) pushing an intrusive feature last minute which has been merged
      into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user
space ABI in stone.

Thanks,

	tglx

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Thomas Gleixner]

On Wed, 26 May 2010, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > or whatever.
> > > > > 
> > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > concept of special sockets that can be used to communicate from less to
> > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > these might be usable ... they have a drawback that they're essentially
> > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > process shouldn't be a huge burden. 
> > > > 
> > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > enough to manage the suspend state.
> > > > 
> > > > Anyway, I think there's been enough arguments against even the concept
> > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > Rafael send this to Linus.
> > > 
> > > It was submitted already. I tried to followup with NAK, but can't
> > > currently see it in the archive.
> 
> You mean this one:
> 
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> 
> ?
> 
> > It was apparently hidden on some funky list.
> 
> Sending a PM pull request to the PM list doesn't really strike me as the
> height of obfuscation.  Plus almost everyone who objected was on the cc
> list.
> 
> >  Hiding pull requests is bad enough, but hiding pull requests for
> > contended features is just plain wrong.
> 
> I don't think it's a conspiracy ... just standard operating procedure
> for this subsystem.  I do think cc'ing lkml is good practise (having
> been yelled at for not doing that in the past) but it's certainly not
> universal practise.

At least it would be good style for a topic which is

   1) contended like this one

   2) pushing an intrusive feature last minute which has been merged
      into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user
space ABI in stone.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that
works and is used for everything else is resource management. Not giving
various tasks the ability to override rules, otherwise you end up needing
suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup
behaviour *subject to hard limits* (ie soft/hard process wakeup) works
both for the sane system where its elegantly managing hard RT, and for
the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
trick ?

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that
works and is used for everything else is resource management. Not giving
various tasks the ability to override rules, otherwise you end up needing
suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup
behaviour *subject to hard limits* (ie soft/hard process wakeup) works
both for the sane system where its elegantly managing hard RT, and for
the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
trick ?

Alan

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

On Wed, May 26, 2010 at 8:40 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
>> On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
>> >> Yup, I don't quite get Arve's argument either. C code can interact
>> >> with Java code (and vice versa) just fine in userspace.
>>
>> On Wed, May 26, 2010 at 7:18 PM, James Bottomley
>> <James.Bottomley@suse.de> wrote:
>> > This is an incorrect statement.  It's possible for java to call C via
>> > the JNI, even though there are quite a few gotchas that mean not just
>> > *any* C code can do it (been there, tripped over some of them, although
>> > they were all ultimately ironed out).  It's very difficult for C to call
>> > directly into Java without being specially coded because it involves
>> > creating and managing a JVM (so in general, arbitrary C code can't do
>> > this).  The usual way we do C -> Java is process to process via some
>> > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
>> > very messy for a mobile device.
>>
>> Incorrect statement how exactly? A JVM can do mmap(), for example,
>> just fine through FileChannel.map() so there's no need for
>> heavy-weight RPC.
>
> Incorrect in that an arbitrary C application can't link to a java API.

Dunno what you mean by "arbitrary" C application but yes, I do agree
that using JNI is somewhat cumbersome. Not sure if that's relevant,
though, as it can all be hidden in the framework APIs.

> mmap and some other messaging (like signals) is just another form of
> IPC ... the list I gave wasn't exhaustive.

The protocols you mentioned are meant for RPC (as in remote) and
messaging, not for IPC which I'm assume is needed for the suspend
manager process Peter is talking about.

>>  Furthermore, the whole discussion is moot anyway as
>> Android runs Dalvik which can be hacked to support whatever
>> communication mechanism is the best choice here.
>>
>> So can we drop the whole "we need to do it in kernel because Java is
>> hard" nonsense and concentrate on real issues?
>
> I've lost you.  This argument seems to hinge on whether or not you
> believe that suspend in any form is a solution to the rogue app
> problem ... whether it's implemented in Java or C is an ancillary issue.

I'm responding to the original argument from Arve that C programs
can't use the existing suspend manager because it's written in Java.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pekka Enberg]

On Wed, May 26, 2010 at 8:40 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
>> On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
>> >> Yup, I don't quite get Arve's argument either. C code can interact
>> >> with Java code (and vice versa) just fine in userspace.
>>
>> On Wed, May 26, 2010 at 7:18 PM, James Bottomley
>> <James.Bottomley@suse.de> wrote:
>> > This is an incorrect statement.  It's possible for java to call C via
>> > the JNI, even though there are quite a few gotchas that mean not just
>> > *any* C code can do it (been there, tripped over some of them, although
>> > they were all ultimately ironed out).  It's very difficult for C to call
>> > directly into Java without being specially coded because it involves
>> > creating and managing a JVM (so in general, arbitrary C code can't do
>> > this).  The usual way we do C -> Java is process to process via some
>> > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
>> > very messy for a mobile device.
>>
>> Incorrect statement how exactly? A JVM can do mmap(), for example,
>> just fine through FileChannel.map() so there's no need for
>> heavy-weight RPC.
>
> Incorrect in that an arbitrary C application can't link to a java API.

Dunno what you mean by "arbitrary" C application but yes, I do agree
that using JNI is somewhat cumbersome. Not sure if that's relevant,
though, as it can all be hidden in the framework APIs.

> mmap and some other messaging (like signals) is just another form of
> IPC ... the list I gave wasn't exhaustive.

The protocols you mentioned are meant for RPC (as in remote) and
messaging, not for IPC which I'm assume is needed for the suspend
manager process Peter is talking about.

>>  Furthermore, the whole discussion is moot anyway as
>> Android runs Dalvik which can be hacked to support whatever
>> communication mechanism is the best choice here.
>>
>> So can we drop the whole "we need to do it in kernel because Java is
>> hard" nonsense and concentrate on real issues?
>
> I've lost you.  This argument seems to hinge on whether or not you
> believe that suspend in any form is a solution to the rogue app
> problem ... whether it's implemented in Java or C is an ancillary issue.

I'm responding to the original argument from Arve that C programs
can't use the existing suspend manager because it's written in Java.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:42 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > The main and most important one being that suspend is a global property
> > > > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > > > down.
> > > > 
> > > > OK, so I believe you have an android phone ... it already implements
> > > > this model ... specifically what are the problems on that platform this
> > > > causes?
> > > 
> > > I do not have one, nor have I ever written an application for it (nor
> > > will I likely ever do that, since I detest Java), but I would expect an
> > > application to run when its runnable.
> > 
> > OK, so I've got one ... tell me what I should see and I'll try to
> > reproduce.
> 
> Umm... try to boot ordinary distro and see how it copes with
> opportunistic suspend?

That's not really going to help, is it?  The issue I was curious are
what are the bad things that result from interfering with the regular
scheduling of processes ... because undeniably suspend (whether
opportunistic or ordinary) does produce this interference.

I could boot debian on an android and have it suspend ... that's still
not going to answer my question.

> I do have android here, and of course it work well with custom
> userland. Question is: can common distro be reasonably modified to
> work with suspend blockers, in a way that's backward compatible?

You mean how an app could run if it was compiled with suspend blockers
but the platform doesn't support it?  That's a simple runtime switch in
the library surely?

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:42 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > The main and most important one being that suspend is a global property
> > > > > and can/will hurt sensible tasks. It puts the whole task model upside
> > > > > down.
> > > > 
> > > > OK, so I believe you have an android phone ... it already implements
> > > > this model ... specifically what are the problems on that platform this
> > > > causes?
> > > 
> > > I do not have one, nor have I ever written an application for it (nor
> > > will I likely ever do that, since I detest Java), but I would expect an
> > > application to run when its runnable.
> > 
> > OK, so I've got one ... tell me what I should see and I'll try to
> > reproduce.
> 
> Umm... try to boot ordinary distro and see how it copes with
> opportunistic suspend?

That's not really going to help, is it?  The issue I was curious are
what are the bad things that result from interfering with the regular
scheduling of processes ... because undeniably suspend (whether
opportunistic or ordinary) does produce this interference.

I could boot debian on an android and have it suspend ... that's still
not going to answer my question.

> I do have android here, and of course it work well with custom
> userland. Question is: can common distro be reasonably modified to
> work with suspend blockers, in a way that's backward compatible?

You mean how an app could run if it was compiled with suspend blockers
but the platform doesn't support it?  That's a simple runtime switch in
the library surely?

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> On Wed, 26 May 2010, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > > or whatever.
> > > > > > 
> > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > > concept of special sockets that can be used to communicate from less to
> > > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > > these might be usable ... they have a drawback that they're essentially
> > > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > > process shouldn't be a huge burden. 
> > > > > 
> > > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > > enough to manage the suspend state.
> > > > > 
> > > > > Anyway, I think there's been enough arguments against even the concept
> > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > > Rafael send this to Linus.
> > > > 
> > > > It was submitted already. I tried to followup with NAK, but can't
> > > > currently see it in the archive.
> > 
> > You mean this one:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> > 
> > ?
> > 
> > > It was apparently hidden on some funky list.
> > 
> > Sending a PM pull request to the PM list doesn't really strike me as the
> > height of obfuscation.  Plus almost everyone who objected was on the cc
> > list.
> > 
> > >  Hiding pull requests is bad enough, but hiding pull requests for
> > > contended features is just plain wrong.
> > 
> > I don't think it's a conspiracy ... just standard operating procedure
> > for this subsystem.  I do think cc'ing lkml is good practise (having
> > been yelled at for not doing that in the past) but it's certainly not
> > universal practise.
> 
> At least it would be good style for a topic which is
> 
>    1) contended like this one
> 
>    2) pushing an intrusive feature last minute which has been merged
>       into the pm tree barely two days ago.

Don't disagree ... I was just explaining how it could happen while not
being a conspiracy.

> Darn, _we_ have to deal with that forever as it sets a crappy user
> space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows
it to be disabled, so only platforms wishing to use it have to support
it.  Even on those platforms that do support it, we can translate most
of it into pm QoS stuff and if one day someone solves the rogue app
problem, we can migrate over.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> On Wed, 26 May 2010, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > > or whatever.
> > > > > > 
> > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > > concept of special sockets that can be used to communicate from less to
> > > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > > these might be usable ... they have a drawback that they're essentially
> > > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > > process shouldn't be a huge burden. 
> > > > > 
> > > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > > enough to manage the suspend state.
> > > > > 
> > > > > Anyway, I think there's been enough arguments against even the concept
> > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > > Rafael send this to Linus.
> > > > 
> > > > It was submitted already. I tried to followup with NAK, but can't
> > > > currently see it in the archive.
> > 
> > You mean this one:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> > 
> > ?
> > 
> > > It was apparently hidden on some funky list.
> > 
> > Sending a PM pull request to the PM list doesn't really strike me as the
> > height of obfuscation.  Plus almost everyone who objected was on the cc
> > list.
> > 
> > >  Hiding pull requests is bad enough, but hiding pull requests for
> > > contended features is just plain wrong.
> > 
> > I don't think it's a conspiracy ... just standard operating procedure
> > for this subsystem.  I do think cc'ing lkml is good practise (having
> > been yelled at for not doing that in the past) but it's certainly not
> > universal practise.
> 
> At least it would be good style for a topic which is
> 
>    1) contended like this one
> 
>    2) pushing an intrusive feature last minute which has been merged
>       into the pm tree barely two days ago.

Don't disagree ... I was just explaining how it could happen while not
being a conspiracy.

> Darn, _we_ have to deal with that forever as it sets a crappy user
> space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows
it to be disabled, so only platforms wishing to use it have to support
it.  Even on those platforms that do support it, we can translate most
of it into pm QoS stuff and if one day someone solves the rogue app
problem, we can migrate over.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Wed, 26 May 2010 13:23:00 CDT, James Bottomley said:
> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> > Darn, _we_ have to deal with that forever as it sets a crappy user
> > space ABI in stone.
> 
> I really don't see how it is ... the ABI comes with a switch that allows
> it to be disabled, so only platforms wishing to use it have to support
> it.  Even on those platforms that do support it, we can translate most
> of it into pm QoS stuff and if one day someone solves the rogue app
> problem, we can migrate over.

And yet, the OSS drivers are *still* in-tree, even though similar arguments
apply to an OSS->ALSA migration.  And there's a bunch of other stuff in
Documentation/feature-removal-schedule.txt in a similar situation.

Remember - programming is like sex. One poorly planned release and you're
stuck maintaining it for years. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 863 bytes --]

On Wed, 26 May 2010 13:23:00 CDT, James Bottomley said:
> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> > Darn, _we_ have to deal with that forever as it sets a crappy user
> > space ABI in stone.
> 
> I really don't see how it is ... the ABI comes with a switch that allows
> it to be disabled, so only platforms wishing to use it have to support
> it.  Even on those platforms that do support it, we can translate most
> of it into pm QoS stuff and if one day someone solves the rogue app
> problem, we can migrate over.

And yet, the OSS drivers are *still* in-tree, even though similar arguments
apply to an OSS->ALSA migration.  And there's a bunch of other stuff in
Documentation/feature-removal-schedule.txt in a similar situation.

Remember - programming is like sex. One poorly planned release and you're
stuck maintaining it for years. :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Florian Mickler]

On Wed, 26 May 2010 19:28:24 +0200
Pavel Machek <pavel@ucw.cz> wrote:


> Besides that it is not linux system at all?

I believe the kernel to be a layer between userspace and hardware. What
business is it to the kernel if it runs whatever android
uses as init process or /bin/bash, sys-v-init or systemd?

There is this thing called choice. 

> 
> Yes, with custom userspace it works extremely nicely.
> 
> Had anyone even tried running oportunistic suspend on normal desktop?
> 									Pavel

I don't think this is a valid concern. Just because current linux/gnu
systems don't implement the userspace part of this interface doesn't
mean it is useless or broken. 

Cheers,
Flo

-- 
Just because I argue an issue, doesn't mean I agree with either side of
it.

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Florian Mickler]

On Wed, 26 May 2010 19:28:24 +0200
Pavel Machek <pavel@ucw.cz> wrote:


> Besides that it is not linux system at all?

I believe the kernel to be a layer between userspace and hardware. What
business is it to the kernel if it runs whatever android
uses as init process or /bin/bash, sys-v-init or systemd?

There is this thing called choice. 

> 
> Yes, with custom userspace it works extremely nicely.
> 
> Had anyone even tried running oportunistic suspend on normal desktop?
> 									Pavel

I don't think this is a valid concern. Just because current linux/gnu
systems don't implement the userspace part of this interface doesn't
mean it is useless or broken. 

Cheers,
Flo

-- 
Just because I argue an issue, doesn't mean I agree with either side of
it.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> Florian,
> 
> On Wed, 26 May 2010, Florian Mickler wrote:
> >
> > On the other hand, applications can say, they don't need that much
> > power and userspace guaranties and not take a suspend blocker.
> > 
> > This is an option which they currently don't have.
> 
> Wrong. A well coded power aware application is very well able to
> express that in various ways already today. Admittedly it's far from
> perfect, but that can be fixed by adding interfaces which allow the
> power aware coder to express the requirements of his application
> actively, not by avoiding it.

Yeah, but a user can't say: "I don't
know programming, but I had this idea. Here try it out." 
to his friend. Because his friends phone then will crap out.

This is a negative. The phone just doesn't work well. 

A knowledgeable programmer is able to do extra work to enable specific
guarantees. A dummy-throw-away-programmer doesn't want to do
any extra work. 

> 
> suspend blockers are completely backwards as they basically disable
> the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it. 

> 
> Also they enforce a black and white scheme (suspend or run) on the
> kernel which is stupid, as there are more options to efficiently save
> power than those two. While current android devices might not provide
> them, later hardware will have it and any atom based device has them
> already.

This is true. Nonetheless, in my opinion, implementing the "backwards
approach" in any form (suspend blockers or some other sort of "sane"
interface) is necessary in the long run.  I also believe that Alan's
approach is the more flexible one. But I'm not in a position to judge
on this.

If it really is better and superior, I think userland will switch
over to it, as soon as it is possible to do it. The impact to the
drivers code is needed anyway. What looses the kernel by implementing
suspend blockers, and later a more finegrained approach and mapping the
userspace part of suspend blockers on that finegrained approach later
on?



> 
> So what the kernel needs to know to make better decisions are things
> like:
> 
>   - how much slack can timers have (exisiting interface)

I liked this idea of Arjan, to give some applications infinite timer
slack. But I don't know if it can made work in a "dummy proof" way.
(I.e. it is too complicated to get it right in general, except for the
"infinity" or not kind of tuning)

>   - how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most
applications. I see this as an orthogonal thing (i.e. not
affecting this merge). 

> 
> and probably some others. That information would allow the kernel to
> make better decisions versus power states, grouping timers, race to
> idle and other things which influence the power consumption based on
> the hardware you are running on.
> 
> > I don't think opportunistic suspend is a policy decision by the kernel.
> > it is something new. Something which currently only the android
> > userspace implements / supports. If you don't want to suspend while
> > looking at the bouncing-cow, you have to take a suspend blocker and
> > make yourself a user-visible power-eater, or don't do 
> > 
> > echo "opportunistic" > /sys/power/policy 
> > 
> > in the first place.
> > 
> > This "optionally being badly written, who cares?" is a new feature the
> > kernel can provide to applications. 
> 
> It's a misfeature which the kernel should not provide at all. It sends
> out the completely wrong message: Hey, we can deal with your crappy
> code, keep on coding that way.

I can't really say anything against that. Or anything in favor of it.  
Except that this is probably a really hard decision for Linus to
make. 

> 
> While this seems to sound cool to certain people in the mobile space,
> it's completely backwards and will backfire in no time. 

Maybe. It is something which seems to not come from the traditional
"linux distribution" model of software deployment, where you have a
party that codes and another party that packages that code. 

It instead is more targeted at the decentralised 3rd-party-app
approach under which windows is suffering.

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

True. But I wouldnt say, that it is the linux kernel who should force
this politics onto its users.

> 
> Thanks,
> 
> 	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> Florian,
> 
> On Wed, 26 May 2010, Florian Mickler wrote:
> >
> > On the other hand, applications can say, they don't need that much
> > power and userspace guaranties and not take a suspend blocker.
> > 
> > This is an option which they currently don't have.
> 
> Wrong. A well coded power aware application is very well able to
> express that in various ways already today. Admittedly it's far from
> perfect, but that can be fixed by adding interfaces which allow the
> power aware coder to express the requirements of his application
> actively, not by avoiding it.

Yeah, but a user can't say: "I don't
know programming, but I had this idea. Here try it out." 
to his friend. Because his friends phone then will crap out.

This is a negative. The phone just doesn't work well. 

A knowledgeable programmer is able to do extra work to enable specific
guarantees. A dummy-throw-away-programmer doesn't want to do
any extra work. 

> 
> suspend blockers are completely backwards as they basically disable
> the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it. 

> 
> Also they enforce a black and white scheme (suspend or run) on the
> kernel which is stupid, as there are more options to efficiently save
> power than those two. While current android devices might not provide
> them, later hardware will have it and any atom based device has them
> already.

This is true. Nonetheless, in my opinion, implementing the "backwards
approach" in any form (suspend blockers or some other sort of "sane"
interface) is necessary in the long run.  I also believe that Alan's
approach is the more flexible one. But I'm not in a position to judge
on this.

If it really is better and superior, I think userland will switch
over to it, as soon as it is possible to do it. The impact to the
drivers code is needed anyway. What looses the kernel by implementing
suspend blockers, and later a more finegrained approach and mapping the
userspace part of suspend blockers on that finegrained approach later
on?



> 
> So what the kernel needs to know to make better decisions are things
> like:
> 
>   - how much slack can timers have (exisiting interface)

I liked this idea of Arjan, to give some applications infinite timer
slack. But I don't know if it can made work in a "dummy proof" way.
(I.e. it is too complicated to get it right in general, except for the
"infinity" or not kind of tuning)

>   - how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most
applications. I see this as an orthogonal thing (i.e. not
affecting this merge). 

> 
> and probably some others. That information would allow the kernel to
> make better decisions versus power states, grouping timers, race to
> idle and other things which influence the power consumption based on
> the hardware you are running on.
> 
> > I don't think opportunistic suspend is a policy decision by the kernel.
> > it is something new. Something which currently only the android
> > userspace implements / supports. If you don't want to suspend while
> > looking at the bouncing-cow, you have to take a suspend blocker and
> > make yourself a user-visible power-eater, or don't do 
> > 
> > echo "opportunistic" > /sys/power/policy 
> > 
> > in the first place.
> > 
> > This "optionally being badly written, who cares?" is a new feature the
> > kernel can provide to applications. 
> 
> It's a misfeature which the kernel should not provide at all. It sends
> out the completely wrong message: Hey, we can deal with your crappy
> code, keep on coding that way.

I can't really say anything against that. Or anything in favor of it.  
Except that this is probably a really hard decision for Linus to
make. 

> 
> While this seems to sound cool to certain people in the mobile space,
> it's completely backwards and will backfire in no time. 

Maybe. It is something which seems to not come from the traditional
"linux distribution" model of software deployment, where you have a
party that codes and another party that packages that code. 

It instead is more targeted at the decentralised 3rd-party-app
approach under which windows is suffering.

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

True. But I wouldnt say, that it is the linux kernel who should force
this politics onto its users.

> 
> Thanks,
> 
> 	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:02:04 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> Even if you believe the kernel should be containing junk the model that
> works and is used for everything else is resource management. Not giving
> various tasks the ability to override rules, otherwise you end up needing
> suspend blocker blockers next week.
> 
> A model based on the idea that a task can set its desired wakeup
> behaviour *subject to hard limits* (ie soft/hard process wakeup) works
> both for the sane system where its elegantly managing hard RT, and for
> the crud where you sandbox it to stop it making a nasty mess.
> 
> Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
> trick ?
> 
> Alan

Your approach definitely sounds better than the current solution. 
What about mapping suspend blocker functionality later on, when this
interface exists, on to this new approach and deprecating it?

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:02:04 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> Even if you believe the kernel should be containing junk the model that
> works and is used for everything else is resource management. Not giving
> various tasks the ability to override rules, otherwise you end up needing
> suspend blocker blockers next week.
> 
> A model based on the idea that a task can set its desired wakeup
> behaviour *subject to hard limits* (ie soft/hard process wakeup) works
> both for the sane system where its elegantly managing hard RT, and for
> the crud where you sandbox it to stop it making a nasty mess.
> 
> Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
> trick ?
> 
> Alan

Your approach definitely sounds better than the current solution. 
What about mapping suspend blocker functionality later on, when this
interface exists, on to this new approach and deprecating it?

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:

> Your approach definitely sounds better than the current solution.
> What about mapping suspend blocker functionality later on, when this
> interface exists, on to this new approach and deprecating it?

What about coming back after some while with the appropriate solution
when it's ready instead of stubbornly pushing crap?

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:

> Your approach definitely sounds better than the current solution.
> What about mapping suspend blocker functionality later on, when this
> interface exists, on to this new approach and deprecating it?

What about coming back after some while with the appropriate solution
when it's ready instead of stubbornly pushing crap?

~Vitaly

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 14:50 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 26 May 2010 13:23:00 CDT, James Bottomley said:
> > On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> > > Darn, _we_ have to deal with that forever as it sets a crappy user
> > > space ABI in stone.
> > 
> > I really don't see how it is ... the ABI comes with a switch that allows
> > it to be disabled, so only platforms wishing to use it have to support
> > it.  Even on those platforms that do support it, we can translate most
> > of it into pm QoS stuff and if one day someone solves the rogue app
> > problem, we can migrate over.
> 
> And yet, the OSS drivers are *still* in-tree, even though similar arguments
> apply to an OSS->ALSA migration.  And there's a bunch of other stuff in
> Documentation/feature-removal-schedule.txt in a similar situation.

On the other hand APM, which is what all laptops used to use to suspend
is gone from the x86 kernel today ... replaced by ACPI or other platform
mechanisms, so it is at least possible.

James

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley]

On Wed, 2010-05-26 at 14:50 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 26 May 2010 13:23:00 CDT, James Bottomley said:
> > On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> > > Darn, _we_ have to deal with that forever as it sets a crappy user
> > > space ABI in stone.
> > 
> > I really don't see how it is ... the ABI comes with a switch that allows
> > it to be disabled, so only platforms wishing to use it have to support
> > it.  Even on those platforms that do support it, we can translate most
> > of it into pm QoS stuff and if one day someone solves the rogue app
> > problem, we can migrate over.
> 
> And yet, the OSS drivers are *still* in-tree, even though similar arguments
> apply to an OSS->ALSA migration.  And there's a bunch of other stuff in
> Documentation/feature-removal-schedule.txt in a similar situation.

On the other hand APM, which is what all laptops used to use to suspend
is gone from the x86 kernel today ... replaced by ACPI or other platform
mechanisms, so it is at least possible.

James

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
> > This is an area where machines are improving and where the ability to
> > do stuff like autosuspend, the technology like the OLPC screen and so on
> > create an incentive for the BIOS and platform people to improve their
> > bits of it.
> 
> But do you think its a sensible thing to do? Explicitly not running
> runnable tasks just sounds wrong. 
[...]
> Why would the code holding suspend blockers be any more or less
> important than any other piece of runnable code.

With my userspace developer hat on, I'd *kill* for a way to tell
the kernel that there are more important things for the system to
be doing than executing my runnable task.  In some cases, the set of
"more important things" the system might include running other tasks,
but it also might include conserving power.  I'd like to have my program
tell the kernel things like "wake me up in 0.1 seconds, plus or minus
a year if you have something better to do."

With my sysadmin hat on (which is nearly identical to my phone owner hat,
BTW), I'd like whatever syscall implements those features to take a PID
argument, so I can impose my importance decisions on other processes.
I'd also like to set the relative importance of keeping the CPU idle on
the same scale, so that I could raise or lower the importance of keeping
the CPU idle as power availability changes.

> This whole thing introduces an artificial segregation of code. My 'cool'
> code is more important than your 'uncool' code. Without a clear
> definition of what makes code cool or not.

It's impossible in the general case for an application to know whether
it's important or not, so it's also impossible for the kernel to derive
this information from the application's behavior--and impossible, in the
general case, to decide whether the application is more important than the
battery or some other scarce resource the kernel might also be managing
(e.g. if the machine is running hot, heat dissipation might be scarce,
and we'd want to be idle then too).  This is similar to niceness and
SCHED_RR/FIFO:  there's no way for the kernel to automatically assign
those values either, they have to be specified by a user or administrator.
Of course, programs are free--within limits--to specify these values
about themselves.

Consider a traditional Unix program like "sort".  Seriously, how is "sort"
supposed to know that it's the most important application on the system
(because I need my contacts list alphabetized *now*), or the least
(because the screensaver needs to know which is the oldest graphics
hack in the list)?

"sort" gets invoked from a shell, cooperating with other processes to do
its work.  It knows very little about the context in which it is executing
(nor should it).  Should "sort" sprout command-line arguments for every
possible scheduling latency and power management policy option, or should
"sort" not care, and defer such decisions to other command-line
tools which set these options before exec()ing "sort", or to a management
utility like "top" that implements policy across the entire system?

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
> > This is an area where machines are improving and where the ability to
> > do stuff like autosuspend, the technology like the OLPC screen and so on
> > create an incentive for the BIOS and platform people to improve their
> > bits of it.
> 
> But do you think its a sensible thing to do? Explicitly not running
> runnable tasks just sounds wrong. 
[...]
> Why would the code holding suspend blockers be any more or less
> important than any other piece of runnable code.

With my userspace developer hat on, I'd *kill* for a way to tell
the kernel that there are more important things for the system to
be doing than executing my runnable task.  In some cases, the set of
"more important things" the system might include running other tasks,
but it also might include conserving power.  I'd like to have my program
tell the kernel things like "wake me up in 0.1 seconds, plus or minus
a year if you have something better to do."

With my sysadmin hat on (which is nearly identical to my phone owner hat,
BTW), I'd like whatever syscall implements those features to take a PID
argument, so I can impose my importance decisions on other processes.
I'd also like to set the relative importance of keeping the CPU idle on
the same scale, so that I could raise or lower the importance of keeping
the CPU idle as power availability changes.

> This whole thing introduces an artificial segregation of code. My 'cool'
> code is more important than your 'uncool' code. Without a clear
> definition of what makes code cool or not.

It's impossible in the general case for an application to know whether
it's important or not, so it's also impossible for the kernel to derive
this information from the application's behavior--and impossible, in the
general case, to decide whether the application is more important than the
battery or some other scarce resource the kernel might also be managing
(e.g. if the machine is running hot, heat dissipation might be scarce,
and we'd want to be idle then too).  This is similar to niceness and
SCHED_RR/FIFO:  there's no way for the kernel to automatically assign
those values either, they have to be specified by a user or administrator.
Of course, programs are free--within limits--to specify these values
about themselves.

Consider a traditional Unix program like "sort".  Seriously, how is "sort"
supposed to know that it's the most important application on the system
(because I need my contacts list alphabetized *now*), or the least
(because the screensaver needs to know which is the oldest graphics
hack in the list)?

"sort" gets invoked from a shell, cooperating with other processes to do
its work.  It knows very little about the context in which it is executing
(nor should it).  Should "sort" sprout command-line arguments for every
possible scheduling latency and power management policy option, or should
"sort" not care, and defer such decisions to other command-line
tools which set these options before exec()ing "sort", or to a management
utility like "top" that implements policy across the entire system?

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Linus Walleij]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
>> > With a single suspend manager process that manages the suspend state you
>> > can achieve the same goal.
>> >
>>
>> Yes we don't need the /dev interface, but it is useful. Without it any
>> program that needs to block suspend has to make a blocking ipc call
>> into the suspend manager process. Android already does this for java
>> code, but system processes written in C block suspend directly with
>> the kernel since they cannot use the java APIs.
>
> So provide a C interface to it as well?
>
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

Android already has D-Bus:
http://android.git.kernel.org/?p=platform/external/dbus.git;a=summary

Which has Java bindings:
http://dbus.freedesktop.org/doc/dbus-java/

D-Bus can be from C to send messages to the Java daemon.
So why not use that if this seems to be a problem. It even brings
serialized typing and all that funny stuff.

Yours,
Linus Walleij

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> 
> > > How is that not polling? If the user is holding down a key, the keypad
> > > driver has to block suspend, and user space will try to suspend again
> > > and again and again...
> > > 
> > 
> > If your userpsace is that stupid - sure. However, you can:
> > 
> > 1. Notify the suspend manager process that he rest of your userspace is
> > busy handling keystrokes so that it does not try to suspend while there
> > are events pending.
> > 
> > 2. Wait a tiny bit after last application notified you that it finished
> > processing events.
> 
> This is more complicated than necessary.  Arve is wrong; my suggested 
> design does not require polling.
> 
> The reason is simple: When a user process initiates an opportunistic 
> suspend, you make it wait in an interruptible sleep until all the 
> kernel suspend blockers are released.  No polling.  If another user 
> thread decides in the meantime that it needs to block the suspend, it 
> sends a signal to the power manager process.
> 
> In fact, other threads should signal the power manager process whenever 
> they want to block or unblock suspends.  That way the power manager 
> process can spend all its time sleeping, without doing any polling.

I still see an issue here.  Namely, if the power manager is in user space and
it's signaled to suspend, it has to ask the kernel to do that, presumably by
writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
power manager waits until the block is released.  Now, it should go back and
check if user space still doesn't block suspend and if so, wait until the block
is released and start over.  With all suspend blockers in the kernel this
looping behavior is avoidable.

> > So basically the difference is that with in-kernel suspend blockers,
> > there is a tiny window where we haven't started the suspend yet but are
> > about to the driver has a chance to prevent entire system from starting
> > sleep.
> > 
> > Without the blocker we may start suspending and will stop midcycle. We
> > may be even better off in the end since we could leave some devices
> > still powered down after aborting system-wide suspend.
> 
> That's not so easy.  The design of the PM core requires that when the 
> system wakes up from suspend (or from an aborted suspend attempt), all 
> devices should go to full-power-on.  This is explained in section 6 of
> Documentation/power/runtime_pm.txt.
> 
> The decision over whether to use kernel-space suspend blockers vs. 
> aborting suspends when queues are non-empty comes down to a tradeoff:
> 
> 	Suspend blockers involve a little more code (to create,
> 	destroy, enable, and disable them) plus a little extra
> 	runtime overhead each time an event occurs.  (Some people
> 	may object to this extra overhead, although so far nobody
> 	in this discussion has done so.)
> 
> 	Suspend blockers eliminate the extra overhead involved in
> 	starting suspends that are just going to be aborted.
> 
> 	Suspend blockers offer extra debugging and accountability
> 	(the user can find out which subsystems are responsible for
> 	keeping the system awake).
> 
> Which way you think the tradeoff should go is a subjective decision.  I 
> think that kernel suspend blockers are acceptable.

I agree.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Alan Stern wrote:
> On Tue, 25 May 2010, Dmitry Torokhov wrote:
> 
> > > How is that not polling? If the user is holding down a key, the keypad
> > > driver has to block suspend, and user space will try to suspend again
> > > and again and again...
> > > 
> > 
> > If your userpsace is that stupid - sure. However, you can:
> > 
> > 1. Notify the suspend manager process that he rest of your userspace is
> > busy handling keystrokes so that it does not try to suspend while there
> > are events pending.
> > 
> > 2. Wait a tiny bit after last application notified you that it finished
> > processing events.
> 
> This is more complicated than necessary.  Arve is wrong; my suggested 
> design does not require polling.
> 
> The reason is simple: When a user process initiates an opportunistic 
> suspend, you make it wait in an interruptible sleep until all the 
> kernel suspend blockers are released.  No polling.  If another user 
> thread decides in the meantime that it needs to block the suspend, it 
> sends a signal to the power manager process.
> 
> In fact, other threads should signal the power manager process whenever 
> they want to block or unblock suspends.  That way the power manager 
> process can spend all its time sleeping, without doing any polling.

I still see an issue here.  Namely, if the power manager is in user space and
it's signaled to suspend, it has to ask the kernel to do that, presumably by
writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
power manager waits until the block is released.  Now, it should go back and
check if user space still doesn't block suspend and if so, wait until the block
is released and start over.  With all suspend blockers in the kernel this
looping behavior is avoidable.

> > So basically the difference is that with in-kernel suspend blockers,
> > there is a tiny window where we haven't started the suspend yet but are
> > about to the driver has a chance to prevent entire system from starting
> > sleep.
> > 
> > Without the blocker we may start suspending and will stop midcycle. We
> > may be even better off in the end since we could leave some devices
> > still powered down after aborting system-wide suspend.
> 
> That's not so easy.  The design of the PM core requires that when the 
> system wakes up from suspend (or from an aborted suspend attempt), all 
> devices should go to full-power-on.  This is explained in section 6 of
> Documentation/power/runtime_pm.txt.
> 
> The decision over whether to use kernel-space suspend blockers vs. 
> aborting suspends when queues are non-empty comes down to a tradeoff:
> 
> 	Suspend blockers involve a little more code (to create,
> 	destroy, enable, and disable them) plus a little extra
> 	runtime overhead each time an event occurs.  (Some people
> 	may object to this extra overhead, although so far nobody
> 	in this discussion has done so.)
> 
> 	Suspend blockers eliminate the extra overhead involved in
> 	starting suspends that are just going to be aborted.
> 
> 	Suspend blockers offer extra debugging and accountability
> 	(the user can find out which subsystems are responsible for
> 	keeping the system awake).
> 
> Which way you think the tradeoff should go is a subjective decision.  I 
> think that kernel suspend blockers are acceptable.

I agree.

Rafael

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > +To create a suspend blocker from user space, open the suspend_blocker
> > special
> > +device file:
> > +
> > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > +
> > +then optionally call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > +
> > +To activate the suspend blocker call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > +
> > +To deactivate it call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > +
> > +To destroy the suspend blocker, close the device:
> > +
> > +    close(fd);
> 
> Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> the SET_NAME thing if you really care.

SET_NAME wouldn't serve any purpose in that case.

This whole thing is related to the statistics part, which Arve says is
essential to him.  He wants to collect statistics for each suspend blocker
activated and deactivated so that he can tell who's causing problems by
blocking suspend too often.  The name also is a part of this.

In fact, without the statistics part the whole thing might be implemented
as a single reference counter such that suspend would happen when it went down
to zero.

Thanks,
Rafael

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > +To create a suspend blocker from user space, open the suspend_blocker
> > special
> > +device file:
> > +
> > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > +
> > +then optionally call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > +
> > +To activate the suspend blocker call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > +
> > +To deactivate it call:
> > +
> > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > +
> > +To destroy the suspend blocker, close the device:
> > +
> > +    close(fd);
> 
> Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> the SET_NAME thing if you really care.

SET_NAME wouldn't serve any purpose in that case.

This whole thing is related to the statistics part, which Arve says is
essential to him.  He wants to collect statistics for each suspend blocker
activated and deactivated so that he can tell who's causing problems by
blocking suspend too often.  The name also is a part of this.

In fact, without the statistics part the whole thing might be implemented
as a single reference counter such that suspend would happen when it went down
to zero.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Matthew Garrett wrote:
> On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> 
> > I fail to see why. In both cases the woken userspace will contact a
> > central governing task, either the kernel or the userspace suspend
> > manager, and inform it there is work to be done, and please don't
> > suspend now.
> 
> Thinking about this, you're right - we don't have to wait, but that does 
> result in another problem. Imagine we get two wakeup events 
> approximately simultaneously. In the kernel-level universe the kernel 
> knows when both have been handled. In the user-level universe, we may 
> have one task schedule, bump the count, handle the event, drop the count 
> and then we attempt a suspend again because the second event handler 
> hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> immediately bounce back up. That's kind of wasteful, although it'd be 
> somewhat mitigated by checking that right at the top of suspend entry 
> and returning -EAGAIN or similar.

I still think it would cause a loop-alike behavior between the user space
power manager and the kernel PM core to happen, because the power manager
will always have to check the user space counter after a failing suspend
attempt.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Matthew Garrett wrote:
> On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> 
> > I fail to see why. In both cases the woken userspace will contact a
> > central governing task, either the kernel or the userspace suspend
> > manager, and inform it there is work to be done, and please don't
> > suspend now.
> 
> Thinking about this, you're right - we don't have to wait, but that does 
> result in another problem. Imagine we get two wakeup events 
> approximately simultaneously. In the kernel-level universe the kernel 
> knows when both have been handled. In the user-level universe, we may 
> have one task schedule, bump the count, handle the event, drop the count 
> and then we attempt a suspend again because the second event handler 
> hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> immediately bounce back up. That's kind of wasteful, although it'd be 
> somewhat mitigated by checking that right at the top of suspend entry 
> and returning -EAGAIN or similar.

I still think it would cause a loop-alike behavior between the user space
power manager and the kernel PM core to happen, because the power manager
will always have to check the user space counter after a failing suspend
attempt.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.

> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The Linux approach is to do the job right. That means getting the
interface right and so it works across all the interested parties (or as
close as we can get).

> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most
> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

The key question that matters for suspend management is 'what wakeup
delay is tolerated'. So it's absolutely fundamental.

> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

This is the Linux way of doing things. It's like the GPL and being
shouted at by Linus. They are things you accept when you choose to take
part. Google chose to use Linux, if they want a feature upstream then the
way you get it there is to figure out how to solve the real problem and
make *everyone* (within reason) happy.

We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can
still simply stonewall those interfaces, and a volunteer community has
ways of dealing with abuse of process, notably by simply not getting
around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even
if you get away with in the short term the people who rely on the junk
will end up out on a limb and holding the baby when the crap hits the fan
(see reiserfs)

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.

> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The Linux approach is to do the job right. That means getting the
interface right and so it works across all the interested parties (or as
close as we can get).

> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most
> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

The key question that matters for suspend management is 'what wakeup
delay is tolerated'. So it's absolutely fundamental.

> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

This is the Linux way of doing things. It's like the GPL and being
shouted at by Linus. They are things you accept when you choose to take
part. Google chose to use Linux, if they want a feature upstream then the
way you get it there is to figure out how to solve the real problem and
make *everyone* (within reason) happy.

We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can
still simply stonewall those interfaces, and a volunteer community has
ways of dealing with abuse of process, notably by simply not getting
around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even
if you get away with in the short term the people who rely on the junk
will end up out on a limb and holding the baby when the crap hits the fan
(see reiserfs)

Alan

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Florian Mickler wrote:
> On Wed, 26 May 2010 19:28:24 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> 
> > Besides that it is not linux system at all?
> 
> I believe the kernel to be a layer between userspace and hardware. What
> business is it to the kernel if it runs whatever android
> uses as init process or /bin/bash, sys-v-init or systemd?
> 
> There is this thing called choice. 
> 
> > 
> > Yes, with custom userspace it works extremely nicely.
> > 
> > Had anyone even tried running oportunistic suspend on normal desktop?
> > 									Pavel
> 
> I don't think this is a valid concern. Just because current linux/gnu
> systems don't implement the userspace part of this interface doesn't
> mean it is useless or broken. 

Agreed.

BTW, this is a valid point.  We are used to think about Linux as the kernel
plus the GNU user space, but that's not how it has to be.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Florian Mickler wrote:
> On Wed, 26 May 2010 19:28:24 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> 
> > Besides that it is not linux system at all?
> 
> I believe the kernel to be a layer between userspace and hardware. What
> business is it to the kernel if it runs whatever android
> uses as init process or /bin/bash, sys-v-init or systemd?
> 
> There is this thing called choice. 
> 
> > 
> > Yes, with custom userspace it works extremely nicely.
> > 
> > Had anyone even tried running oportunistic suspend on normal desktop?
> > 									Pavel
> 
> I don't think this is a valid concern. Just because current linux/gnu
> systems don't implement the userspace part of this interface doesn't
> mean it is useless or broken. 

Agreed.

BTW, this is a valid point.  We are used to think about Linux as the kernel
plus the GNU user space, but that's not how it has to be.

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Rafael J. Wysocki wrote:

> > The reason is simple: When a user process initiates an opportunistic 
> > suspend, you make it wait in an interruptible sleep until all the 
> > kernel suspend blockers are released.  No polling.  If another user 
> > thread decides in the meantime that it needs to block the suspend, it 
> > sends a signal to the power manager process.
> > 
> > In fact, other threads should signal the power manager process whenever 
> > they want to block or unblock suspends.  That way the power manager 
> > process can spend all its time sleeping, without doing any polling.
> 
> I still see an issue here.  Namely, if the power manager is in user space and
> it's signaled to suspend, it has to ask the kernel to do that, presumably by
> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
> power manager waits until the block is released.  Now, it should go back and
> check if user space still doesn't block suspend and if so, wait until the block
> is released and start over.  With all suspend blockers in the kernel this
> looping behavior is avoidable.

I must be missing something.  In Arve's patch 1/8, if the system is in
opportunistic suspend, and a wakeup event occurs but no suspend
blockers get enabled by the handler, what causes the system to go back
into suspend after the event is handled?  Isn't that a loop of some
sort?

And even if it isn't, so what?  What's wrong with looping behavior?  
Especially a loop that's as short as this one and spends almost all of
its time sleeping.  Think how much harder it would be to write programs
if you weren't allowed to use any loops.  :-)

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Rafael J. Wysocki wrote:

> > The reason is simple: When a user process initiates an opportunistic 
> > suspend, you make it wait in an interruptible sleep until all the 
> > kernel suspend blockers are released.  No polling.  If another user 
> > thread decides in the meantime that it needs to block the suspend, it 
> > sends a signal to the power manager process.
> > 
> > In fact, other threads should signal the power manager process whenever 
> > they want to block or unblock suspends.  That way the power manager 
> > process can spend all its time sleeping, without doing any polling.
> 
> I still see an issue here.  Namely, if the power manager is in user space and
> it's signaled to suspend, it has to ask the kernel to do that, presumably by
> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
> power manager waits until the block is released.  Now, it should go back and
> check if user space still doesn't block suspend and if so, wait until the block
> is released and start over.  With all suspend blockers in the kernel this
> looping behavior is avoidable.

I must be missing something.  In Arve's patch 1/8, if the system is in
opportunistic suspend, and a wakeup event occurs but no suspend
blockers get enabled by the handler, what causes the system to go back
into suspend after the event is handled?  Isn't that a loop of some
sort?

And even if it isn't, so what?  What's wrong with looping behavior?  
Especially a loop that's as short as this one and spends almost all of
its time sleeping.  Think how much harder it would be to write programs
if you weren't allowed to use any loops.  :-)

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > or whatever.
> > > > 
> > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > concept of special sockets that can be used to communicate from less to
> > > > more privileged processes (it has a very segmented runtime model), so
> > > > these might be usable ... they have a drawback that they're essentially
> > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > process shouldn't be a huge burden. 
> > > 
> > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > enough to manage the suspend state.
> > > 
> > > Anyway, I think there's been enough arguments against even the concept
> > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > Rafael send this to Linus.
> > 
> > It was submitted already. I tried to followup with NAK, but can't
> > currently see it in the archive.
> 
> It was apparently hidden on some funky list. Hiding pull requests is bad
> enough, but hiding pull requests for contended features is just plain
> wrong.

It was not intentionally hidden.  I think my mailer did that wrong because
the CC list was too long or something like this.  I surely intended to send
it to the LKML, so sorry for the inconvenience.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > or whatever.
> > > > 
> > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > concept of special sockets that can be used to communicate from less to
> > > > more privileged processes (it has a very segmented runtime model), so
> > > > these might be usable ... they have a drawback that they're essentially
> > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > process shouldn't be a huge burden. 
> > > 
> > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > enough to manage the suspend state.
> > > 
> > > Anyway, I think there's been enough arguments against even the concept
> > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > Rafael send this to Linus.
> > 
> > It was submitted already. I tried to followup with NAK, but can't
> > currently see it in the archive.
> 
> It was apparently hidden on some funky list. Hiding pull requests is bad
> enough, but hiding pull requests for contended features is just plain
> wrong.

It was not intentionally hidden.  I think my mailer did that wrong because
the CC list was too long or something like this.  I surely intended to send
it to the LKML, so sorry for the inconvenience.

Rafael

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Cox]

> This whole thing is related to the statistics part, which Arve says is
> essential to him.  He wants to collect statistics for each suspend blocker
> activated and deactivated so that he can tell who's causing problems by
> blocking suspend too often.  The name also is a part of this.

If he wants to collect stats about misbehaving code then presumably he
needs reliable stats. Arbitary user set names are not reliable and
judging by app vendor behaviour in the proprietary space with other such
examples they will actively name their blockers in a manner specifically
intended to hide the cause so as to 'reduce support costs'.

Its a waste of memory (especially if I create a million of them with a
long name for fun).

It's all an economic system, proprietary app vendors are in it to make
money, some will therefore game the system and the rest will be forced to
follow to keep their playing field fair.

Alan

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Brian Swetland]

On Wed, May 26, 2010 at 3:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> This whole thing is related to the statistics part, which Arve says is
>> essential to him.  He wants to collect statistics for each suspend blocker
>> activated and deactivated so that he can tell who's causing problems by
>> blocking suspend too often.  The name also is a part of this.
>
> If he wants to collect stats about misbehaving code then presumably he
> needs reliable stats. Arbitary user set names are not reliable and
> judging by app vendor behaviour in the proprietary space with other such
> examples they will actively name their blockers in a manner specifically
> intended to hide the cause so as to 'reduce support costs'.
>
> Its a waste of memory (especially if I create a million of them with a
> long name for fun).

You are limited to one per open fd of the device, and a max name size
which could be further shrunk to something pretty small (32?) if
desired.  The device node interface came about after discussions last
year and concerns that userspace could create an unbounded number of
suspend blockers.

> It's all an economic system, proprietary app vendors are in it to make
> money, some will therefore game the system and the rest will be forced to
> follow to keep their playing field fair.

Untrusted (non-system) code can't directly access the device node from
userspace in the Android world -- so directly created suspend blockers
from userspace are only created by a couple system processes (3-4
typically).  Applications are sandboxed by UID and there is (much
more) per-application accounting in the userspace application manager
process (other resource consumption such as sensors, CPU, etc is
tracked here as well).

For suspend blockers created by drivers and by trusted userspace
processes, having a meaningful name significantly helps statistics
gathering.

Brian

Re: [linux-pm] [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Stern]

On Wed, 26 May 2010, Rafael J. Wysocki wrote:

> On Wednesday 26 May 2010, Peter Zijlstra wrote:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > > +To create a suspend blocker from user space, open the suspend_blocker
> > > special
> > > +device file:
> > > +
> > > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > > +
> > > +then optionally call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > > +
> > > +To activate the suspend blocker call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > > +
> > > +To deactivate it call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > > +
> > > +To destroy the suspend blocker, close the device:
> > > +
> > > +    close(fd);
> > 
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> 
> SET_NAME wouldn't serve any purpose in that case.
> 
> This whole thing is related to the statistics part, which Arve says is
> essential to him.  He wants to collect statistics for each suspend blocker
> activated and deactivated so that he can tell who's causing problems by
> blocking suspend too often.  The name also is a part of this.
> 
> In fact, without the statistics part the whole thing might be implemented
> as a single reference counter such that suspend would happen when it went down
> to zero.

There's also Arve's other main point: These suspend blockers tend to
get used quite a lot.  Opening and closing a file each time has much
higher overhead than a simple ioctl.

All these topics have been covered earlier in this discussion.  Peter 
should go back and read the emails in the linux-pm archive.

Alan Stern

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Stern]

On Wed, 26 May 2010, Rafael J. Wysocki wrote:

> On Wednesday 26 May 2010, Peter Zijlstra wrote:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > > +To create a suspend blocker from user space, open the suspend_blocker
> > > special
> > > +device file:
> > > +
> > > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > > +
> > > +then optionally call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > > +
> > > +To activate the suspend blocker call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > > +
> > > +To deactivate it call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > > +
> > > +To destroy the suspend blocker, close the device:
> > > +
> > > +    close(fd);
> > 
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> 
> SET_NAME wouldn't serve any purpose in that case.
> 
> This whole thing is related to the statistics part, which Arve says is
> essential to him.  He wants to collect statistics for each suspend blocker
> activated and deactivated so that he can tell who's causing problems by
> blocking suspend too often.  The name also is a part of this.
> 
> In fact, without the statistics part the whole thing might be implemented
> as a single reference counter such that suspend would happen when it went down
> to zero.

There's also Arve's other main point: These suspend blockers tend to
get used quite a lot.  Opening and closing a file each time has much
higher overhead than a simple ioctl.

All these topics have been covered earlier in this discussion.  Peter 
should go back and read the emails in the linux-pm archive.

Alan Stern

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Stern]

On Wed, 26 May 2010, Rafael J. Wysocki wrote:

> On Wednesday 26 May 2010, Peter Zijlstra wrote:
> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > > +To create a suspend blocker from user space, open the suspend_blocker
> > > special
> > > +device file:
> > > +
> > > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > > +
> > > +then optionally call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > > +
> > > +To activate the suspend blocker call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > > +
> > > +To deactivate it call:
> > > +
> > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > > +
> > > +To destroy the suspend blocker, close the device:
> > > +
> > > +    close(fd);
> > 
> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > the SET_NAME thing if you really care.
> 
> SET_NAME wouldn't serve any purpose in that case.
> 
> This whole thing is related to the statistics part, which Arve says is
> essential to him.  He wants to collect statistics for each suspend blocker
> activated and deactivated so that he can tell who's causing problems by
> blocking suspend too often.  The name also is a part of this.
> 
> In fact, without the statistics part the whole thing might be implemented
> as a single reference counter such that suspend would happen when it went down
> to zero.

There's also Arve's other main point: These suspend blockers tend to
get used quite a lot.  Opening and closing a file each time has much
higher overhead than a simple ioctl.

All these topics have been covered earlier in this discussion.  Peter 
should go back and read the emails in the linux-pm archive.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Thomas Gleixner wrote:
> On Wed, 26 May 2010, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > > or whatever.
> > > > > > 
> > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > > concept of special sockets that can be used to communicate from less to
> > > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > > these might be usable ... they have a drawback that they're essentially
> > > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > > process shouldn't be a huge burden. 
> > > > > 
> > > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > > enough to manage the suspend state.
> > > > > 
> > > > > Anyway, I think there's been enough arguments against even the concept
> > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > > Rafael send this to Linus.
> > > > 
> > > > It was submitted already. I tried to followup with NAK, but can't
> > > > currently see it in the archive.
> > 
> > You mean this one:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> > 
> > ?
> > 
> > > It was apparently hidden on some funky list.
> > 
> > Sending a PM pull request to the PM list doesn't really strike me as the
> > height of obfuscation.  Plus almost everyone who objected was on the cc
> > list.
> > 
> > >  Hiding pull requests is bad enough, but hiding pull requests for
> > > contended features is just plain wrong.
> > 
> > I don't think it's a conspiracy ... just standard operating procedure
> > for this subsystem.  I do think cc'ing lkml is good practise (having
> > been yelled at for not doing that in the past) but it's certainly not
> > universal practise.
> 
> At least it would be good style for a topic which is

As I said in another message, I intended to send the pull request to the LKML,
but for some reason that didn't work.  Perhaps that was my fault, so sorry for
that, but I think the CC list contained people who had objections, so they
easily could respond (adding the CC to the LKML).

>    1) contended like this one
> 
>    2) pushing an intrusive feature last minute which has been merged
>       into the pm tree barely two days ago.

It had been discussed for a month before without any serious progress, though,
so I simply had to do something to make things go. :-)

> Darn, _we_ have to deal with that forever as it sets a crappy user
> space ABI in stone.

Well, I don't think it's _that_ bad, although it isn't nice either.

The whole reason why it's there is because the Google people want to collect
suspend blocker usage statistics, so that they can easily check how often
applications block suspending.  If we dropped the statistics part, the
interface might be substantially simplified.

Thanks,
Rafael



> 
> Thanks,
> 
> 	tglx
> 
> 

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Wednesday 26 May 2010, Thomas Gleixner wrote:
> On Wed, 26 May 2010, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > > or whatever.
> > > > > > 
> > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > > concept of special sockets that can be used to communicate from less to
> > > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > > these might be usable ... they have a drawback that they're essentially
> > > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > > process shouldn't be a huge burden. 
> > > > > 
> > > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > > enough to manage the suspend state.
> > > > > 
> > > > > Anyway, I think there's been enough arguments against even the concept
> > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > > Rafael send this to Linus.
> > > > 
> > > > It was submitted already. I tried to followup with NAK, but can't
> > > > currently see it in the archive.
> > 
> > You mean this one:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> > 
> > ?
> > 
> > > It was apparently hidden on some funky list.
> > 
> > Sending a PM pull request to the PM list doesn't really strike me as the
> > height of obfuscation.  Plus almost everyone who objected was on the cc
> > list.
> > 
> > >  Hiding pull requests is bad enough, but hiding pull requests for
> > > contended features is just plain wrong.
> > 
> > I don't think it's a conspiracy ... just standard operating procedure
> > for this subsystem.  I do think cc'ing lkml is good practise (having
> > been yelled at for not doing that in the past) but it's certainly not
> > universal practise.
> 
> At least it would be good style for a topic which is

As I said in another message, I intended to send the pull request to the LKML,
but for some reason that didn't work.  Perhaps that was my fault, so sorry for
that, but I think the CC list contained people who had objections, so they
easily could respond (adding the CC to the LKML).

>    1) contended like this one
> 
>    2) pushing an intrusive feature last minute which has been merged
>       into the pm tree barely two days ago.

It had been discussed for a month before without any serious progress, though,
so I simply had to do something to make things go. :-)

> Darn, _we_ have to deal with that forever as it sets a crappy user
> space ABI in stone.

Well, I don't think it's _that_ bad, although it isn't nice either.

The whole reason why it's there is because the Google people want to collect
suspend blocker usage statistics, so that they can easily check how often
applications block suspending.  If we dropped the statistics part, the
interface might be substantially simplified.

Thanks,
Rafael



> 
> Thanks,
> 
> 	tglx
> 
> 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Really, what are you getting at? Do you deny that there are programs,
>> that prevent a device from sleeping? (Just think of the bouncing
>> cows app)
>>
>> And if you have two kernels, one with which your device is dead after 1
>> hour and one with which your device is dead after 10 hours. Which would
>> you prefer? I mean really... this is ridiculous.
>
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends.

We never suspend when the screen is on. If the screen is off, I would
not be upset if it suspends.

> What you are essentially arguing for is for the
> kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible.
Suspend is an existing kernel feature. All opportunistic suspend adds
is the ability to use it safely when there are wakeup event you cannot
afford to ignore.

> It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
>
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.
>
> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
>

Our actual stating point is this: Some systems can only enter their
lowest power state from suspend. So we added an api that allowed us to
use suspend without loosing wakeup events. Since suspending also
improves our battery life on platforms that enter the same power state
from idle and suspend and we already have a way to safely use suspend,
we would be crazy not to use it.

> - You don't know which processes should be ignored for the purpose of
>  suspend (except for kernel threads) and there is no way to set this
>
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>  just a really deep idle in truth anyway) might break wakeups
>  requirements because a device has wake dependencies due to hardware
>  design (eg a port that has no electronics to kick the box out of
>  suspend into running). This is a problem we have already. [1]
>
> That maps onto two existing ideas
>
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross
process dependencies. When a call comes in I don't know where the name
and picture to display comes from. With suspend blockers we block
suspend when we get notified that we have an incoming call and we can
call into any process and get a response.

>
>                setpidle(getpid(), something);
>                exec()
>
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
>
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone.
>
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
>


What about platforms that currently cannot enter low power states from
idle? Do you remove suspend support from the kernel?


> Alan
> --
>
> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Really, what are you getting at? Do you deny that there are programs,
>> that prevent a device from sleeping? (Just think of the bouncing
>> cows app)
>>
>> And if you have two kernels, one with which your device is dead after 1
>> hour and one with which your device is dead after 10 hours. Which would
>> you prefer? I mean really... this is ridiculous.
>
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends.

We never suspend when the screen is on. If the screen is off, I would
not be upset if it suspends.

> What you are essentially arguing for is for the
> kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible.
Suspend is an existing kernel feature. All opportunistic suspend adds
is the ability to use it safely when there are wakeup event you cannot
afford to ignore.

> It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
>
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.
>
> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
>

Our actual stating point is this: Some systems can only enter their
lowest power state from suspend. So we added an api that allowed us to
use suspend without loosing wakeup events. Since suspending also
improves our battery life on platforms that enter the same power state
from idle and suspend and we already have a way to safely use suspend,
we would be crazy not to use it.

> - You don't know which processes should be ignored for the purpose of
>  suspend (except for kernel threads) and there is no way to set this
>
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>  just a really deep idle in truth anyway) might break wakeups
>  requirements because a device has wake dependencies due to hardware
>  design (eg a port that has no electronics to kick the box out of
>  suspend into running). This is a problem we have already. [1]
>
> That maps onto two existing ideas
>
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross
process dependencies. When a call comes in I don't know where the name
and picture to display comes from. With suspend blockers we block
suspend when we get notified that we have an incoming call and we can
call into any process and get a response.

>
>                setpidle(getpid(), something);
>                exec()
>
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
>
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone.
>
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
>


What about platforms that currently cannot enter low power states from
idle? Do you remove suspend support from the kernel?


> Alan
> --
>
> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Really, what are you getting at? Do you deny that there are programs,
>> that prevent a device from sleeping? (Just think of the bouncing
>> cows app)
>>
>> And if you have two kernels, one with which your device is dead after 1
>> hour and one with which your device is dead after 10 hours. Which would
>> you prefer? I mean really... this is ridiculous.
>
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends.

We never suspend when the screen is on. If the screen is off, I would
not be upset if it suspends.

> What you are essentially arguing for is for the
> kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible.
Suspend is an existing kernel feature. All opportunistic suspend adds
is the ability to use it safely when there are wakeup event you cannot
afford to ignore.

> It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
>
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.
>
> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
>

Our actual stating point is this: Some systems can only enter their
lowest power state from suspend. So we added an api that allowed us to
use suspend without loosing wakeup events. Since suspending also
improves our battery life on platforms that enter the same power state
from idle and suspend and we already have a way to safely use suspend,
we would be crazy not to use it.

> - You don't know which processes should be ignored for the purpose of
>  suspend (except for kernel threads) and there is no way to set this
>
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>  just a really deep idle in truth anyway) might break wakeups
>  requirements because a device has wake dependencies due to hardware
>  design (eg a port that has no electronics to kick the box out of
>  suspend into running). This is a problem we have already. [1]
>
> That maps onto two existing ideas
>
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross
process dependencies. When a call comes in I don't know where the name
and picture to display comes from. With suspend blockers we block
suspend when we get notified that we have an incoming call and we can
call into any process and get a response.

>
>                setpidle(getpid(), something);
>                exec()
>
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
>
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone.
>
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
>


What about platforms that currently cannot enter low power states from
idle? Do you remove suspend support from the kernel?


> Alan
> --
>
> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
> 
> > On Wednesday 26 May 2010, Peter Zijlstra wrote:
> > > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > > > +To create a suspend blocker from user space, open the suspend_blocker
> > > > special
> > > > +device file:
> > > > +
> > > > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > > > +
> > > > +then optionally call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > > > +
> > > > +To activate the suspend blocker call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > > > +
> > > > +To deactivate it call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > > > +
> > > > +To destroy the suspend blocker, close the device:
> > > > +
> > > > +    close(fd);
> > > 
> > > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > > the SET_NAME thing if you really care.
> > 
> > SET_NAME wouldn't serve any purpose in that case.
> > 
> > This whole thing is related to the statistics part, which Arve says is
> > essential to him.  He wants to collect statistics for each suspend blocker
> > activated and deactivated so that he can tell who's causing problems by
> > blocking suspend too often.  The name also is a part of this.
> > 
> > In fact, without the statistics part the whole thing might be implemented
> > as a single reference counter such that suspend would happen when it went down
> > to zero.
> 
> There's also Arve's other main point: These suspend blockers tend to
> get used quite a lot.  Opening and closing a file each time has much
> higher overhead than a simple ioctl.
> 
> All these topics have been covered earlier in this discussion.  Peter 
> should go back and read the emails in the linux-pm archive.

Yeah.

Although with a reference counter the special device file won't be necessary.

Rafael

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
> 
> > On Wednesday 26 May 2010, Peter Zijlstra wrote:
> > > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
> > > > +To create a suspend blocker from user space, open the suspend_blocker
> > > > special
> > > > +device file:
> > > > +
> > > > +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
> > > > +
> > > > +then optionally call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
> > > > +
> > > > +To activate the suspend blocker call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
> > > > +
> > > > +To deactivate it call:
> > > > +
> > > > +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
> > > > +
> > > > +To destroy the suspend blocker, close the device:
> > > > +
> > > > +    close(fd);
> > > 
> > > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
> > > the SET_NAME thing if you really care.
> > 
> > SET_NAME wouldn't serve any purpose in that case.
> > 
> > This whole thing is related to the statistics part, which Arve says is
> > essential to him.  He wants to collect statistics for each suspend blocker
> > activated and deactivated so that he can tell who's causing problems by
> > blocking suspend too often.  The name also is a part of this.
> > 
> > In fact, without the statistics part the whole thing might be implemented
> > as a single reference counter such that suspend would happen when it went down
> > to zero.
> 
> There's also Arve's other main point: These suspend blockers tend to
> get used quite a lot.  Opening and closing a file each time has much
> higher overhead than a simple ioctl.
> 
> All these topics have been covered earlier in this discussion.  Peter 
> should go back and read the emails in the linux-pm archive.

Yeah.

Although with a reference counter the special device file won't be necessary.

Rafael

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > This whole thing is related to the statistics part, which Arve says is
> > essential to him.  He wants to collect statistics for each suspend blocker
> > activated and deactivated so that he can tell who's causing problems by
> > blocking suspend too often.  The name also is a part of this.
> 
> If he wants to collect stats about misbehaving code then presumably he
> needs reliable stats. Arbitary user set names are not reliable and
> judging by app vendor behaviour in the proprietary space with other such
> examples they will actively name their blockers in a manner specifically
> intended to hide the cause so as to 'reduce support costs'.
> 
> Its a waste of memory (especially if I create a million of them with a
> long name for fun).

Well, I won't argue with that. :-)

> It's all an economic system, proprietary app vendors are in it to make
> money, some will therefore game the system and the rest will be forced to
> follow to keep their playing field fair.

Good point.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
> 
> > > The reason is simple: When a user process initiates an opportunistic 
> > > suspend, you make it wait in an interruptible sleep until all the 
> > > kernel suspend blockers are released.  No polling.  If another user 
> > > thread decides in the meantime that it needs to block the suspend, it 
> > > sends a signal to the power manager process.
> > > 
> > > In fact, other threads should signal the power manager process whenever 
> > > they want to block or unblock suspends.  That way the power manager 
> > > process can spend all its time sleeping, without doing any polling.
> > 
> > I still see an issue here.  Namely, if the power manager is in user space and
> > it's signaled to suspend, it has to ask the kernel to do that, presumably by
> > writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
> > power manager waits until the block is released.  Now, it should go back and
> > check if user space still doesn't block suspend and if so, wait until the block
> > is released and start over.  With all suspend blockers in the kernel this
> > looping behavior is avoidable.
> 
> I must be missing something.  In Arve's patch 1/8, if the system is in
> opportunistic suspend, and a wakeup event occurs but no suspend
> blockers get enabled by the handler, what causes the system to go back
> into suspend after the event is handled?  Isn't that a loop of some
> sort?

Well, yes it is.

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
> 
> > > The reason is simple: When a user process initiates an opportunistic 
> > > suspend, you make it wait in an interruptible sleep until all the 
> > > kernel suspend blockers are released.  No polling.  If another user 
> > > thread decides in the meantime that it needs to block the suspend, it 
> > > sends a signal to the power manager process.
> > > 
> > > In fact, other threads should signal the power manager process whenever 
> > > they want to block or unblock suspends.  That way the power manager 
> > > process can spend all its time sleeping, without doing any polling.
> > 
> > I still see an issue here.  Namely, if the power manager is in user space and
> > it's signaled to suspend, it has to ask the kernel to do that, presumably by
> > writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
> > power manager waits until the block is released.  Now, it should go back and
> > check if user space still doesn't block suspend and if so, wait until the block
> > is released and start over.  With all suspend blockers in the kernel this
> > looping behavior is avoidable.
> 
> I must be missing something.  In Arve's patch 1/8, if the system is in
> opportunistic suspend, and a wakeup event occurs but no suspend
> blockers get enabled by the handler, what causes the system to go back
> into suspend after the event is handled?  Isn't that a loop of some
> sort?

Well, yes it is.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >> >
>> >> >> and on systems where the
>> >> >> same power state can be used from idle and suspend, we use suspend so
>> >> >> we can stay in the low power state for minutes to hours instead of
>> >> >> milliseconds to seconds.
>> >> >
>> >> > So don't you think working on making it possible for systems to be idle
>> >> > _that_ long would improve things for everybody? as opposed to this
>> >> > auto-suspend which only improves matters for those that (can) use it?
>> >>
>> >> I'm not preventing anyone from working on improving this. Currently
>> >> both the kernel and our user-space code polls way too much. I don't
>> >> think it is reasonable to demand that no one should run any user-space
>> >> code with periodic timers when we have not even fixed the kernel to
>> >> not do this.
>> >
>> > All I'm saying is that merging a stop-gap measure will decrease the
>> > urgency and thus the time spend fixing the actual issues while adding
>> > the burden of maintaining this stop-gap measure.
>> >
>>
>> Fixing the actually issue means fixing all user-space code, and
>> replacing most x86 hardware. I don't think keeping this feature out of
>> the kernel will significantly accelerate this.
>
> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

x86 systems already auto-suspend.

>
> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.
>

Why? If your suspend is currently set to sleep after 30 minutes of
inactivity, you can still have the same setting with opportunistic
suspend. With opportunistic suspend you can have an alarm set to run a
task at a specific time without risking that this task does not run at
that time just because your inactivity timer expired at the same time
as the alarm went off.

> Getting longer idle periods however is something that everybody benefits
> from. On x86 we're nowhere close to hitting the max idle time of the
> platform, you get _tons_ of wakeups on current 'desktop' software.
>
> But x86 being a PITA shouldn't stop people from working on this, there's
> plenty other architectures out there, I remember fixing a NO_HZ bug with
> davem on sparc64 because his niagra had cores idling for very long times
> indeed.
>
> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.
>

To me this is not a good argument for not merging the code. If people
stop caring about the problem if this feature is merged that means it
solved a problem for them. You want to prevent merging a feature
_because_ it solves a problem.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >> >
>> >> >> and on systems where the
>> >> >> same power state can be used from idle and suspend, we use suspend so
>> >> >> we can stay in the low power state for minutes to hours instead of
>> >> >> milliseconds to seconds.
>> >> >
>> >> > So don't you think working on making it possible for systems to be idle
>> >> > _that_ long would improve things for everybody? as opposed to this
>> >> > auto-suspend which only improves matters for those that (can) use it?
>> >>
>> >> I'm not preventing anyone from working on improving this. Currently
>> >> both the kernel and our user-space code polls way too much. I don't
>> >> think it is reasonable to demand that no one should run any user-space
>> >> code with periodic timers when we have not even fixed the kernel to
>> >> not do this.
>> >
>> > All I'm saying is that merging a stop-gap measure will decrease the
>> > urgency and thus the time spend fixing the actual issues while adding
>> > the burden of maintaining this stop-gap measure.
>> >
>>
>> Fixing the actually issue means fixing all user-space code, and
>> replacing most x86 hardware. I don't think keeping this feature out of
>> the kernel will significantly accelerate this.
>
> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

x86 systems already auto-suspend.

>
> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.
>

Why? If your suspend is currently set to sleep after 30 minutes of
inactivity, you can still have the same setting with opportunistic
suspend. With opportunistic suspend you can have an alarm set to run a
task at a specific time without risking that this task does not run at
that time just because your inactivity timer expired at the same time
as the alarm went off.

> Getting longer idle periods however is something that everybody benefits
> from. On x86 we're nowhere close to hitting the max idle time of the
> platform, you get _tons_ of wakeups on current 'desktop' software.
>
> But x86 being a PITA shouldn't stop people from working on this, there's
> plenty other architectures out there, I remember fixing a NO_HZ bug with
> davem on sparc64 because his niagra had cores idling for very long times
> indeed.
>
> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.
>

To me this is not a good argument for not merging the code. If people
stop caring about the problem if this feature is merged that means it
solved a problem for them. You want to prevent merging a feature
_because_ it solves a problem.

-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Cox]

> desired.  The device node interface came about after discussions last
> year and concerns that userspace could create an unbounded number of
> suspend blockers.

Surely you only need one block per task (or better yet one expression of
latency per task). If not can you explain why a setup which has a per
task expression of latency needs (and a 'hard limit' set which you can't
then bump back down except as root) isn't enough ?

I'd really like this lot to also fix the hard real time and power
management problem we have today and to try an fix the "suspend is
special and different" mentality in the kernel, which is getting less and
less true on a variety of chips.

> > It's all an economic system, proprietary app vendors are in it to make
> > money, some will therefore game the system and the rest will be forced to
> > follow to keep their playing field fair.
> 
> Untrusted (non-system) code can't directly access the device node from
> userspace in the Android world -- so directly created suspend blockers

Great - but the world is not Android and even if they can't access it
directly but get passed a handle they can play.

> For suspend blockers created by drivers and by trusted userspace
> processes, having a meaningful name significantly helps statistics
> gathering.

By drivers I agree but in the driver case the cost is minimal because
there should not be many and it is bounded clearly. Again I really think
'suspend blocking' is the wrong expression.

A driver needs to express

'Don't go below this latency'

and

'Don't go below this state'

This is more generic and helps our power management do the right thing on
all boxes. For example a serial port can meaningfully say 'I want X
latency worst case' based upon the fact the fifo is 64 bytes and the user
space just asked for 115,200 baud.

The don't go below for states out of which the device must wake but
cannot. Eg if your device is being told by user space to set wake on lan
and can only wake on lan from a higher state than 'off' it needs to say
so.

Alan

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 4:00 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> desired.  The device node interface came about after discussions last
>> year and concerns that userspace could create an unbounded number of
>> suspend blockers.
>
> Surely you only need one block per task (or better yet one expression of

No, many suspend blockers protect data, not tasks. We block suspend
when there are unprocessed input events in the kernel queue.
User-space then blocks suspend before reading those events, and it
blocks suspend using a different suspend blocker when its queue of
processed events become not-empty.

> latency per task). If not can you explain why a setup which has a per
> task expression of latency needs (and a 'hard limit' set which you can't
> then bump back down except as root) isn't enough ?
>

> I'd really like this lot to also fix the hard real time and power
> management problem we have today and to try an fix the "suspend is
> special and different" mentality in the kernel, which is getting less and
> less true on a variety of chips.
>
>> > It's all an economic system, proprietary app vendors are in it to make
>> > money, some will therefore game the system and the rest will be forced to
>> > follow to keep their playing field fair.
>>
>> Untrusted (non-system) code can't directly access the device node from
>> userspace in the Android world -- so directly created suspend blockers
>
> Great - but the world is not Android and even if they can't access it
> directly but get passed a handle they can play.
>
>> For suspend blockers created by drivers and by trusted userspace
>> processes, having a meaningful name significantly helps statistics
>> gathering.
>
> By drivers I agree but in the driver case the cost is minimal because
> there should not be many and it is bounded clearly. Again I really think
> 'suspend blocking' is the wrong expression.
>
> A driver needs to express
>
> 'Don't go below this latency'
>
> and
>
> 'Don't go below this state'
>
> This is more generic and helps our power management do the right thing on
> all boxes. For example a serial port can meaningfully say 'I want X
> latency worst case' based upon the fact the fifo is 64 bytes and the user
> space just asked for 115,200 baud.
>
> The don't go below for states out of which the device must wake but
> cannot. Eg if your device is being told by user space to set wake on lan
> and can only wake on lan from a higher state than 'off' it needs to say
> so.
>
> Alan
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 3:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
>
>> > The reason is simple: When a user process initiates an opportunistic
>> > suspend, you make it wait in an interruptible sleep until all the
>> > kernel suspend blockers are released.  No polling.  If another user
>> > thread decides in the meantime that it needs to block the suspend, it
>> > sends a signal to the power manager process.
>> >
>> > In fact, other threads should signal the power manager process whenever
>> > they want to block or unblock suspends.  That way the power manager
>> > process can spend all its time sleeping, without doing any polling.
>>
>> I still see an issue here.  Namely, if the power manager is in user space and
>> it's signaled to suspend, it has to ask the kernel to do that, presumably by
>> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
>> power manager waits until the block is released.  Now, it should go back and
>> check if user space still doesn't block suspend and if so, wait until the block
>> is released and start over.  With all suspend blockers in the kernel this
>> looping behavior is avoidable.
>
> I must be missing something.  In Arve's patch 1/8, if the system is in
> opportunistic suspend, and a wakeup event occurs but no suspend
> blockers get enabled by the handler, what causes the system to go back
> into suspend after the event is handled?  Isn't that a loop of some
> sort?
>

Yes it is a loop. I think what you are missing is that it only loops
repeatedly if the driver that aborts suspend does not use a suspend
blocker.

> And even if it isn't, so what?  What's wrong with looping behavior?

It is a significant power drain.

> Especially a loop that's as short as this one and spends almost all of
> its time sleeping.  Think how much harder it would be to write programs
> if you weren't allowed to use any loops.  :-)
>
> Alan Stern
>
>


-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 3:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 26 May 2010, Rafael J. Wysocki wrote:
>
>> > The reason is simple: When a user process initiates an opportunistic
>> > suspend, you make it wait in an interruptible sleep until all the
>> > kernel suspend blockers are released.  No polling.  If another user
>> > thread decides in the meantime that it needs to block the suspend, it
>> > sends a signal to the power manager process.
>> >
>> > In fact, other threads should signal the power manager process whenever
>> > they want to block or unblock suspends.  That way the power manager
>> > process can spend all its time sleeping, without doing any polling.
>>
>> I still see an issue here.  Namely, if the power manager is in user space and
>> it's signaled to suspend, it has to ask the kernel to do that, presumably by
>> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the
>> power manager waits until the block is released.  Now, it should go back and
>> check if user space still doesn't block suspend and if so, wait until the block
>> is released and start over.  With all suspend blockers in the kernel this
>> looping behavior is avoidable.
>
> I must be missing something.  In Arve's patch 1/8, if the system is in
> opportunistic suspend, and a wakeup event occurs but no suspend
> blockers get enabled by the handler, what causes the system to go back
> into suspend after the event is handled?  Isn't that a loop of some
> sort?
>

Yes it is a loop. I think what you are missing is that it only loops
repeatedly if the driver that aborts suspend does not use a suspend
blocker.

> And even if it isn't, so what?  What's wrong with looping behavior?

It is a significant power drain.

> Especially a loop that's as short as this one and spends almost all of
> its time sleeping.  Think how much harder it would be to write programs
> if you weren't allowed to use any loops.  :-)
>
> Alan Stern
>
>


-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:47 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
>> >> +To create a suspend blocker from user space, open the suspend_blocker
>> >> special
>> >> +device file:
>> >> +
>> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
>> >> +
>> >> +then optionally call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
>> >> +
>> >> +To activate the suspend blocker call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
>> >> +
>> >> +To deactivate it call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
>> >> +
>> >> +To destroy the suspend blocker, close the device:
>> >> +
>> >> +    close(fd);
>> >
>> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
>> > the SET_NAME thing if you really care.
>> >
>>
>> That would be very inefficient.
>
> How so? Anyway, since you admitted this thing isn't needed at all, I say
> we remove it altogether.
>

I also said it was useful. I don't think we should drop it just
because we can work around its absence.

-- 
Arve Hjønnevåg

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-05-26 at 03:47 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra <peterz@infradead.org>:
>> > On Fri, 2010-05-21 at 15:46 -0700, Arve Hjønnevåg wrote:
>> >> +To create a suspend blocker from user space, open the suspend_blocker
>> >> special
>> >> +device file:
>> >> +
>> >> +    fd = open("/dev/suspend_blocker", O_RDWR | O_CLOEXEC);
>> >> +
>> >> +then optionally call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_SET_NAME(strlen(name)), name);
>> >> +
>> >> +To activate the suspend blocker call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_BLOCK);
>> >> +
>> >> +To deactivate it call:
>> >> +
>> >> +    ioctl(fd, SUSPEND_BLOCKER_IOCTL_UNBLOCK);
>> >> +
>> >> +To destroy the suspend blocker, close the device:
>> >> +
>> >> +    close(fd);
>> >
>> > Urgh, please let the open() be BLOCK, the close() be UNBLOCK, and keep
>> > the SET_NAME thing if you really care.
>> >
>>
>> That would be very inefficient.
>
> How so? Anyway, since you admitted this thing isn't needed at all, I say
> we remove it altogether.
>

I also said it was useful. I don't think we should drop it just
because we can work around its absence.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> Really, what are you getting at? Do you deny that there are programs,
> >> that prevent a device from sleeping? (Just think of the bouncing
> >> cows app)
> >>
> >> And if you have two kernels, one with which your device is dead after 1
> >> hour and one with which your device is dead after 10 hours. Which would
> >> you prefer? I mean really... this is ridiculous.
> >
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends.
> 
> We never suspend when the screen is on. If the screen is off, I would
> not be upset if it suspends.

This is policy and platform specific. The OLPC can suspend with the
screen on. Should I write my app to know about this once for Android and
once for OLPC (and no doubt once for Apple). In the OLPC case cows could
indeed suspend to RAM between frames if the wakeup time was suitable.

My app simply should not have to know this sort of crap, that's the whole
point of an OS.

> > What you are essentially arguing for is for the
> > kernel to disobey the userspace.
> 
> No I'm not. User-space asked the kernel to suspend when possible.
> Suspend is an existing kernel feature. All opportunistic suspend adds
> is the ability to use it safely when there are wakeup event you cannot
> afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend
blockers are - or more precisely - the manner in which they express
intent from userspace. Opportunistic suspend is wonderful stuff for all
sorts of things and if it persuades people like netbook manufacturers to
think harder, and Linux driver authors to optimise their suspend/resume
paths we all win.

> Our actual stating point is this: Some systems can only enter their
> lowest power state from suspend. So we added an api that allowed us to
> use suspend without loosing wakeup events. Since suspending also
> improves our battery life on platforms that enter the same power state
> from idle and suspend and we already have a way to safely use suspend,
> we would be crazy not to use it.

Opportunistic suspend isn't special. Suspend is just a very deep idle. In
fact some of the low power states on processors look little different to
suspend - the OS executes a whole pile of CPU state saving and cache
flushing. It might be a hardware state machine, it might be buried in
firmware or it might be quite explicit (eg mrst). So we already have
differing degrees of doing additional work in different states.

User triggered suspend is a bit special in that the user is usually right
in that case to override the power management policy.

Note I'm not suggesting we run off and restructure all our power
management code to take this view right now. I'm suggesting we need a
clean 'opportunistic suspend is not special' view by user space. How the
kernel handles this is addressible later without app breakage, but only
if we get the interface wrong to begin with.

> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> > phone runs the appstore code via something like
> 
> Sandboxing is problematic on Android since there are a lot of cross
> process dependencies. When a call comes in I don't know where the name
> and picture to display comes from. With suspend blockers we block
> suspend when we get notified that we have an incoming call and we can
> call into any process and get a response.

But you can express user suspend blocking in this manner. Your call
incoming code would say 'I want good latency'. As someone needs good
latency the box won't suspend. If your approach is to start with an
initial 'anyone can set a low latency we don't care' then anyone can
block suspends.

Equally your call handling example is about latency not about suspend.
You want the phone to stay on, to fetch a picture and display it promptly.

So what are expressing

'I am using device 'screen' please keep it live'  (which may or may not
block suspend - see OLPC). I guess your display server and kernel support
manage this bit.

'I want the photo to appear in a resonable timescale'  (latency). It's
not a suspend question - an imaginary non suspend idle mode with a 20
second latency would be just as annoying yes ?

At the moment we have a very real bigger problem that your problem is
part of.

- Hard real time people want to be able to limit the CPU sleeping
  behaviour based upon what tasks are running

- Certain gaming types want their boxes to be good power citizens except
  when committing digital mass murder. Right now that involves wrapping
  the game in a script with bits occurring as root and that generally
  breaks if the game crashes so the script doesn't run nicely on exit

- Virtual machine people desperately want to see latency data to help
  schedule stuff in a power efficient manner.  In a virtual machine
  environment its vital information about how you schedule a virtual
  machine, whether now is a good time to live migrate it and how best to
  optimise power/performance on the server end.

- Some drivers want to constrain idling because they know
  platform/hardware stuff the core power management code doesn't (eg
  serial ports at high speed). We want that expressed in a way that keeps
  the power management code clean of such device knowledge

Now I don't care if we have an elegant kernel interface and Android uses
it as a big hammer - if that makes Android work well everyone can be
happy. What I don't want is to have a big hammer when it doesn't solve the
underlying big picture problem for everyone.

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a
  latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those
  later
- Suspend is just a power state

How does that fit your model and vision ?

> What about platforms that currently cannot enter low power states from
> idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to
support the user API and blissfully ignore it. Applications will ask for
various latency guarantees and of course always get them. The apps will be
portable, the device will be offering it's best behaviour and everyone
will be happy.

If your device only supports full on and suspend I don't see why
opportunistic suspend couldn't be provided assuming sufficient wakeup
support was present. It won't be the most exciting power management
policy to write but it's perfectly doable and the apps again will not need
recoding to handle it.

The latency goal data is also priceless for another consumer - in a
virtual machine environment its vital information about how you schedule
a virtual machine, whether now is a good time to live migrate it and how
best to optimise power/performance on the server end.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> Really, what are you getting at? Do you deny that there are programs,
> >> that prevent a device from sleeping? (Just think of the bouncing
> >> cows app)
> >>
> >> And if you have two kernels, one with which your device is dead after 1
> >> hour and one with which your device is dead after 10 hours. Which would
> >> you prefer? I mean really... this is ridiculous.
> >
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends.
> 
> We never suspend when the screen is on. If the screen is off, I would
> not be upset if it suspends.

This is policy and platform specific. The OLPC can suspend with the
screen on. Should I write my app to know about this once for Android and
once for OLPC (and no doubt once for Apple). In the OLPC case cows could
indeed suspend to RAM between frames if the wakeup time was suitable.

My app simply should not have to know this sort of crap, that's the whole
point of an OS.

> > What you are essentially arguing for is for the
> > kernel to disobey the userspace.
> 
> No I'm not. User-space asked the kernel to suspend when possible.
> Suspend is an existing kernel feature. All opportunistic suspend adds
> is the ability to use it safely when there are wakeup event you cannot
> afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend
blockers are - or more precisely - the manner in which they express
intent from userspace. Opportunistic suspend is wonderful stuff for all
sorts of things and if it persuades people like netbook manufacturers to
think harder, and Linux driver authors to optimise their suspend/resume
paths we all win.

> Our actual stating point is this: Some systems can only enter their
> lowest power state from suspend. So we added an api that allowed us to
> use suspend without loosing wakeup events. Since suspending also
> improves our battery life on platforms that enter the same power state
> from idle and suspend and we already have a way to safely use suspend,
> we would be crazy not to use it.

Opportunistic suspend isn't special. Suspend is just a very deep idle. In
fact some of the low power states on processors look little different to
suspend - the OS executes a whole pile of CPU state saving and cache
flushing. It might be a hardware state machine, it might be buried in
firmware or it might be quite explicit (eg mrst). So we already have
differing degrees of doing additional work in different states.

User triggered suspend is a bit special in that the user is usually right
in that case to override the power management policy.

Note I'm not suggesting we run off and restructure all our power
management code to take this view right now. I'm suggesting we need a
clean 'opportunistic suspend is not special' view by user space. How the
kernel handles this is addressible later without app breakage, but only
if we get the interface wrong to begin with.

> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> > phone runs the appstore code via something like
> 
> Sandboxing is problematic on Android since there are a lot of cross
> process dependencies. When a call comes in I don't know where the name
> and picture to display comes from. With suspend blockers we block
> suspend when we get notified that we have an incoming call and we can
> call into any process and get a response.

But you can express user suspend blocking in this manner. Your call
incoming code would say 'I want good latency'. As someone needs good
latency the box won't suspend. If your approach is to start with an
initial 'anyone can set a low latency we don't care' then anyone can
block suspends.

Equally your call handling example is about latency not about suspend.
You want the phone to stay on, to fetch a picture and display it promptly.

So what are expressing

'I am using device 'screen' please keep it live'  (which may or may not
block suspend - see OLPC). I guess your display server and kernel support
manage this bit.

'I want the photo to appear in a resonable timescale'  (latency). It's
not a suspend question - an imaginary non suspend idle mode with a 20
second latency would be just as annoying yes ?

At the moment we have a very real bigger problem that your problem is
part of.

- Hard real time people want to be able to limit the CPU sleeping
  behaviour based upon what tasks are running

- Certain gaming types want their boxes to be good power citizens except
  when committing digital mass murder. Right now that involves wrapping
  the game in a script with bits occurring as root and that generally
  breaks if the game crashes so the script doesn't run nicely on exit

- Virtual machine people desperately want to see latency data to help
  schedule stuff in a power efficient manner.  In a virtual machine
  environment its vital information about how you schedule a virtual
  machine, whether now is a good time to live migrate it and how best to
  optimise power/performance on the server end.

- Some drivers want to constrain idling because they know
  platform/hardware stuff the core power management code doesn't (eg
  serial ports at high speed). We want that expressed in a way that keeps
  the power management code clean of such device knowledge

Now I don't care if we have an elegant kernel interface and Android uses
it as a big hammer - if that makes Android work well everyone can be
happy. What I don't want is to have a big hammer when it doesn't solve the
underlying big picture problem for everyone.

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a
  latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those
  later
- Suspend is just a power state

How does that fit your model and vision ?

> What about platforms that currently cannot enter low power states from
> idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to
support the user API and blissfully ignore it. Applications will ask for
various latency guarantees and of course always get them. The apps will be
portable, the device will be offering it's best behaviour and everyone
will be happy.

If your device only supports full on and suspend I don't see why
opportunistic suspend couldn't be provided assuming sufficient wakeup
support was present. It won't be the most exciting power management
policy to write but it's perfectly doable and the apps again will not need
recoding to handle it.

The latency goal data is also priceless for another consumer - in a
virtual machine environment its vital information about how you schedule
a virtual machine, whether now is a good time to live migrate it and how
best to optimise power/performance on the server end.

Alan

Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Alan Cox]

> No, many suspend blockers protect data, not tasks. We block suspend
> when there are unprocessed input events in the kernel queue.
> User-space then blocks suspend before reading those events, and it
> blocks suspend using a different suspend blocker when its queue of
> processed events become not-empty.

That sounds to me like higher level user space implementation plus a
kernel driver imposing a power level limit.

The fact your suspend blockers as a user construct are tied to data isn't
neccessarily what the kernel needs to provide.

That aside we could equally provide latency constraints using a file
handle based semantic like your suspend blockers. That would make it
easier to do suspend blockers in those terms and provide an interface
that can be used for more elegant expression of desire.

I suggested setpidle() to keep resources tied and bounded to tasks and
to make SMP work nicely. I have no problem with the latency constraints
being floating file handles, although some thought would be needed as to
how that is then mapped to SMP.

The problem with an arbitary mapping is that if I have an 8 processor
system I might want to use the latency info to stuff tasks onto different
cores so that most of them are in a deeper idle than the others. I can't
do that unless I know who the latency constraint applies to. But
hopefully someone in scheduler land has bright ideas - eg could we keep a
per task variable and adjust it when people open/close blockers with the
assumption being anyone who has open a given constraint is bound by it
and nobody else is.

Might need it to be a constraintfs so you can open other people's
constraints but all the framework for that is there in the kernel too.

Alan

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:

> > I must be missing something.  In Arve's patch 1/8, if the system is in
> > opportunistic suspend, and a wakeup event occurs but no suspend
> > blockers get enabled by the handler, what causes the system to go back
> > into suspend after the event is handled?  Isn't that a loop of some
> > sort?
> >
> 
> Yes it is a loop. I think what you are missing is that it only loops
> repeatedly if the driver that aborts suspend does not use a suspend
> blocker.

You mean "the driver that handles the wakeup event".  I was asking what 
happened if suspend succeeded and then a wakeup occurred.  But yes, if 
a suspend blocker is used then its release causes another suspend 
attempt, with no looping.

> > And even if it isn't, so what?  What's wrong with looping behavior?
> 
> It is a significant power drain.

Not in the situation I was discussing.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:

> > I must be missing something.  In Arve's patch 1/8, if the system is in
> > opportunistic suspend, and a wakeup event occurs but no suspend
> > blockers get enabled by the handler, what causes the system to go back
> > into suspend after the event is handled?  Isn't that a loop of some
> > sort?
> >
> 
> Yes it is a loop. I think what you are missing is that it only loops
> repeatedly if the driver that aborts suspend does not use a suspend
> blocker.

You mean "the driver that handles the wakeup event".  I was asking what 
happened if suspend succeeded and then a wakeup occurred.  But yes, if 
a suspend blocker is used then its release causes another suspend 
attempt, with no looping.

> > And even if it isn't, so what?  What's wrong with looping behavior?
> 
> It is a significant power drain.

Not in the situation I was discussing.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Wed, 26 May 2010 15:30:58 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> >> Really, what are you getting at? Do you deny that there are programs,
>> >> that prevent a device from sleeping? (Just think of the bouncing
>> >> cows app)
>> >>
>> >> And if you have two kernels, one with which your device is dead after 1
>> >> hour and one with which your device is dead after 10 hours. Which would
>> >> you prefer? I mean really... this is ridiculous.
>> >
>> > The problem you have is that this is policy. If I have the device wired
>> > to a big screen and I want cows bouncing on it I'll be most upset if
>> > instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> This is policy and platform specific. The OLPC can suspend with the
> screen on. Should I write my app to know about this once for Android and
> once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from
idle and still wake up for the next timer or interrupt, then do that.
Suspend blockers should have not effect on this.

>
> My app simply should not have to know this sort of crap, that's the whole
> point of an OS.
>

Most apps does not have to know about this with opportunistic suspend
either. If the user is interacting with the device, we don't suspend.
If your apps needs to run when the user is not interacting with the
device, then you can block suspend.

>> > What you are essentially arguing for is for the
>> > kernel to disobey the userspace.
>>
>> No I'm not. User-space asked the kernel to suspend when possible.
>> Suspend is an existing kernel feature. All opportunistic suspend adds
>> is the ability to use it safely when there are wakeup event you cannot
>> afford to ignore.
>
> Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> blockers are - or more precisely - the manner in which they express
> intent from userspace. Opportunistic suspend is wonderful stuff for all
> sorts of things and if it persuades people like netbook manufacturers to
> think harder, and Linux driver authors to optimise their suspend/resume
> paths we all win.
>
>> Our actual stating point is this: Some systems can only enter their
>> lowest power state from suspend. So we added an api that allowed us to
>> use suspend without loosing wakeup events. Since suspending also
>> improves our battery life on platforms that enter the same power state
>> from idle and suspend and we already have a way to safely use suspend,
>> we would be crazy not to use it.
>
> Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular
timers stop, and only specially marked wakeup events can bring the
system back to the normal state.

> fact some of the low power states on processors look little different to
> suspend - the OS executes a whole pile of CPU state saving and cache
> flushing. It might be a hardware state machine, it might be buried in
> firmware or it might be quite explicit (eg mrst). So we already have
> differing degrees of doing additional work in different states.
>
> User triggered suspend is a bit special in that the user is usually right
> in that case to override the power management policy.
>

On a phone this is not the case. The user manually can toggle the
screen on and off, and we may or may not enter suspend when the screen
is off. If we forced suspend when the user turned the screen off, we
could miss phone calls.

> Note I'm not suggesting we run off and restructure all our power
> management code to take this view right now. I'm suggesting we need a
> clean 'opportunistic suspend is not special' view by user space. How the
> kernel handles this is addressible later without app breakage, but only
> if we get the interface wrong to begin with.
>
>> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
>> > phone runs the appstore code via something like
>>
>> Sandboxing is problematic on Android since there are a lot of cross
>> process dependencies. When a call comes in I don't know where the name
>> and picture to display comes from. With suspend blockers we block
>> suspend when we get notified that we have an incoming call and we can
>> call into any process and get a response.
>
> But you can express user suspend blocking in this manner. Your call
> incoming code would say 'I want good latency'. As someone needs good
> latency the box won't suspend. If your approach is to start with an
> initial 'anyone can set a low latency we don't care' then anyone can
> block suspends.
>
> Equally your call handling example is about latency not about suspend.
> You want the phone to stay on, to fetch a picture and display it promptly.
>

I don't think a latency api is the right way to express this since the
only latency values we would use is minimal-latency and any-latency.
What we are expressing is that this works need to happen now, even if
the user is not currently interacting with the device.

> So what are expressing
>
> 'I am using device 'screen' please keep it live'  (which may or may not
> block suspend - see OLPC). I guess your display server and kernel support
> manage this bit.
>
> 'I want the photo to appear in a resonable timescale'  (latency). It's
> not a suspend question - an imaginary non suspend idle mode with a 20
> second latency would be just as annoying yes ?
>
> At the moment we have a very real bigger problem that your problem is
> part of.
>
> - Hard real time people want to be able to limit the CPU sleeping
>  behaviour based upon what tasks are running
>
> - Certain gaming types want their boxes to be good power citizens except
>  when committing digital mass murder. Right now that involves wrapping
>  the game in a script with bits occurring as root and that generally
>  breaks if the game crashes so the script doesn't run nicely on exit
>
> - Virtual machine people desperately want to see latency data to help
>  schedule stuff in a power efficient manner.  In a virtual machine
>  environment its vital information about how you schedule a virtual
>  machine, whether now is a good time to live migrate it and how best to
>  optimise power/performance on the server end.
>
> - Some drivers want to constrain idling because they know
>  platform/hardware stuff the core power management code doesn't (eg
>  serial ports at high speed). We want that expressed in a way that keeps
>  the power management code clean of such device knowledge
>
> Now I don't care if we have an elegant kernel interface and Android uses
> it as a big hammer - if that makes Android work well everyone can be
> happy. What I don't want is to have a big hammer when it doesn't solve the
> underlying big picture problem for everyone.
>
> So my working position is summarised thusly
>
> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>  latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>  later
> - Suspend is just a power state
>
> How does that fit your model and vision ?
>

We have two main modes of operation. The user is interacting with the
device and tasks and timers should run as requested. And, the user is
not interacting with the device and the device should enter (and stay
in) low power states regardless of running tasks and timers. Since
some events (e.g. incoming phone call, alarm clock) will may cause the
user to start interacting with the device, they need special
treatment. A per thread latency api does not work for us. A global
latency api could work, but since would only use minimal latency or
any latency this seem like overkill. Also, with a global latency api,
how do I know it the requested latency is meant to improve the
experience while the user is interacting with the app, or if it meant
the app needs to run when the user is not interacting with the device.

>> What about platforms that currently cannot enter low power states from
>> idle? Do you remove suspend support from the kernel?
>
> I would actually expect a system that can't do any low power states to
> support the user API and blissfully ignore it. Applications will ask for

I don't think you understood what I asked. Currently most x86 systems
can enter much lower power states from suspend than they can from
idle. Are you suggesting that we remove suspend support from Linux and
try to enter the same power states on x86 from idle that we now enter
from suspend? It is not clear to me if this is possible.

> various latency guarantees and of course always get them. The apps will be
> portable, the device will be offering it's best behaviour and everyone
> will be happy.
>
> If your device only supports full on and suspend I don't see why
> opportunistic suspend couldn't be provided assuming sufficient wakeup
> support was present. It won't be the most exciting power management
> policy to write but it's perfectly doable and the apps again will not need
> recoding to handle it.
>
> The latency goal data is also priceless for another consumer - in a
> virtual machine environment its vital information about how you schedule
> a virtual machine, whether now is a good time to live migrate it and how
> best to optimise power/performance on the server end.
>
> Alan
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Wed, 26 May 2010 15:30:58 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> >> Really, what are you getting at? Do you deny that there are programs,
>> >> that prevent a device from sleeping? (Just think of the bouncing
>> >> cows app)
>> >>
>> >> And if you have two kernels, one with which your device is dead after 1
>> >> hour and one with which your device is dead after 10 hours. Which would
>> >> you prefer? I mean really... this is ridiculous.
>> >
>> > The problem you have is that this is policy. If I have the device wired
>> > to a big screen and I want cows bouncing on it I'll be most upset if
>> > instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> This is policy and platform specific. The OLPC can suspend with the
> screen on. Should I write my app to know about this once for Android and
> once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from
idle and still wake up for the next timer or interrupt, then do that.
Suspend blockers should have not effect on this.

>
> My app simply should not have to know this sort of crap, that's the whole
> point of an OS.
>

Most apps does not have to know about this with opportunistic suspend
either. If the user is interacting with the device, we don't suspend.
If your apps needs to run when the user is not interacting with the
device, then you can block suspend.

>> > What you are essentially arguing for is for the
>> > kernel to disobey the userspace.
>>
>> No I'm not. User-space asked the kernel to suspend when possible.
>> Suspend is an existing kernel feature. All opportunistic suspend adds
>> is the ability to use it safely when there are wakeup event you cannot
>> afford to ignore.
>
> Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> blockers are - or more precisely - the manner in which they express
> intent from userspace. Opportunistic suspend is wonderful stuff for all
> sorts of things and if it persuades people like netbook manufacturers to
> think harder, and Linux driver authors to optimise their suspend/resume
> paths we all win.
>
>> Our actual stating point is this: Some systems can only enter their
>> lowest power state from suspend. So we added an api that allowed us to
>> use suspend without loosing wakeup events. Since suspending also
>> improves our battery life on platforms that enter the same power state
>> from idle and suspend and we already have a way to safely use suspend,
>> we would be crazy not to use it.
>
> Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular
timers stop, and only specially marked wakeup events can bring the
system back to the normal state.

> fact some of the low power states on processors look little different to
> suspend - the OS executes a whole pile of CPU state saving and cache
> flushing. It might be a hardware state machine, it might be buried in
> firmware or it might be quite explicit (eg mrst). So we already have
> differing degrees of doing additional work in different states.
>
> User triggered suspend is a bit special in that the user is usually right
> in that case to override the power management policy.
>

On a phone this is not the case. The user manually can toggle the
screen on and off, and we may or may not enter suspend when the screen
is off. If we forced suspend when the user turned the screen off, we
could miss phone calls.

> Note I'm not suggesting we run off and restructure all our power
> management code to take this view right now. I'm suggesting we need a
> clean 'opportunistic suspend is not special' view by user space. How the
> kernel handles this is addressible later without app breakage, but only
> if we get the interface wrong to begin with.
>
>> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
>> > phone runs the appstore code via something like
>>
>> Sandboxing is problematic on Android since there are a lot of cross
>> process dependencies. When a call comes in I don't know where the name
>> and picture to display comes from. With suspend blockers we block
>> suspend when we get notified that we have an incoming call and we can
>> call into any process and get a response.
>
> But you can express user suspend blocking in this manner. Your call
> incoming code would say 'I want good latency'. As someone needs good
> latency the box won't suspend. If your approach is to start with an
> initial 'anyone can set a low latency we don't care' then anyone can
> block suspends.
>
> Equally your call handling example is about latency not about suspend.
> You want the phone to stay on, to fetch a picture and display it promptly.
>

I don't think a latency api is the right way to express this since the
only latency values we would use is minimal-latency and any-latency.
What we are expressing is that this works need to happen now, even if
the user is not currently interacting with the device.

> So what are expressing
>
> 'I am using device 'screen' please keep it live'  (which may or may not
> block suspend - see OLPC). I guess your display server and kernel support
> manage this bit.
>
> 'I want the photo to appear in a resonable timescale'  (latency). It's
> not a suspend question - an imaginary non suspend idle mode with a 20
> second latency would be just as annoying yes ?
>
> At the moment we have a very real bigger problem that your problem is
> part of.
>
> - Hard real time people want to be able to limit the CPU sleeping
>  behaviour based upon what tasks are running
>
> - Certain gaming types want their boxes to be good power citizens except
>  when committing digital mass murder. Right now that involves wrapping
>  the game in a script with bits occurring as root and that generally
>  breaks if the game crashes so the script doesn't run nicely on exit
>
> - Virtual machine people desperately want to see latency data to help
>  schedule stuff in a power efficient manner.  In a virtual machine
>  environment its vital information about how you schedule a virtual
>  machine, whether now is a good time to live migrate it and how best to
>  optimise power/performance on the server end.
>
> - Some drivers want to constrain idling because they know
>  platform/hardware stuff the core power management code doesn't (eg
>  serial ports at high speed). We want that expressed in a way that keeps
>  the power management code clean of such device knowledge
>
> Now I don't care if we have an elegant kernel interface and Android uses
> it as a big hammer - if that makes Android work well everyone can be
> happy. What I don't want is to have a big hammer when it doesn't solve the
> underlying big picture problem for everyone.
>
> So my working position is summarised thusly
>
> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>  latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>  later
> - Suspend is just a power state
>
> How does that fit your model and vision ?
>

We have two main modes of operation. The user is interacting with the
device and tasks and timers should run as requested. And, the user is
not interacting with the device and the device should enter (and stay
in) low power states regardless of running tasks and timers. Since
some events (e.g. incoming phone call, alarm clock) will may cause the
user to start interacting with the device, they need special
treatment. A per thread latency api does not work for us. A global
latency api could work, but since would only use minimal latency or
any latency this seem like overkill. Also, with a global latency api,
how do I know it the requested latency is meant to improve the
experience while the user is interacting with the app, or if it meant
the app needs to run when the user is not interacting with the device.

>> What about platforms that currently cannot enter low power states from
>> idle? Do you remove suspend support from the kernel?
>
> I would actually expect a system that can't do any low power states to
> support the user API and blissfully ignore it. Applications will ask for

I don't think you understood what I asked. Currently most x86 systems
can enter much lower power states from suspend than they can from
idle. Are you suggesting that we remove suspend support from Linux and
try to enter the same power states on x86 from idle that we now enter
from suspend? It is not clear to me if this is possible.

> various latency guarantees and of course always get them. The apps will be
> portable, the device will be offering it's best behaviour and everyone
> will be happy.
>
> If your device only supports full on and suspend I don't see why
> opportunistic suspend couldn't be provided assuming sufficient wakeup
> support was present. It won't be the most exciting power management
> policy to write but it's perfectly doable and the apps again will not need
> recoding to handle it.
>
> The latency goal data is also priceless for another consumer - in a
> virtual machine environment its vital information about how you schedule
> a virtual machine, whether now is a good time to live migrate it and how
> best to optimise power/performance on the server end.
>
> Alan
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Wed, 26 May 2010 15:30:58 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> >> Really, what are you getting at? Do you deny that there are programs,
>> >> that prevent a device from sleeping? (Just think of the bouncing
>> >> cows app)
>> >>
>> >> And if you have two kernels, one with which your device is dead after 1
>> >> hour and one with which your device is dead after 10 hours. Which would
>> >> you prefer? I mean really... this is ridiculous.
>> >
>> > The problem you have is that this is policy. If I have the device wired
>> > to a big screen and I want cows bouncing on it I'll be most upset if
>> > instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> This is policy and platform specific. The OLPC can suspend with the
> screen on. Should I write my app to know about this once for Android and
> once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from
idle and still wake up for the next timer or interrupt, then do that.
Suspend blockers should have not effect on this.

>
> My app simply should not have to know this sort of crap, that's the whole
> point of an OS.
>

Most apps does not have to know about this with opportunistic suspend
either. If the user is interacting with the device, we don't suspend.
If your apps needs to run when the user is not interacting with the
device, then you can block suspend.

>> > What you are essentially arguing for is for the
>> > kernel to disobey the userspace.
>>
>> No I'm not. User-space asked the kernel to suspend when possible.
>> Suspend is an existing kernel feature. All opportunistic suspend adds
>> is the ability to use it safely when there are wakeup event you cannot
>> afford to ignore.
>
> Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> blockers are - or more precisely - the manner in which they express
> intent from userspace. Opportunistic suspend is wonderful stuff for all
> sorts of things and if it persuades people like netbook manufacturers to
> think harder, and Linux driver authors to optimise their suspend/resume
> paths we all win.
>
>> Our actual stating point is this: Some systems can only enter their
>> lowest power state from suspend. So we added an api that allowed us to
>> use suspend without loosing wakeup events. Since suspending also
>> improves our battery life on platforms that enter the same power state
>> from idle and suspend and we already have a way to safely use suspend,
>> we would be crazy not to use it.
>
> Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular
timers stop, and only specially marked wakeup events can bring the
system back to the normal state.

> fact some of the low power states on processors look little different to
> suspend - the OS executes a whole pile of CPU state saving and cache
> flushing. It might be a hardware state machine, it might be buried in
> firmware or it might be quite explicit (eg mrst). So we already have
> differing degrees of doing additional work in different states.
>
> User triggered suspend is a bit special in that the user is usually right
> in that case to override the power management policy.
>

On a phone this is not the case. The user manually can toggle the
screen on and off, and we may or may not enter suspend when the screen
is off. If we forced suspend when the user turned the screen off, we
could miss phone calls.

> Note I'm not suggesting we run off and restructure all our power
> management code to take this view right now. I'm suggesting we need a
> clean 'opportunistic suspend is not special' view by user space. How the
> kernel handles this is addressible later without app breakage, but only
> if we get the interface wrong to begin with.
>
>> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
>> > phone runs the appstore code via something like
>>
>> Sandboxing is problematic on Android since there are a lot of cross
>> process dependencies. When a call comes in I don't know where the name
>> and picture to display comes from. With suspend blockers we block
>> suspend when we get notified that we have an incoming call and we can
>> call into any process and get a response.
>
> But you can express user suspend blocking in this manner. Your call
> incoming code would say 'I want good latency'. As someone needs good
> latency the box won't suspend. If your approach is to start with an
> initial 'anyone can set a low latency we don't care' then anyone can
> block suspends.
>
> Equally your call handling example is about latency not about suspend.
> You want the phone to stay on, to fetch a picture and display it promptly.
>

I don't think a latency api is the right way to express this since the
only latency values we would use is minimal-latency and any-latency.
What we are expressing is that this works need to happen now, even if
the user is not currently interacting with the device.

> So what are expressing
>
> 'I am using device 'screen' please keep it live'  (which may or may not
> block suspend - see OLPC). I guess your display server and kernel support
> manage this bit.
>
> 'I want the photo to appear in a resonable timescale'  (latency). It's
> not a suspend question - an imaginary non suspend idle mode with a 20
> second latency would be just as annoying yes ?
>
> At the moment we have a very real bigger problem that your problem is
> part of.
>
> - Hard real time people want to be able to limit the CPU sleeping
>  behaviour based upon what tasks are running
>
> - Certain gaming types want their boxes to be good power citizens except
>  when committing digital mass murder. Right now that involves wrapping
>  the game in a script with bits occurring as root and that generally
>  breaks if the game crashes so the script doesn't run nicely on exit
>
> - Virtual machine people desperately want to see latency data to help
>  schedule stuff in a power efficient manner.  In a virtual machine
>  environment its vital information about how you schedule a virtual
>  machine, whether now is a good time to live migrate it and how best to
>  optimise power/performance on the server end.
>
> - Some drivers want to constrain idling because they know
>  platform/hardware stuff the core power management code doesn't (eg
>  serial ports at high speed). We want that expressed in a way that keeps
>  the power management code clean of such device knowledge
>
> Now I don't care if we have an elegant kernel interface and Android uses
> it as a big hammer - if that makes Android work well everyone can be
> happy. What I don't want is to have a big hammer when it doesn't solve the
> underlying big picture problem for everyone.
>
> So my working position is summarised thusly
>
> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>  latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>  later
> - Suspend is just a power state
>
> How does that fit your model and vision ?
>

We have two main modes of operation. The user is interacting with the
device and tasks and timers should run as requested. And, the user is
not interacting with the device and the device should enter (and stay
in) low power states regardless of running tasks and timers. Since
some events (e.g. incoming phone call, alarm clock) will may cause the
user to start interacting with the device, they need special
treatment. A per thread latency api does not work for us. A global
latency api could work, but since would only use minimal latency or
any latency this seem like overkill. Also, with a global latency api,
how do I know it the requested latency is meant to improve the
experience while the user is interacting with the app, or if it meant
the app needs to run when the user is not interacting with the device.

>> What about platforms that currently cannot enter low power states from
>> idle? Do you remove suspend support from the kernel?
>
> I would actually expect a system that can't do any low power states to
> support the user API and blissfully ignore it. Applications will ask for

I don't think you understood what I asked. Currently most x86 systems
can enter much lower power states from suspend than they can from
idle. Are you suggesting that we remove suspend support from Linux and
try to enter the same power states on x86 from idle that we now enter
from suspend? It is not clear to me if this is possible.

> various latency guarantees and of course always get them. The apps will be
> portable, the device will be offering it's best behaviour and everyone
> will be happy.
>
> If your device only supports full on and suspend I don't see why
> opportunistic suspend couldn't be provided assuming sufficient wakeup
> support was present. It won't be the most exciting power management
> policy to write but it's perfectly doable and the apps again will not need
> recoding to handle it.
>
> The latency goal data is also priceless for another consumer - in a
> virtual machine environment its vital information about how you schedule
> a virtual machine, whether now is a good time to live migrate it and how
> best to optimise power/performance on the server end.
>
> Alan
>



-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>
>> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> > opportunistic suspend, and a wakeup event occurs but no suspend
>> > blockers get enabled by the handler, what causes the system to go back
>> > into suspend after the event is handled?  Isn't that a loop of some
>> > sort?
>> >
>>
>> Yes it is a loop. I think what you are missing is that it only loops
>> repeatedly if the driver that aborts suspend does not use a suspend
>> blocker.
>
> You mean "the driver that handles the wakeup event".  I was asking what
> happened if suspend succeeded and then a wakeup occurred.  But yes, if
> a suspend blocker is used then its release causes another suspend
> attempt, with no looping.
>
>> > And even if it isn't, so what?  What's wrong with looping behavior?
>>
>> It is a significant power drain.
>
> Not in the situation I was discussing.
>

If you meant it spend most of the time suspended, then I agree. It
only wastes power when a driver blocks suspend by returning an error
from its suspend hook and we are forced to loop doing no useful work.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>
>> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> > opportunistic suspend, and a wakeup event occurs but no suspend
>> > blockers get enabled by the handler, what causes the system to go back
>> > into suspend after the event is handled?  Isn't that a loop of some
>> > sort?
>> >
>>
>> Yes it is a loop. I think what you are missing is that it only loops
>> repeatedly if the driver that aborts suspend does not use a suspend
>> blocker.
>
> You mean "the driver that handles the wakeup event".  I was asking what
> happened if suspend succeeded and then a wakeup occurred.  But yes, if
> a suspend blocker is used then its release causes another suspend
> attempt, with no looping.
>
>> > And even if it isn't, so what?  What's wrong with looping behavior?
>>
>> It is a significant power drain.
>
> Not in the situation I was discussing.
>

If you meant it spend most of the time suspended, then I agree. It
only wastes power when a driver blocks suspend by returning an error
from its suspend hook and we are forced to loop doing no useful work.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > Your approach definitely sounds better than the current solution.
> > What about mapping suspend blocker functionality later on, when this
> > interface exists, on to this new approach and deprecating it?
> 
> What about coming back after some while with the appropriate solution
> when it's ready instead of stubbornly pushing crap?
> 
> ~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers
is already in the kernel. It's just an historical mistake that they are
not in the linux kernel's hosted on kernel.org. 
So why don't we do what we always do? Improve existing interfaces step
by step? 

Top Down approaches fail from time to time. Also it is not clear, that
that proposed interface works for the use cases. This has to be proven
by providing an implementation. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > Your approach definitely sounds better than the current solution.
> > What about mapping suspend blocker functionality later on, when this
> > interface exists, on to this new approach and deprecating it?
> 
> What about coming back after some while with the appropriate solution
> when it's ready instead of stubbornly pushing crap?
> 
> ~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers
is already in the kernel. It's just an historical mistake that they are
not in the linux kernel's hosted on kernel.org. 
So why don't we do what we always do? Improve existing interfaces step
by step? 

Top Down approaches fail from time to time. Also it is not clear, that
that proposed interface works for the use cases. This has to be proven
by providing an implementation. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 23:09:43 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> We now have suggestions how to do the job properly so the right thing is
> probably to go and explore those suggestions not merge crap.
> 
> Merging crap won't help anyway. The rest of the kernel community can
> still simply stonewall those interfaces, and a volunteer community has
> ways of dealing with abuse of process, notably by simply not getting
> around to, or implementing things directly contrary to the crap bits.
> 
> So it's not even in the interest of people to play political games. Even
> if you get away with in the short term the people who rely on the junk
> will end up out on a limb and holding the baby when the crap hits the fan
> (see reiserfs)
> 
> Alan

I'm not interested in "abusing processes". I just think, this is in
limbo for too long already.
Just decide something. One way or the other. The world will continue.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 23:09:43 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> We now have suggestions how to do the job properly so the right thing is
> probably to go and explore those suggestions not merge crap.
> 
> Merging crap won't help anyway. The rest of the kernel community can
> still simply stonewall those interfaces, and a volunteer community has
> ways of dealing with abuse of process, notably by simply not getting
> around to, or implementing things directly contrary to the crap bits.
> 
> So it's not even in the interest of people to play political games. Even
> if you get away with in the short term the people who rely on the junk
> will end up out on a limb and holding the baby when the crap hits the fan
> (see reiserfs)
> 
> Alan

I'm not interested in "abusing processes". I just think, this is in
limbo for too long already.
Just decide something. One way or the other. The world will continue.

Cheers,
Flo

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Wed, 26 May 2010 14:20:51 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> 
> > I fail to see why. In both cases the woken userspace will contact a
> > central governing task, either the kernel or the userspace suspend
> > manager, and inform it there is work to be done, and please don't
> > suspend now.
> 
> Thinking about this, you're right - we don't have to wait, but that does 
> result in another problem. Imagine we get two wakeup events 
> approximately simultaneously. In the kernel-level universe the kernel 
> knows when both have been handled. In the user-level universe, we may 
> have one task schedule, bump the count, handle the event, drop the count 
> and then we attempt a suspend again because the second event handler 
> hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> immediately bounce back up. That's kind of wasteful, although it'd be 
> somewhat mitigated by checking that right at the top of suspend entry 
> and returning -EAGAIN or similar.
> 

(I'm coming a little late to this party, so excuse me if I say something that
has already been covered however...)

The above triggers a sequence of thoughts which (When they settled down) look
a bit like this.

At the hardware level, there is a thing that we could call a "suspend
blocker".  It is an interrupt (presumably level-triggered) that causes the
processor to come out of suspend, or not to go into it.

Maybe it makes sense to export a similar thing from the kernel to user-space.
When any event happens that would wake the device (and drivers need to know
about these already), it would present something to user-space to say that
the event happened.

When user-space processes the event, it clears the event indicator.

When there are no more current event indicators, userspace is allowed to
request a suspend.  Obviously this could fail as an event could happen at any
moment, but the same is true when the kernel asks the device to suspend, an
interrupt might happen immediately to stop it.  But in either case an event
will be reported.  So when userspace requests a suspend and it fails, it
will see events reported and so will wait for them to be handled.

I imagine a sysfs directory with files that appear when events are pending.
We could have some separate mechanism for user-space processes to request
that the suspend-daemon not suspend.  Then it suspends whenever there are no
pending requests from user-space or from the kernel.

The advantage of this model of suspend-blockers is that it is a close
analogue for something that already exists in hardware so it isn't really
creating new concepts, just giving the Linux virtual-machine features that
have proved themselves in physical machines.

The cost is that any wake-up event needs to not only be handled, but also
explicitly acknowledged by clearing the relevant suspend-blocker (i.e.
removing the file from sysfs, or whatever interface was ultimately chosen).
I'm hoping that isn't a big cost.

NeilBrown

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Wed, 26 May 2010 14:20:51 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> 
> > I fail to see why. In both cases the woken userspace will contact a
> > central governing task, either the kernel or the userspace suspend
> > manager, and inform it there is work to be done, and please don't
> > suspend now.
> 
> Thinking about this, you're right - we don't have to wait, but that does 
> result in another problem. Imagine we get two wakeup events 
> approximately simultaneously. In the kernel-level universe the kernel 
> knows when both have been handled. In the user-level universe, we may 
> have one task schedule, bump the count, handle the event, drop the count 
> and then we attempt a suspend again because the second event handler 
> hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> immediately bounce back up. That's kind of wasteful, although it'd be 
> somewhat mitigated by checking that right at the top of suspend entry 
> and returning -EAGAIN or similar.
> 

(I'm coming a little late to this party, so excuse me if I say something that
has already been covered however...)

The above triggers a sequence of thoughts which (When they settled down) look
a bit like this.

At the hardware level, there is a thing that we could call a "suspend
blocker".  It is an interrupt (presumably level-triggered) that causes the
processor to come out of suspend, or not to go into it.

Maybe it makes sense to export a similar thing from the kernel to user-space.
When any event happens that would wake the device (and drivers need to know
about these already), it would present something to user-space to say that
the event happened.

When user-space processes the event, it clears the event indicator.

When there are no more current event indicators, userspace is allowed to
request a suspend.  Obviously this could fail as an event could happen at any
moment, but the same is true when the kernel asks the device to suspend, an
interrupt might happen immediately to stop it.  But in either case an event
will be reported.  So when userspace requests a suspend and it fails, it
will see events reported and so will wait for them to be handled.

I imagine a sysfs directory with files that appear when events are pending.
We could have some separate mechanism for user-space processes to request
that the suspend-daemon not suspend.  Then it suspends whenever there are no
pending requests from user-space or from the kernel.

The advantage of this model of suspend-blockers is that it is a close
analogue for something that already exists in hardware so it isn't really
creating new concepts, just giving the Linux virtual-machine features that
have proved themselves in physical machines.

The cost is that any wake-up event needs to not only be handled, but also
explicitly acknowledged by clearing the relevant suspend-blocker (i.e.
removing the file from sysfs, or whatever interface was ultimately chosen).
I'm hoping that isn't a big cost.

NeilBrown

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Wed, 26 May 2010 12:21:02 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
> > > With a single suspend manager process that manages the suspend state you
> > > can achieve the same goal.
> > >
> > 
> > Yes we don't need the /dev interface, but it is useful. Without it any
> > program that needs to block suspend has to make a blocking ipc call
> > into the suspend manager process. Android already does this for java
> > code, but system processes written in C block suspend directly with
> > the kernel since they cannot use the java APIs. 
> 
> So provide a C interface to it as well?
> 
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
> 
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

I fail to understand the modern fascination with complex IPC mechanisms.

If you have a userspace process that initiates suspends, and you want other
user-space processes to be able to block that suspend, then I would suggest
the use of a lock-file.  /var/run/suspend/blocked maybe.

To block suspend, you open the file and get a read lock.
To initiate a suspend you take a write-lock (blocking if necessary), then
ask the kernel to suspend.
To restrict access to particular users you use permissions - either group
based or ACLs (or both).
This is all easy to do from C or python or perl or presumably even java..
(I use this mechanism on my Freerunner and even have shell scripts that
happily prevent suspend).

NeilBrown

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Wed, 26 May 2010 12:21:02 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
> > > With a single suspend manager process that manages the suspend state you
> > > can achieve the same goal.
> > >
> > 
> > Yes we don't need the /dev interface, but it is useful. Without it any
> > program that needs to block suspend has to make a blocking ipc call
> > into the suspend manager process. Android already does this for java
> > code, but system processes written in C block suspend directly with
> > the kernel since they cannot use the java APIs. 
> 
> So provide a C interface to it as well?
> 
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
> 
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

I fail to understand the modern fascination with complex IPC mechanisms.

If you have a userspace process that initiates suspends, and you want other
user-space processes to be able to block that suspend, then I would suggest
the use of a lock-file.  /var/run/suspend/blocked maybe.

To block suspend, you open the file and get a read lock.
To initiate a suspend you take a write-lock (blocking if necessary), then
ask the kernel to suspend.
To restrict access to particular users you use permissions - either group
based or ACLs (or both).
This is all easy to do from C or python or perl or presumably even java..
(I use this mechanism on my Freerunner and even have shell scripts that
happily prevent suspend).

NeilBrown
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/27 Arve Hjønnevåg <arve@android.com>:
> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> Really, what are you getting at? Do you deny that there are programs,
>>> that prevent a device from sleeping? (Just think of the bouncing
>>> cows app)
>>>
>>> And if you have two kernels, one with which your device is dead after 1
>>> hour and one with which your device is dead after 10 hours. Which would
>>> you prefer? I mean really... this is ridiculous.
>>
>> The problem you have is that this is policy. If I have the device wired
>> to a big screen and I want cows bouncing on it I'll be most upset if
>> instead it suspends.
>
> We never suspend when the screen is on. If the screen is off, I would
> not be upset if it suspends.

That's /wrong/. What if you have an active download ongoing when the
screen is off? This ugly simplistic approach is one of the worst
things in Android.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/27 Arve Hjønnevåg <arve@android.com>:
> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> Really, what are you getting at? Do you deny that there are programs,
>>> that prevent a device from sleeping? (Just think of the bouncing
>>> cows app)
>>>
>>> And if you have two kernels, one with which your device is dead after 1
>>> hour and one with which your device is dead after 10 hours. Which would
>>> you prefer? I mean really... this is ridiculous.
>>
>> The problem you have is that this is policy. If I have the device wired
>> to a big screen and I want cows bouncing on it I'll be most upset if
>> instead it suspends.
>
> We never suspend when the screen is on. If the screen is off, I would
> not be upset if it suspends.

That's /wrong/. What if you have an active download ongoing when the
screen is off? This ugly simplistic approach is one of the worst
things in Android.

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Thu, May 27, 2010 at 7:14 AM, Florian Mickler <florian@mickler.org> wrote:

> I'm not interested in "abusing processes". I just think, this is in
> limbo for too long already.
> Just decide something. One way or the other. The world will continue.

Oh man, you rule the world eh? :)

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Thu, May 27, 2010 at 7:14 AM, Florian Mickler <florian@mickler.org> wrote:

> I'm not interested in "abusing processes". I just think, this is in
> limbo for too long already.
> Just decide something. One way or the other. The world will continue.

Oh man, you rule the world eh? :)

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/27 Vitaly Wool <vitalywool@gmail.com>:
> 2010/5/27 Arve Hjønnevåg <arve@android.com>:
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>>> Really, what are you getting at? Do you deny that there are programs,
>>>> that prevent a device from sleeping? (Just think of the bouncing
>>>> cows app)
>>>>
>>>> And if you have two kernels, one with which your device is dead after 1
>>>> hour and one with which your device is dead after 10 hours. Which would
>>>> you prefer? I mean really... this is ridiculous.
>>>
>>> The problem you have is that this is policy. If I have the device wired
>>> to a big screen and I want cows bouncing on it I'll be most upset if
>>> instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> That's /wrong/. What if you have an active download ongoing when the
> screen is off? This ugly simplistic approach is one of the worst
> things in Android.

On android we have code that blocks suspend while downloading. On
non-android systems I have used if the download has not finished by
the time the auto-sleep timeout kicks in, the system will suspend and
the download halts.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/27 Vitaly Wool <vitalywool@gmail.com>:
> 2010/5/27 Arve Hjønnevåg <arve@android.com>:
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>>> Really, what are you getting at? Do you deny that there are programs,
>>>> that prevent a device from sleeping? (Just think of the bouncing
>>>> cows app)
>>>>
>>>> And if you have two kernels, one with which your device is dead after 1
>>>> hour and one with which your device is dead after 10 hours. Which would
>>>> you prefer? I mean really... this is ridiculous.
>>>
>>> The problem you have is that this is policy. If I have the device wired
>>> to a big screen and I want cows bouncing on it I'll be most upset if
>>> instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> That's /wrong/. What if you have an active download ongoing when the
> screen is off? This ugly simplistic approach is one of the worst
> things in Android.

On android we have code that blocks suspend while downloading. On
non-android systems I have used if the download has not finished by
the time the auto-sleep timeout kicks in, the system will suspend and
the download halts.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Bernd Petrovitsch]

On Mit, 2010-05-26 at 21:15 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 19:28:24 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > Besides that it is not linux system at all?
> 
> I believe the kernel to be a layer between userspace and hardware. What
> business is it to the kernel if it runs whatever android
> uses as init process or /bin/bash, sys-v-init or systemd?

The kernel has no business and doesn't care. But precisely that is the
reason to clearly separate policy from means. And that separation is not
done in a good way by a loosely-defined API but by a (well-defined)
kernel-API which allows user-space so implement the policy (whatever it
might feel) by using the means (wiht appopriate parameters).
So the (kernel-)API should not use policy-defined (read: user-space)
semantics/values - plain simply because they will change (in no time).
But the kernel must use policy-independent semantics/values - if only
the suspend/wakeup-latency or whatever technically makes sense.
Perhaps some "will/want to be waken up every 0.1 second" makes sense for
periodic jobs.

> There is this thing called choice. 
>
> > Yes, with custom userspace it works extremely nicely.
> > 
> > Had anyone even tried running oportunistic suspend on normal desktop?
>
> I don't think this is a valid concern. Just because current linux/gnu

A lot of stuff is not (or no longer) implemented because it's - plain
simply - a bad idea in the first place.
Other than that: Linux/GNU-systems come from the server and desktop
world where power is not an important part. And laptop producers
obviously didn't care enough ...
And you do realize that in the non-embedded (and non-Apple) world the
user-space is not controlled by one entity in any way.
So forcing "good apps" vs "bad apps" doesn't workout - except you have
direct feedback like "powertop" which makes it easy for everyone
(especially the users) to rate the apps.
So the kernel actually must have means to do that. If user-space defines
the semantics of the API, the kernel can't do that because user-space is
always right.

> systems don't implement the userspace part of this interface doesn't
> mean it is useless or broken. 

Just because Android designed and/or implements it doesn't mean it's not
broken (in the medium to long run).
So what?

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Bernd Petrovitsch]

On Mit, 2010-05-26 at 21:15 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 19:28:24 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > Besides that it is not linux system at all?
> 
> I believe the kernel to be a layer between userspace and hardware. What
> business is it to the kernel if it runs whatever android
> uses as init process or /bin/bash, sys-v-init or systemd?

The kernel has no business and doesn't care. But precisely that is the
reason to clearly separate policy from means. And that separation is not
done in a good way by a loosely-defined API but by a (well-defined)
kernel-API which allows user-space so implement the policy (whatever it
might feel) by using the means (wiht appopriate parameters).
So the (kernel-)API should not use policy-defined (read: user-space)
semantics/values - plain simply because they will change (in no time).
But the kernel must use policy-independent semantics/values - if only
the suspend/wakeup-latency or whatever technically makes sense.
Perhaps some "will/want to be waken up every 0.1 second" makes sense for
periodic jobs.

> There is this thing called choice. 
>
> > Yes, with custom userspace it works extremely nicely.
> > 
> > Had anyone even tried running oportunistic suspend on normal desktop?
>
> I don't think this is a valid concern. Just because current linux/gnu

A lot of stuff is not (or no longer) implemented because it's - plain
simply - a bad idea in the first place.
Other than that: Linux/GNU-systems come from the server and desktop
world where power is not an important part. And laptop producers
obviously didn't care enough ...
And you do realize that in the non-embedded (and non-Apple) world the
user-space is not controlled by one entity in any way.
So forcing "good apps" vs "bad apps" doesn't workout - except you have
direct feedback like "powertop" which makes it easy for everyone
(especially the users) to rate the apps.
So the kernel actually must have means to do that. If user-space defines
the semantics of the API, the kernel can't do that because user-space is
always right.

> systems don't implement the userspace part of this interface doesn't
> mean it is useless or broken. 

Just because Android designed and/or implements it doesn't mean it's not
broken (in the medium to long run).
So what?

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Bernd Petrovitsch]

On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
[...]
> > Darn, _we_ have to deal with that forever as it sets a crappy user
> > space ABI in stone.
> 
> I really don't see how it is ... the ABI comes with a switch that allows
> it to be disabled, so only platforms wishing to use it have to support
> it.  Even on those platforms that do support it, we can translate most

You completely missed the point: The crappy user interface - and
interferences with pother subsystems - must be maintained for ages - and
that is independent if one uses it or not. Even worse if it's not widely
used.

> of it into pm QoS stuff and if one day someone solves the rogue app
> problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it
out of tree.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Bernd Petrovitsch]

On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote:
> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
[...]
> > Darn, _we_ have to deal with that forever as it sets a crappy user
> > space ABI in stone.
> 
> I really don't see how it is ... the ABI comes with a switch that allows
> it to be disabled, so only platforms wishing to use it have to support
> it.  Even on those platforms that do support it, we can translate most

You completely missed the point: The crappy user interface - and
interferences with pother subsystems - must be maintained for ages - and
that is independent if one uses it or not. Even worse if it's not widely
used.

> of it into pm QoS stuff and if one day someone solves the rogue app
> problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it
out of tree.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Wed, May 26, 2010 at 3:54 PM, Florian Mickler <florian@mickler.org> wrote:
> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other. So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.
>
> All points about the impact on the kernel have already been raised. So
> you should be happy there.
>
> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

Let's get rid of hypothetical uses in the future: suspend blockers is
_only_ used by Android user-space. Nobody else has expressed any
intention of using them.

> Also I expect there to be synergies between android development and
> mainline kernel development _only_ if android development can use
> mainline kernel.

That's like saying "there can only be synergies between linux real
time and mainline _only_ if RT development can use mainline".

I can give you my experience at Nokia... can you use mainline on any
of the Maemo devices? No. You have to patch the kernel heavily, to be
able to kind-of run the official user-space, or you have to use a
different user-space.

Does that prevent synergies? No. As Brian Swetland and Daniel Walker
already expressed before; you can run mainline kernel with debian on
Android phones.

It would be nice to run Android user-space, or parts of it on mainline
kernels, but if it's not possible, that's a deficiency on Android's
design; Maemo/Moblin/Meego are good players in the linux ecosystem so
you can re-use parts of the system on typical desktops (in fact many
are coming from there), and there are community distributions re-using
those parts and running just fine on mainline kernels.

Sure, it would be easier for Android developers if all their crap was
in the mainline, but even then there are no guarantees of anything.
Just like any other linux phone, you'll probably need to add patches
for 3D drivers, DSP, or other hardware acceleration, missing
board-specfic patches, and bunch of hacks.

So if you have to add all those patches anyway, what's the problem of
having to add the suspend block patches?

Why do some Android developers think they can be the exception and
have patches merged in the core of linux _only_ for their specific
user-space, and their specific drivers?

If you separate suspend blockers from Android, and judge them on their
technical merit, I don't see a single person saying this is a good
idea, we'll switch all our user-space to use them.

-- 
Felipe Contreras

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Wed, May 26, 2010 at 3:54 PM, Florian Mickler <florian@mickler.org> wrote:
> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other. So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.
>
> All points about the impact on the kernel have already been raised. So
> you should be happy there.
>
> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

Let's get rid of hypothetical uses in the future: suspend blockers is
_only_ used by Android user-space. Nobody else has expressed any
intention of using them.

> Also I expect there to be synergies between android development and
> mainline kernel development _only_ if android development can use
> mainline kernel.

That's like saying "there can only be synergies between linux real
time and mainline _only_ if RT development can use mainline".

I can give you my experience at Nokia... can you use mainline on any
of the Maemo devices? No. You have to patch the kernel heavily, to be
able to kind-of run the official user-space, or you have to use a
different user-space.

Does that prevent synergies? No. As Brian Swetland and Daniel Walker
already expressed before; you can run mainline kernel with debian on
Android phones.

It would be nice to run Android user-space, or parts of it on mainline
kernels, but if it's not possible, that's a deficiency on Android's
design; Maemo/Moblin/Meego are good players in the linux ecosystem so
you can re-use parts of the system on typical desktops (in fact many
are coming from there), and there are community distributions re-using
those parts and running just fine on mainline kernels.

Sure, it would be easier for Android developers if all their crap was
in the mainline, but even then there are no guarantees of anything.
Just like any other linux phone, you'll probably need to add patches
for 3D drivers, DSP, or other hardware acceleration, missing
board-specfic patches, and bunch of hacks.

So if you have to add all those patches anyway, what's the problem of
having to add the suspend block patches?

Why do some Android developers think they can be the exception and
have patches merged in the core of linux _only_ for their specific
user-space, and their specific drivers?

If you separate suspend blockers from Android, and judge them on their
technical merit, I don't see a single person saying this is a good
idea, we'll switch all our user-space to use them.

-- 
Felipe Contreras

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 1:17 AM, Bernd Petrovitsch
<bernd@petrovitsch.priv.at> wrote:
> On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote:
>> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> [...]
>> > Darn, _we_ have to deal with that forever as it sets a crappy user
>> > space ABI in stone.
>>
>> I really don't see how it is ... the ABI comes with a switch that allows
>> it to be disabled, so only platforms wishing to use it have to support
>> it.  Even on those platforms that do support it, we can translate most
>
> You completely missed the point: The crappy user interface - and
> interferences with pother subsystems - must be maintained for ages - and
> that is independent if one uses it or not. Even worse if it's not widely
> used.

When (or if) the time comes that suspend is no longer useful, this api
becomes a NOP.

>
>> of it into pm QoS stuff and if one day someone solves the rogue app
>> problem, we can migrate over.
>
> If it's so important for Android and no one else, Android can carry it
> out of tree.
>

This is not only important for Android. If you use suspend on a
current Linux system you run the risk of loosing wakeup events. If you
have wakeup events that you cannot afford to lose your only option is
to never suspend. On some hardware (e.g. x86) the cost of not
suspending is always huge, on other hardware (many ARM SOCs) the cost
is only huge if your apps behave poorly.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 1:17 AM, Bernd Petrovitsch
<bernd@petrovitsch.priv.at> wrote:
> On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote:
>> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> [...]
>> > Darn, _we_ have to deal with that forever as it sets a crappy user
>> > space ABI in stone.
>>
>> I really don't see how it is ... the ABI comes with a switch that allows
>> it to be disabled, so only platforms wishing to use it have to support
>> it.  Even on those platforms that do support it, we can translate most
>
> You completely missed the point: The crappy user interface - and
> interferences with pother subsystems - must be maintained for ages - and
> that is independent if one uses it or not. Even worse if it's not widely
> used.

When (or if) the time comes that suspend is no longer useful, this api
becomes a NOP.

>
>> of it into pm QoS stuff and if one day someone solves the rogue app
>> problem, we can migrate over.
>
> If it's so important for Android and no one else, Android can carry it
> out of tree.
>

This is not only important for Android. If you use suspend on a
current Linux system you run the risk of loosing wakeup events. If you
have wakeup events that you cannot afford to lose your only option is
to never suspend. On some hardware (e.g. x86) the cost of not
suspending is always huge, on other hardware (many ARM SOCs) the cost
is only huge if your apps behave poorly.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 26 May 2010, Florian Mickler wrote:
> 
> > I don't think that the in-kernel suspend block is a bad idea. 
> > 
> > You could probably use the suspend-blockers unconditionally in the
> > suspend framework to indicate if a suspend is possible or not.
> 
> That's not how it works.  Drivers aren't supposed to abort
> unconditional suspend -- not without a really good reason (for example,
> the device received a wakeup event before it was fully suspended).  In
> short, suspends should be considered to be _always_ possible.
> 
> > Regardless of opportunistic suspend or not. This way, you don't have to
> > try-and-fail on a suspend request and thus making suspending
> > potentially more robust or allowing for a "suspend as soon as
> > possible" semantic (which is probably a good idea, if you have to grab
> > your laptop in a hurry to get away).
> 
> That's different.  Suspend blockers could block (not abort!) regular 
> suspends, just as they do opportunistic suspends.
> 
> But why should they?  I mean, if userspace wants to initiate a suspend
> that is capable of being blocked by a kernel suspend blocker, then all
> it has to do is initiate an opportunistic suspend instead of a normal
> suspend.
> 
> Alan Stern

Let me elaborate what i mean:

The assumption beeing that specifying pm constraints in the drivers is
a good thing which we will be doing anyway in the long run. 
(See Alan Cox's summary of current mainline problems[1].)

I don't wanna go into specifing any constraint API here, but it could
probably be either a blocker flag (the here presented suspend-blocker,
which Alan doesnt like?) 
or maybe a few integer-typed constraints defined by the pm-core.
(needed scheduler-latency/needed io-latency?)

As an intermediate step, it would probably be possible to
specify the "I cant be suspended" constraint (aka blocker) for all
drivers not explicitly stating anything other. 

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical.  
(Much work.)

A future switch from something like a flag (blocker) to a
full integer-typed requirement would probably be a simple search and
replace or even possible by extending the blocker-api. 

If that is done, the prototype of the driver callback

int suspend(); 

could probably be changed to 

void suspend();

and it be expected to always _successfully_ suspend.

The hard part is finding the places where special guarantees are
needed. But android did show that this is possible.

Cheers,
Flo

[1]: http://lkml.org/lkml/2010/5/26/575

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 26 May 2010, Florian Mickler wrote:
> 
> > I don't think that the in-kernel suspend block is a bad idea. 
> > 
> > You could probably use the suspend-blockers unconditionally in the
> > suspend framework to indicate if a suspend is possible or not.
> 
> That's not how it works.  Drivers aren't supposed to abort
> unconditional suspend -- not without a really good reason (for example,
> the device received a wakeup event before it was fully suspended).  In
> short, suspends should be considered to be _always_ possible.
> 
> > Regardless of opportunistic suspend or not. This way, you don't have to
> > try-and-fail on a suspend request and thus making suspending
> > potentially more robust or allowing for a "suspend as soon as
> > possible" semantic (which is probably a good idea, if you have to grab
> > your laptop in a hurry to get away).
> 
> That's different.  Suspend blockers could block (not abort!) regular 
> suspends, just as they do opportunistic suspends.
> 
> But why should they?  I mean, if userspace wants to initiate a suspend
> that is capable of being blocked by a kernel suspend blocker, then all
> it has to do is initiate an opportunistic suspend instead of a normal
> suspend.
> 
> Alan Stern

Let me elaborate what i mean:

The assumption beeing that specifying pm constraints in the drivers is
a good thing which we will be doing anyway in the long run. 
(See Alan Cox's summary of current mainline problems[1].)

I don't wanna go into specifing any constraint API here, but it could
probably be either a blocker flag (the here presented suspend-blocker,
which Alan doesnt like?) 
or maybe a few integer-typed constraints defined by the pm-core.
(needed scheduler-latency/needed io-latency?)

As an intermediate step, it would probably be possible to
specify the "I cant be suspended" constraint (aka blocker) for all
drivers not explicitly stating anything other. 

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical.  
(Much work.)

A future switch from something like a flag (blocker) to a
full integer-typed requirement would probably be a simple search and
replace or even possible by extending the blocker-api. 

If that is done, the prototype of the driver callback

int suspend(); 

could probably be changed to 

void suspend();

and it be expected to always _successfully_ suspend.

The hard part is finding the places where special guarantees are
needed. But android did show that this is possible.

Cheers,
Flo

[1]: http://lkml.org/lkml/2010/5/26/575

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 26 May 2010, Florian Mickler wrote:
> 
> > I don't think that the in-kernel suspend block is a bad idea. 
> > 
> > You could probably use the suspend-blockers unconditionally in the
> > suspend framework to indicate if a suspend is possible or not.
> 
> That's not how it works.  Drivers aren't supposed to abort
> unconditional suspend -- not without a really good reason (for example,
> the device received a wakeup event before it was fully suspended).  In
> short, suspends should be considered to be _always_ possible.
> 
> > Regardless of opportunistic suspend or not. This way, you don't have to
> > try-and-fail on a suspend request and thus making suspending
> > potentially more robust or allowing for a "suspend as soon as
> > possible" semantic (which is probably a good idea, if you have to grab
> > your laptop in a hurry to get away).
> 
> That's different.  Suspend blockers could block (not abort!) regular 
> suspends, just as they do opportunistic suspends.
> 
> But why should they?  I mean, if userspace wants to initiate a suspend
> that is capable of being blocked by a kernel suspend blocker, then all
> it has to do is initiate an opportunistic suspend instead of a normal
> suspend.
> 
> Alan Stern

Let me elaborate what i mean:

The assumption beeing that specifying pm constraints in the drivers is
a good thing which we will be doing anyway in the long run. 
(See Alan Cox's summary of current mainline problems[1].)

I don't wanna go into specifing any constraint API here, but it could
probably be either a blocker flag (the here presented suspend-blocker,
which Alan doesnt like?) 
or maybe a few integer-typed constraints defined by the pm-core.
(needed scheduler-latency/needed io-latency?)

As an intermediate step, it would probably be possible to
specify the "I cant be suspended" constraint (aka blocker) for all
drivers not explicitly stating anything other. 

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical.  
(Much work.)

A future switch from something like a flag (blocker) to a
full integer-typed requirement would probably be a simple search and
replace or even possible by extending the blocker-api. 

If that is done, the prototype of the driver callback

int suspend(); 

could probably be changed to 

void suspend();

and it be expected to always _successfully_ suspend.

The hard part is finding the places where special guarantees are
needed. But android did show that this is possible.

Cheers,
Flo

[1]: http://lkml.org/lkml/2010/5/26/575

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Wed, 26 May 2010, Alan Cox wrote:

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> Even if you believe the kernel should be containing junk the model that
> works and is used for everything else is resource management. Not giving
> various tasks the ability to override rules, otherwise you end up needing
> suspend blocker blockers next week.

We definitely will need them when we want to optimize the kernel
resource management on a QoS based scheme, which is the only sensible
way to go IMNSHO.

> A model based on the idea that a task can set its desired wakeup
> behaviour *subject to hard limits* (ie soft/hard process wakeup) works
> both for the sane system where its elegantly managing hard RT, and for
> the crud where you sandbox it to stop it making a nasty mess.

Right, the base system can set sensible defaults for "verified" apps,
which will work most of the time except for those which have special
requirements and need a skilled coder anyway. And for the sandbox crud
the sensible default can be "very long time" and allow the kernel to
ignore them at will.

> Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
> trick ?

That might be a good starting point.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Wed, 26 May 2010, Alan Cox wrote:

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> Even if you believe the kernel should be containing junk the model that
> works and is used for everything else is resource management. Not giving
> various tasks the ability to override rules, otherwise you end up needing
> suspend blocker blockers next week.

We definitely will need them when we want to optimize the kernel
resource management on a QoS based scheme, which is the only sensible
way to go IMNSHO.

> A model based on the idea that a task can set its desired wakeup
> behaviour *subject to hard limits* (ie soft/hard process wakeup) works
> both for the sane system where its elegantly managing hard RT, and for
> the crud where you sandbox it to stop it making a nasty mess.

Right, the base system can set sensible defaults for "verified" apps,
which will work most of the time except for those which have special
requirements and need a skilled coder anyway. And for the sandbox crud
the sensible default can be "very long time" and allow the kernel to
ignore them at will.

> Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
> trick ?

That might be a good starting point.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Florian Mickler wrote:

> On Wed, 26 May 2010 22:03:37 +0200
> Vitaly Wool <vitalywool@gmail.com> wrote:
> 
> > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> > 
> > > Your approach definitely sounds better than the current solution.
> > > What about mapping suspend blocker functionality later on, when this
> > > interface exists, on to this new approach and deprecating it?
> > 
> > What about coming back after some while with the appropriate solution
> > when it's ready instead of stubbornly pushing crap?
> > 
> > ~Vitaly
> 
> Because quite frankly, for a good part of linux users, suspend blockers
> is already in the kernel. It's just an historical mistake that they are
> not in the linux kernel's hosted on kernel.org. 

No, it's not a historical mistake. It's a technical decision _NOT_ to
merge crap. If we would accept every crappy patch which gets shipped
in large quantities as a defacto part of the kernel we would have a
completely unmaintainable mess since years.

> So why don't we do what we always do? Improve existing interfaces step
> by step? 

Exactly, that's what we are going to do. We improve and extend
existing interfaces step by step, but not by creating a horrible and
unmaintainable mess in the frist place which we can never get rid of
anymore.

> Top Down approaches fail from time to time. Also it is not clear, that
> that proposed interface works for the use cases. This has to be proven
> by providing an implementation. 

Nobody prevents you to sit down and start with a prove of concept
implementation.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Florian Mickler wrote:

> On Wed, 26 May 2010 22:03:37 +0200
> Vitaly Wool <vitalywool@gmail.com> wrote:
> 
> > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> > 
> > > Your approach definitely sounds better than the current solution.
> > > What about mapping suspend blocker functionality later on, when this
> > > interface exists, on to this new approach and deprecating it?
> > 
> > What about coming back after some while with the appropriate solution
> > when it's ready instead of stubbornly pushing crap?
> > 
> > ~Vitaly
> 
> Because quite frankly, for a good part of linux users, suspend blockers
> is already in the kernel. It's just an historical mistake that they are
> not in the linux kernel's hosted on kernel.org. 

No, it's not a historical mistake. It's a technical decision _NOT_ to
merge crap. If we would accept every crappy patch which gets shipped
in large quantities as a defacto part of the kernel we would have a
completely unmaintainable mess since years.

> So why don't we do what we always do? Improve existing interfaces step
> by step? 

Exactly, that's what we are going to do. We improve and extend
existing interfaces step by step, but not by creating a horrible and
unmaintainable mess in the frist place which we can never get rid of
anymore.

> Top Down approaches fail from time to time. Also it is not clear, that
> that proposed interface works for the use cases. This has to be proven
> by providing an implementation. 

Nobody prevents you to sit down and start with a prove of concept
implementation.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Wed, 26 May 2010, Florian Mickler wrote:

> On Wed, 26 May 2010 19:22:16 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Wed, 26 May 2010, Florian Mickler wrote:
> > >
> > > On the other hand, applications can say, they don't need that much
> > > power and userspace guaranties and not take a suspend blocker.
> > > 
> > > This is an option which they currently don't have.
> > 
> > Wrong. A well coded power aware application is very well able to
> > express that in various ways already today. Admittedly it's far from
> > perfect, but that can be fixed by adding interfaces which allow the
> > power aware coder to express the requirements of his application
> > actively, not by avoiding it.
> 
> Yeah, but a user can't say: "I don't
> know programming, but I had this idea. Here try it out." 
> to his friend. Because his friends phone then will crap out.
> 
> This is a negative. The phone just doesn't work well. 
> 
> A knowledgeable programmer is able to do extra work to enable specific
> guarantees. A dummy-throw-away-programmer doesn't want to do
> any extra work. 

Trying to solve that inside the kernel is the patently wrong
approach. The only way to give Joe Clicker the ability to "code" his
idea is to give him a restricted sandbox environment which takes care
of the extra work and is created by knowledgable programmers with the
Joe Clickers in mind.

Every Joe Clicker can "code" websites and does this happily in his
sandbox which consists of a web server and a web application
framework. There is no single line of code in the kernel to make this
work.

As I said before we need new interfaces and new technologies to let
the kernel do better power management, but definitely not a big hammer
approach which is actively preventing the kernel to do smarter
decisions.

The correct approach is QoS based and everything else is just a
bandaid which is going to hurt us badly.

> > 
> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I know that this is the point of the approach, but that does not make
it less wrong. Me, Alan and others explained already in great length
why it is the wrong approach, but you refuse to listen.

You remind me of my 14 year old son, who argues in circles to convince
me that I must allow him something which is wrong. And if he would
think about it w/o his primary goal of getting permission in mind he
would concede that it's wrong.

> > 
> > Also they enforce a black and white scheme (suspend or run) on the
> > kernel which is stupid, as there are more options to efficiently save
> > power than those two. While current android devices might not provide
> > them, later hardware will have it and any atom based device has them
> > already.
> 
> This is true. Nonetheless, in my opinion, implementing the "backwards
> approach" in any form (suspend blockers or some other sort of "sane"
> interface) is necessary in the long run.  I also believe that Alan's
> approach is the more flexible one. But I'm not in a position to judge
> on this.
> 
> If it really is better and superior, I think userland will switch
> over to it, as soon as it is possible to do it. The impact to the
> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The kernel loses the ability to remove suspend blockers once the
interface is exposed to user space. That's the whole point. We would
have to carry it on for a long time and trying to work around it when
implementing a technical correct approach.

And we have never seen crap move to a better interface. It will stay
there forever and hell will break lose when we break it.

> > So what the kernel needs to know to make better decisions are things
> > like:
> > 
> >   - how much slack can timers have (exisiting interface)
> 
> I liked this idea of Arjan, to give some applications infinite timer
> slack. But I don't know if it can made work in a "dummy proof" way.
> (I.e. it is too complicated to get it right in general, except for the
> "infinity" or not kind of tuning)

A mobile device can implement sensible defaults for the careless
applications and let the "good" apps override them.
 
> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most

It solves the segregration problem quite nicely, as again it can be
set to sensible defaults and to "very long" for the non verified apps.

> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

It's not orthogonal, it's essential to do QoS based power management,
which is the only sensible technical solution to do, as it allows the
kernel to optimize in various areas while at the same time
guaranteeing the response time to applications which require them.

Blockers are not orthogonal at all, as they actively prevent clever
decisions.

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

The kernel does not make politics. You and the folks who are pushing
that blockers stuff with all might are making politics on the ground
of a very bad argument. It does not matter at all whether android
ships that blockers or not, it neither matters whether android folks
consider this to be the best invention since sliced bread.

The only thing which matters is technical sanity of the approach and
the maintainability of it. And none of those is given.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Wed, 26 May 2010, Florian Mickler wrote:

> On Wed, 26 May 2010 19:22:16 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Wed, 26 May 2010, Florian Mickler wrote:
> > >
> > > On the other hand, applications can say, they don't need that much
> > > power and userspace guaranties and not take a suspend blocker.
> > > 
> > > This is an option which they currently don't have.
> > 
> > Wrong. A well coded power aware application is very well able to
> > express that in various ways already today. Admittedly it's far from
> > perfect, but that can be fixed by adding interfaces which allow the
> > power aware coder to express the requirements of his application
> > actively, not by avoiding it.
> 
> Yeah, but a user can't say: "I don't
> know programming, but I had this idea. Here try it out." 
> to his friend. Because his friends phone then will crap out.
> 
> This is a negative. The phone just doesn't work well. 
> 
> A knowledgeable programmer is able to do extra work to enable specific
> guarantees. A dummy-throw-away-programmer doesn't want to do
> any extra work. 

Trying to solve that inside the kernel is the patently wrong
approach. The only way to give Joe Clicker the ability to "code" his
idea is to give him a restricted sandbox environment which takes care
of the extra work and is created by knowledgable programmers with the
Joe Clickers in mind.

Every Joe Clicker can "code" websites and does this happily in his
sandbox which consists of a web server and a web application
framework. There is no single line of code in the kernel to make this
work.

As I said before we need new interfaces and new technologies to let
the kernel do better power management, but definitely not a big hammer
approach which is actively preventing the kernel to do smarter
decisions.

The correct approach is QoS based and everything else is just a
bandaid which is going to hurt us badly.

> > 
> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I know that this is the point of the approach, but that does not make
it less wrong. Me, Alan and others explained already in great length
why it is the wrong approach, but you refuse to listen.

You remind me of my 14 year old son, who argues in circles to convince
me that I must allow him something which is wrong. And if he would
think about it w/o his primary goal of getting permission in mind he
would concede that it's wrong.

> > 
> > Also they enforce a black and white scheme (suspend or run) on the
> > kernel which is stupid, as there are more options to efficiently save
> > power than those two. While current android devices might not provide
> > them, later hardware will have it and any atom based device has them
> > already.
> 
> This is true. Nonetheless, in my opinion, implementing the "backwards
> approach" in any form (suspend blockers or some other sort of "sane"
> interface) is necessary in the long run.  I also believe that Alan's
> approach is the more flexible one. But I'm not in a position to judge
> on this.
> 
> If it really is better and superior, I think userland will switch
> over to it, as soon as it is possible to do it. The impact to the
> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The kernel loses the ability to remove suspend blockers once the
interface is exposed to user space. That's the whole point. We would
have to carry it on for a long time and trying to work around it when
implementing a technical correct approach.

And we have never seen crap move to a better interface. It will stay
there forever and hell will break lose when we break it.

> > So what the kernel needs to know to make better decisions are things
> > like:
> > 
> >   - how much slack can timers have (exisiting interface)
> 
> I liked this idea of Arjan, to give some applications infinite timer
> slack. But I don't know if it can made work in a "dummy proof" way.
> (I.e. it is too complicated to get it right in general, except for the
> "infinity" or not kind of tuning)

A mobile device can implement sensible defaults for the careless
applications and let the "good" apps override them.
 
> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most

It solves the segregration problem quite nicely, as again it can be
set to sensible defaults and to "very long" for the non verified apps.

> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

It's not orthogonal, it's essential to do QoS based power management,
which is the only sensible technical solution to do, as it allows the
kernel to optimize in various areas while at the same time
guaranteeing the response time to applications which require them.

Blockers are not orthogonal at all, as they actively prevent clever
decisions.

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

The kernel does not make politics. You and the folks who are pushing
that blockers stuff with all might are making politics on the ground
of a very bad argument. It does not matter at all whether android
ships that blockers or not, it neither matters whether android folks
consider this to be the best invention since sliced bread.

The only thing which matters is technical sanity of the approach and
the maintainability of it. And none of those is given.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:

> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>   latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>   later
> - Suspend is just a power state
> 
> How does that fit your model and vision ?

I don't entirely see how this works. In order to deal with poorly 
written applications, it's necessary to (optionally, based on some 
policy) ignore them when it comes to the scheduler. The problem is how 
to implement the optional nature of this in a race-free manner. This is 
obviously a pathological case, but imagine an application that does 
something along the following lines:

int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
char foo;

while (1) {
	suspend_block();
	if (read(input, &foo, 1) > 0) {
		(do something)
		suspend_unblock();
	} else {
		suspend_unblock();
		(draw bouncing cows and clouds and tractor beams briefly)
	}
}

Now, if the user is playing this game, you want it to be scheduled. If 
the user has put down their phone and the screen lock has kicked in, you 
don't want it to be scheduled. So we could imagine some sort of cgroup 
that contains untrusted tasks - when the session is active we set a flag 
one way which indicates to the scheduler that tasks in TASK_RUNNING 
should be scheduled, and when the session is idle we set the flag the 
other way and all processes in that cgroup get shifted to 
TASK_INTERRUPTIBLE or something.

Except that doesn't work. If the session goes idle in the middle of the 
app drawing a frame, we'll stop the process and the task will never call 
read(). So the user hits a key, we wake up, nothing shifts from 
TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go 
back to sleep. The event never gets delivered.

Now let's try this in the Android world. The user hits a key and the 
system wakes up. The input layer takes a suspend block. The application 
now draws all the cows it wants to, takes its own suspend block and 
reads the input device. This empties the queue and the kernel-level 
suspend block is released. The application then processes the event 
before releasing the suspend block. The event has been delivered and 
handled.

You can't express that with resource limits or QoS constraints. If you 
want to deal with this kind of situation then, as far as I can tell, you 
need either suspend blockers or something so close to them that it makes 
no difference.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:

> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>   latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>   later
> - Suspend is just a power state
> 
> How does that fit your model and vision ?

I don't entirely see how this works. In order to deal with poorly 
written applications, it's necessary to (optionally, based on some 
policy) ignore them when it comes to the scheduler. The problem is how 
to implement the optional nature of this in a race-free manner. This is 
obviously a pathological case, but imagine an application that does 
something along the following lines:

int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
char foo;

while (1) {
	suspend_block();
	if (read(input, &foo, 1) > 0) {
		(do something)
		suspend_unblock();
	} else {
		suspend_unblock();
		(draw bouncing cows and clouds and tractor beams briefly)
	}
}

Now, if the user is playing this game, you want it to be scheduled. If 
the user has put down their phone and the screen lock has kicked in, you 
don't want it to be scheduled. So we could imagine some sort of cgroup 
that contains untrusted tasks - when the session is active we set a flag 
one way which indicates to the scheduler that tasks in TASK_RUNNING 
should be scheduled, and when the session is idle we set the flag the 
other way and all processes in that cgroup get shifted to 
TASK_INTERRUPTIBLE or something.

Except that doesn't work. If the session goes idle in the middle of the 
app drawing a frame, we'll stop the process and the task will never call 
read(). So the user hits a key, we wake up, nothing shifts from 
TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go 
back to sleep. The event never gets delivered.

Now let's try this in the Android world. The user hits a key and the 
system wakes up. The input layer takes a suspend block. The application 
now draws all the cows it wants to, takes its own suspend block and 
reads the input device. This empties the queue and the kernel-level 
suspend block is released. The application then processes the event 
before releasing the suspend block. The event has been delivered and 
handled.

You can't express that with resource limits or QoS constraints. If you 
want to deal with this kind of situation then, as far as I can tell, you 
need either suspend blockers or something so close to them that it makes 
no difference.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:

> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >>
> >> It is a significant power drain.
> >
> > Not in the situation I was discussing.
> >
> 
> If you meant it spend most of the time suspended, then I agree. It
> only wastes power when a driver blocks suspend by returning an error
> from its suspend hook and we are forced to loop doing no useful work.

Exactly the same as the in-kernel opportunistic suspend implementation.

Alan Stern

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Alan Stern]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:

> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >>
> >> It is a significant power drain.
> >
> > Not in the situation I was discussing.
> >
> 
> If you meant it spend most of the time suspended, then I agree. It
> only wastes power when a driver blocks suspend by returning an error
> from its suspend hook and we are forced to loop doing no useful work.

Exactly the same as the in-kernel opportunistic suspend implementation.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:

> I don't entirely see how this works. In order to deal with poorly 
> written applications, it's necessary to (optionally, based on some 
> policy) ignore them when it comes to the scheduler. The problem is how 
> to implement the optional nature of this in a race-free manner. This is 
> obviously a pathological case, but imagine an application that does 
> something along the following lines:
> 
> int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
> char foo;
> 
> while (1) {
> 	suspend_block();
> 	if (read(input, &foo, 1) > 0) {
> 		(do something)
> 		suspend_unblock();
> 	} else {
> 		suspend_unblock();
> 		(draw bouncing cows and clouds and tractor beams briefly)
> 	}
> }
> 
> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 
> one way which indicates to the scheduler that tasks in TASK_RUNNING 
> should be scheduled, and when the session is idle we set the flag the 
> other way and all processes in that cgroup get shifted to 
> TASK_INTERRUPTIBLE or something.

What's wrong with simply making the phone beep loudly and displaying:
bouncing cows is preventing your phone from sleeping!

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:

> I don't entirely see how this works. In order to deal with poorly 
> written applications, it's necessary to (optionally, based on some 
> policy) ignore them when it comes to the scheduler. The problem is how 
> to implement the optional nature of this in a race-free manner. This is 
> obviously a pathological case, but imagine an application that does 
> something along the following lines:
> 
> int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
> char foo;
> 
> while (1) {
> 	suspend_block();
> 	if (read(input, &foo, 1) > 0) {
> 		(do something)
> 		suspend_unblock();
> 	} else {
> 		suspend_unblock();
> 		(draw bouncing cows and clouds and tractor beams briefly)
> 	}
> }
> 
> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 
> one way which indicates to the scheduler that tasks in TASK_RUNNING 
> should be scheduled, and when the session is idle we set the flag the 
> other way and all processes in that cgroup get shifted to 
> TASK_INTERRUPTIBLE or something.

What's wrong with simply making the phone beep loudly and displaying:
bouncing cows is preventing your phone from sleeping!

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 10091 bytes --]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> 2010/5/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > On Wed, 26 May 2010 15:30:58 -0700
> > Arve Hjønnevåg <arve@android.com> wrote:
> >
> >> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> >> Really, what are you getting at? Do you deny that there are programs,
> >> >> that prevent a device from sleeping? (Just think of the bouncing
> >> >> cows app)
> >> >>
> >> >> And if you have two kernels, one with which your device is dead after 1
> >> >> hour and one with which your device is dead after 10 hours. Which would
> >> >> you prefer? I mean really... this is ridiculous.
> >> >
> >> > The problem you have is that this is policy. If I have the device wired
> >> > to a big screen and I want cows bouncing on it I'll be most upset if
> >> > instead it suspends.
> >>
> >> We never suspend when the screen is on. If the screen is off, I would
> >> not be upset if it suspends.
> >
> > This is policy and platform specific. The OLPC can suspend with the
> > screen on. Should I write my app to know about this once for Android and
> > once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> > indeed suspend to RAM between frames if the wakeup time was suitable.
> 
> Are you still talking about Linux suspend? If you can enter S3 from
> idle and still wake up for the next timer or interrupt, then do that.
> Suspend blockers should have not effect on this.

It does not matter whether it's S3 or any other power saving
state / mechanism in a particular device.

What matters is that the kernel needs to know about the QoS
requirements of the applications which are active to make optimal
decisions for power management. 

If we can go into any given power state from idle then the decision
which power state to select needs to be made on the requirements of an
application to react on the next event (timer, interrupt, ...).

So yes, we could go into S3 (with some effort) and arm the wakeup
source which will bring us back when the requirements of the apps are
known at the point where the decision is made.

> >
> > My app simply should not have to know this sort of crap, that's the whole
> > point of an OS.
> >
> 
> Most apps does not have to know about this with opportunistic suspend
> either. If the user is interacting with the device, we don't suspend.
> If your apps needs to run when the user is not interacting with the
> device, then you can block suspend.

You can express that in QoS requirements as well. If you say "max
wakeup latency 100ms" then the kernel will select a power state which
will meet this requirement. So it can decide whether to go into full
suspend on a given system or select some other better suiting power
saving mechanism. But this allows us to express this in a completely
hardware independent way. If the hardware does not provide a suitable
state, then the box stays on.

> >> > What you are essentially arguing for is for the
> >> > kernel to disobey the userspace.
> >>
> >> No I'm not. User-space asked the kernel to suspend when possible.
> >> Suspend is an existing kernel feature. All opportunistic suspend adds
> >> is the ability to use it safely when there are wakeup event you cannot
> >> afford to ignore.
> >
> > Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> > blockers are - or more precisely - the manner in which they express
> > intent from userspace. Opportunistic suspend is wonderful stuff for all
> > sorts of things and if it persuades people like netbook manufacturers to
> > think harder, and Linux driver authors to optimise their suspend/resume
> > paths we all win.
> >
> >> Our actual stating point is this: Some systems can only enter their
> >> lowest power state from suspend. So we added an api that allowed us to
> >> use suspend without loosing wakeup events. Since suspending also
> >> improves our battery life on platforms that enter the same power state
> >> from idle and suspend and we already have a way to safely use suspend,
> >> we would be crazy not to use it.
> >
> > Opportunistic suspend isn't special. Suspend is just a very deep idle. In
> 
> Suspend as it is currently implemented in Linux is special. Regular
> timers stop, and only specially marked wakeup events can bring the
> system back to the normal state.

That's a matter of the current implementation. We can change that and
improve it to do better resource management. And this requirement is
not restricted to the mobile phone space, it's true for laptops,
virtualization and other areas as well.
 
> > But you can express user suspend blocking in this manner. Your call
> > incoming code would say 'I want good latency'. As someone needs good
> > latency the box won't suspend. If your approach is to start with an
> > initial 'anyone can set a low latency we don't care' then anyone can
> > block suspends.
> >
> > Equally your call handling example is about latency not about suspend.
> > You want the phone to stay on, to fetch a picture and display it promptly.
> >
> 
> I don't think a latency api is the right way to express this since the
> only latency values we would use is minimal-latency and any-latency.
> What we are expressing is that this works need to happen now, even if
> the user is not currently interacting with the device.

You're mind is stuck in a black and white decision scheme, which you
implemented with the suspend blockers big hammer approach.

There is a wide variety between minimal and any latency. It depends on
the task at hand. An interactive application will want a latency which
is in the range of acceptable user experience, but that's not
necessarily the minimal latency which the system can guarantee and
provide. A background task can say "I'm fine with 100ms" which allows
the kernel to aggregate wakeups in a clever way.

Even if andorid decides that min and any are the only two which
matter, then this approach will work for android, but lets us use the
same mechanism and technology in other areas where people are
interested to express more than the on/off QoS requirements.

> > So my working position is summarised thusly
> >
> > - Supporting Android needs well good
> > - Opportunistic suspend good
> > - Manner in which interface is expressed to userspace bad
> > - Latency constraint interface would be better
> > - Your existing behaviour can be implemented by a simplistic use of a
> >  latency constraint interface
> > - We can fix a pile of other directly connected things at the same time
> > - Implementation internals I care far less about because we can fix those
> >  later
> > - Suspend is just a power state
> >
> > How does that fit your model and vision ?
> >
> 
> We have two main modes of operation. The user is interacting with the
> device and tasks and timers should run as requested. And, the user is
> not interacting with the device and the device should enter (and stay
> in) low power states regardless of running tasks and timers. Since
> some events (e.g. incoming phone call, alarm clock) will may cause the
> user to start interacting with the device, they need special
> treatment. A per thread latency api does not work for us. A global
> latency api could work, but since would only use minimal latency or
> any latency this seem like overkill. Also, with a global latency api,
> how do I know it the requested latency is meant to improve the
> experience while the user is interacting with the app, or if it meant
> the app needs to run when the user is not interacting with the device.

Again. You do not need a global latency API. A per thread and probably
per device latency information is what matters. The global state is
extracted from the per thread/device information.

With your global approach - which is basically the suspend blocker in
a different disguise - you prevent actively that the kernel can do
more clever decisions vs. power savings when there are more options
than suspend or not suspend.

> >> What about platforms that currently cannot enter low power states from
> >> idle? Do you remove suspend support from the kernel?
> >
> > I would actually expect a system that can't do any low power states to
> > support the user API and blissfully ignore it. Applications will ask for
> 
> I don't think you understood what I asked. Currently most x86 systems
> can enter much lower power states from suspend than they can from
> idle. Are you suggesting that we remove suspend support from Linux and
> try to enter the same power states on x86 from idle that we now enter
> from suspend? It is not clear to me if this is possible.

That does not matter whether we can do that right now or whether it's
possible at all on X86. The point is that the hardware is improving
and implementing better power saving mechanisms which allow us fine
grained control over the way we save power. 

So if a system can't go into suspend from idle, then the kernel can
simply ignore that all apps told the kernel that they don't care about
latency and QoS at the moment. It just selects the lowest power state
available. And if it has no power states at all, everything just works
fine.

OTOH, when you have this fancy application which just blinks with the
LED every two seconds for whatever reason, then your black and white
approach might prevent entering suspend just because the suspend
wakeup latency is 2.2 seconds and the kernel does not know that the
LED blinker app does not care whether it's actually 2 or 2.5 seconds.

Power management has more than two states, and the most important
information for selecting a state is the acceptable latency which a
given application can tolerate for coming out of the state in order to
meet the deadlines which can be given by a particular device fifo
length or by not violating the user experience.

There is nothing which prevents you of using the black and white
approach and just using the min and any latency values to express what
you think is the best for android, but you do not prevent other people
that way from taking a more sensible approach.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 10297 bytes --]

On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> 2010/5/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > On Wed, 26 May 2010 15:30:58 -0700
> > Arve Hjønnevåg <arve@android.com> wrote:
> >
> >> On Wed, May 26, 2010 at 6:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> >> Really, what are you getting at? Do you deny that there are programs,
> >> >> that prevent a device from sleeping? (Just think of the bouncing
> >> >> cows app)
> >> >>
> >> >> And if you have two kernels, one with which your device is dead after 1
> >> >> hour and one with which your device is dead after 10 hours. Which would
> >> >> you prefer? I mean really... this is ridiculous.
> >> >
> >> > The problem you have is that this is policy. If I have the device wired
> >> > to a big screen and I want cows bouncing on it I'll be most upset if
> >> > instead it suspends.
> >>
> >> We never suspend when the screen is on. If the screen is off, I would
> >> not be upset if it suspends.
> >
> > This is policy and platform specific. The OLPC can suspend with the
> > screen on. Should I write my app to know about this once for Android and
> > once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> > indeed suspend to RAM between frames if the wakeup time was suitable.
> 
> Are you still talking about Linux suspend? If you can enter S3 from
> idle and still wake up for the next timer or interrupt, then do that.
> Suspend blockers should have not effect on this.

It does not matter whether it's S3 or any other power saving
state / mechanism in a particular device.

What matters is that the kernel needs to know about the QoS
requirements of the applications which are active to make optimal
decisions for power management. 

If we can go into any given power state from idle then the decision
which power state to select needs to be made on the requirements of an
application to react on the next event (timer, interrupt, ...).

So yes, we could go into S3 (with some effort) and arm the wakeup
source which will bring us back when the requirements of the apps are
known at the point where the decision is made.

> >
> > My app simply should not have to know this sort of crap, that's the whole
> > point of an OS.
> >
> 
> Most apps does not have to know about this with opportunistic suspend
> either. If the user is interacting with the device, we don't suspend.
> If your apps needs to run when the user is not interacting with the
> device, then you can block suspend.

You can express that in QoS requirements as well. If you say "max
wakeup latency 100ms" then the kernel will select a power state which
will meet this requirement. So it can decide whether to go into full
suspend on a given system or select some other better suiting power
saving mechanism. But this allows us to express this in a completely
hardware independent way. If the hardware does not provide a suitable
state, then the box stays on.

> >> > What you are essentially arguing for is for the
> >> > kernel to disobey the userspace.
> >>
> >> No I'm not. User-space asked the kernel to suspend when possible.
> >> Suspend is an existing kernel feature. All opportunistic suspend adds
> >> is the ability to use it safely when there are wakeup event you cannot
> >> afford to ignore.
> >
> > Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> > blockers are - or more precisely - the manner in which they express
> > intent from userspace. Opportunistic suspend is wonderful stuff for all
> > sorts of things and if it persuades people like netbook manufacturers to
> > think harder, and Linux driver authors to optimise their suspend/resume
> > paths we all win.
> >
> >> Our actual stating point is this: Some systems can only enter their
> >> lowest power state from suspend. So we added an api that allowed us to
> >> use suspend without loosing wakeup events. Since suspending also
> >> improves our battery life on platforms that enter the same power state
> >> from idle and suspend and we already have a way to safely use suspend,
> >> we would be crazy not to use it.
> >
> > Opportunistic suspend isn't special. Suspend is just a very deep idle. In
> 
> Suspend as it is currently implemented in Linux is special. Regular
> timers stop, and only specially marked wakeup events can bring the
> system back to the normal state.

That's a matter of the current implementation. We can change that and
improve it to do better resource management. And this requirement is
not restricted to the mobile phone space, it's true for laptops,
virtualization and other areas as well.
 
> > But you can express user suspend blocking in this manner. Your call
> > incoming code would say 'I want good latency'. As someone needs good
> > latency the box won't suspend. If your approach is to start with an
> > initial 'anyone can set a low latency we don't care' then anyone can
> > block suspends.
> >
> > Equally your call handling example is about latency not about suspend.
> > You want the phone to stay on, to fetch a picture and display it promptly.
> >
> 
> I don't think a latency api is the right way to express this since the
> only latency values we would use is minimal-latency and any-latency.
> What we are expressing is that this works need to happen now, even if
> the user is not currently interacting with the device.

You're mind is stuck in a black and white decision scheme, which you
implemented with the suspend blockers big hammer approach.

There is a wide variety between minimal and any latency. It depends on
the task at hand. An interactive application will want a latency which
is in the range of acceptable user experience, but that's not
necessarily the minimal latency which the system can guarantee and
provide. A background task can say "I'm fine with 100ms" which allows
the kernel to aggregate wakeups in a clever way.

Even if andorid decides that min and any are the only two which
matter, then this approach will work for android, but lets us use the
same mechanism and technology in other areas where people are
interested to express more than the on/off QoS requirements.

> > So my working position is summarised thusly
> >
> > - Supporting Android needs well good
> > - Opportunistic suspend good
> > - Manner in which interface is expressed to userspace bad
> > - Latency constraint interface would be better
> > - Your existing behaviour can be implemented by a simplistic use of a
> >  latency constraint interface
> > - We can fix a pile of other directly connected things at the same time
> > - Implementation internals I care far less about because we can fix those
> >  later
> > - Suspend is just a power state
> >
> > How does that fit your model and vision ?
> >
> 
> We have two main modes of operation. The user is interacting with the
> device and tasks and timers should run as requested. And, the user is
> not interacting with the device and the device should enter (and stay
> in) low power states regardless of running tasks and timers. Since
> some events (e.g. incoming phone call, alarm clock) will may cause the
> user to start interacting with the device, they need special
> treatment. A per thread latency api does not work for us. A global
> latency api could work, but since would only use minimal latency or
> any latency this seem like overkill. Also, with a global latency api,
> how do I know it the requested latency is meant to improve the
> experience while the user is interacting with the app, or if it meant
> the app needs to run when the user is not interacting with the device.

Again. You do not need a global latency API. A per thread and probably
per device latency information is what matters. The global state is
extracted from the per thread/device information.

With your global approach - which is basically the suspend blocker in
a different disguise - you prevent actively that the kernel can do
more clever decisions vs. power savings when there are more options
than suspend or not suspend.

> >> What about platforms that currently cannot enter low power states from
> >> idle? Do you remove suspend support from the kernel?
> >
> > I would actually expect a system that can't do any low power states to
> > support the user API and blissfully ignore it. Applications will ask for
> 
> I don't think you understood what I asked. Currently most x86 systems
> can enter much lower power states from suspend than they can from
> idle. Are you suggesting that we remove suspend support from Linux and
> try to enter the same power states on x86 from idle that we now enter
> from suspend? It is not clear to me if this is possible.

That does not matter whether we can do that right now or whether it's
possible at all on X86. The point is that the hardware is improving
and implementing better power saving mechanisms which allow us fine
grained control over the way we save power. 

So if a system can't go into suspend from idle, then the kernel can
simply ignore that all apps told the kernel that they don't care about
latency and QoS at the moment. It just selects the lowest power state
available. And if it has no power states at all, everything just works
fine.

OTOH, when you have this fancy application which just blinks with the
LED every two seconds for whatever reason, then your black and white
approach might prevent entering suspend just because the suspend
wakeup latency is 2.2 seconds and the kernel does not know that the
LED blinker app does not care whether it's actually 2 or 2.5 seconds.

Power management has more than two states, and the most important
information for selecting a state is the acceptable latency which a
given application can tolerate for coming out of the state in order to
meet the deadlines which can be given by a particular device fifo
length or by not violating the user experience.

There is nothing which prevents you of using the black and white
approach and just using the min and any latency values to express what
you think is the best for android, but you do not prevent other people
that way from taking a more sensible approach.

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > should be scheduled, and when the session is idle we set the flag the 
> > other way and all processes in that cgroup get shifted to 
> > TASK_INTERRUPTIBLE or something.
> 
> What's wrong with simply making the phone beep loudly and displaying:
> bouncing cows is preventing your phone from sleeping!

Well, primarily that it's possible to design an implementation where it 
*doesn't* prevent your phone froms sleeping, but also because a given 
application may justifiably be preventing your phone from sleeping for a 
short while. What threshold do you use to determine the difference?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > should be scheduled, and when the session is idle we set the flag the 
> > other way and all processes in that cgroup get shifted to 
> > TASK_INTERRUPTIBLE or something.
> 
> What's wrong with simply making the phone beep loudly and displaying:
> bouncing cows is preventing your phone from sleeping!

Well, primarily that it's possible to design an implementation where it 
*doesn't* prevent your phone froms sleeping, but also because a given 
application may justifiably be preventing your phone from sleeping for a 
short while. What threshold do you use to determine the difference?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > > should be scheduled, and when the session is idle we set the flag the 
> > > other way and all processes in that cgroup get shifted to 
> > > TASK_INTERRUPTIBLE or something.
> > 
> > What's wrong with simply making the phone beep loudly and displaying:
> > bouncing cows is preventing your phone from sleeping!
> 
> Well, primarily that it's possible to design an implementation where it 
> *doesn't* prevent your phone froms sleeping, but also because a given 
> application may justifiably be preventing your phone from sleeping for a 
> short while. What threshold do you use to determine the difference?

Whatever you want, why would the kernel care?

You can create a whole resource management layer in userspace, with
different privilidge/trust levels. Trusted apps may wake more than
untrusted apps. Who cares.

The thing is, you can easily detect what keeps your cpu from idling.
What you do about it a pure userspace solution.

You can use the QoS stuff to give hints, like don't wake me more than 5
times a minute, if with those hints an app still doesn't meet whatever
criteria are suitable for the current mode, yell at it. Or adjust its
QoS parameters for it.

Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > > should be scheduled, and when the session is idle we set the flag the 
> > > other way and all processes in that cgroup get shifted to 
> > > TASK_INTERRUPTIBLE or something.
> > 
> > What's wrong with simply making the phone beep loudly and displaying:
> > bouncing cows is preventing your phone from sleeping!
> 
> Well, primarily that it's possible to design an implementation where it 
> *doesn't* prevent your phone froms sleeping, but also because a given 
> application may justifiably be preventing your phone from sleeping for a 
> short while. What threshold do you use to determine the difference?

Whatever you want, why would the kernel care?

You can create a whole resource management layer in userspace, with
different privilidge/trust levels. Trusted apps may wake more than
untrusted apps. Who cares.

The thing is, you can easily detect what keeps your cpu from idling.
What you do about it a pure userspace solution.

You can use the QoS stuff to give hints, like don't wake me more than 5
times a minute, if with those hints an app still doesn't meet whatever
criteria are suitable for the current mode, yell at it. Or adjust its
QoS parameters for it.

Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:41 +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > > > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > > > should be scheduled, and when the session is idle we set the flag the 
> > > > other way and all processes in that cgroup get shifted to 
> > > > TASK_INTERRUPTIBLE or something.
> > > 
> > > What's wrong with simply making the phone beep loudly and displaying:
> > > bouncing cows is preventing your phone from sleeping!
> > 
> > Well, primarily that it's possible to design an implementation where it 
> > *doesn't* prevent your phone froms sleeping, but also because a given 
> > application may justifiably be preventing your phone from sleeping for a 
> > short while. What threshold do you use to determine the difference?
> 
> Whatever you want, why would the kernel care?
> 
> You can create a whole resource management layer in userspace, with
> different privilidge/trust levels. Trusted apps may wake more than
> untrusted apps. Who cares.
> 
> The thing is, you can easily detect what keeps your cpu from idling.
> What you do about it a pure userspace solution.
> 
> You can use the QoS stuff to give hints, like don't wake me more than 5
> times a minute, if with those hints an app still doesn't meet whatever
> criteria are suitable for the current mode, yell at it. Or adjust its
> QoS parameters for it.
> 
> Heck, for all I care, simply SIGKILL the thing and report it once the
> user starts looking at his screen again.

Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:41 +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
> > > > one way which indicates to the scheduler that tasks in TASK_RUNNING 
> > > > should be scheduled, and when the session is idle we set the flag the 
> > > > other way and all processes in that cgroup get shifted to 
> > > > TASK_INTERRUPTIBLE or something.
> > > 
> > > What's wrong with simply making the phone beep loudly and displaying:
> > > bouncing cows is preventing your phone from sleeping!
> > 
> > Well, primarily that it's possible to design an implementation where it 
> > *doesn't* prevent your phone froms sleeping, but also because a given 
> > application may justifiably be preventing your phone from sleeping for a 
> > short while. What threshold do you use to determine the difference?
> 
> Whatever you want, why would the kernel care?
> 
> You can create a whole resource management layer in userspace, with
> different privilidge/trust levels. Trusted apps may wake more than
> untrusted apps. Who cares.
> 
> The thing is, you can easily detect what keeps your cpu from idling.
> What you do about it a pure userspace solution.
> 
> You can use the QoS stuff to give hints, like don't wake me more than 5
> times a minute, if with those hints an app still doesn't meet whatever
> criteria are suitable for the current mode, yell at it. Or adjust its
> QoS parameters for it.
> 
> Heck, for all I care, simply SIGKILL the thing and report it once the
> user starts looking at his screen again.

Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:05 +0100, Alan Cox wrote:
> What is the problem here - your device driver for the display can block
> tasks it doesn't want to use the display. 

Very well put again.

I bet the next example is a proglet that does: while(1); without device
interaction :-).

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:05 +0100, Alan Cox wrote:
> What is the problem here - your device driver for the display can block
> tasks it doesn't want to use the display. 

Very well put again.

I bet the next example is a proglet that does: while(1); without device
interaction :-).

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 

I would hope not, because I'd rather prefer my app that used the screen
to get the chance to save important data on what it was doing
irrespective of the screen blank:  "I have an elegant proof for this
problem but my battery has gone flat"

(and I imagine we can play that examples game forever given Ashby's law)

> You can't express that with resource limits or QoS constraints. 

I don't see why not. You just have to think about the problem from the
right end. Start from "normality is well behaved applications" and
progress to "but I can constrain bogus ones". 

So what are the resource constraints/QoS constraints for your example:

[Simplistically]

1. App says 'I want to wakeup from events for me within 1 second'
	(Because I like drawing cows at about that rate)
2. App open driver for buttons
3. App opens driver for screen

   Driver for buttons goes 'humm, well I can trigger wakeup from all
   power states so I need no restrictions'. Screen will vary by device a
   lot.


(I'll come back to the screen a bit more in a moment)

So lets consider the same binary

App runs on OLPC like h/w

The pm code goes 'well I can suspend/resume in a second thats cool'
The screen code goes 'Hey I've got OLPC like video so thats ok'
The button driver can wake the system from suspend and queue an event


App runs on Android like h/w

The pm code goes 'well I can suspend/resume in a second thats cool'
The screen code goes 'Gee the screen goes blank if I go below level X' so
	I'll set a limit
The button driver can wake the system from suspend and queue an event


App runs on Android like h/w but not trusted

The pm code goes 'well tough, you can't do that, I'll refuse you'
	(Maybe user space wrapped by Android with a 'Cows wants to eat
	your phone alive [Refuse] [This Time Only] [Always] UI
	User hits refuse and Android duly assigns the code no guarantee
	and a hard limit of no guarantee.

The screen code goes 'tough'
The button driver can wake the system etc

Cows will get suspended for longer than one second whether it likes it or
not

App runs on a desktop PC

The pm code goes 'well I can't do suspend/resume in 1 second, but I can
do C6'
The screen goes 'I need C6'
The button driver goes 'I need C6'


Same app in each case and a lot less syscalls. No pathalogical cases
either - with suspend blockers you can get emergent synchronization
patterns between applications where each app rarely blocks suspends but
together their timings fall such that they never allow it. How do you
propose to even detect that ?


Ok now the screen

If I write to an X server and the server doesn't wish to talk to me it
ignores the stream and I block. This has been the case since the 1980s.

What is the problem here - your device driver for the display can block
tasks it doesn't want to use the display.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 

I would hope not, because I'd rather prefer my app that used the screen
to get the chance to save important data on what it was doing
irrespective of the screen blank:  "I have an elegant proof for this
problem but my battery has gone flat"

(and I imagine we can play that examples game forever given Ashby's law)

> You can't express that with resource limits or QoS constraints. 

I don't see why not. You just have to think about the problem from the
right end. Start from "normality is well behaved applications" and
progress to "but I can constrain bogus ones". 

So what are the resource constraints/QoS constraints for your example:

[Simplistically]

1. App says 'I want to wakeup from events for me within 1 second'
	(Because I like drawing cows at about that rate)
2. App open driver for buttons
3. App opens driver for screen

   Driver for buttons goes 'humm, well I can trigger wakeup from all
   power states so I need no restrictions'. Screen will vary by device a
   lot.


(I'll come back to the screen a bit more in a moment)

So lets consider the same binary

App runs on OLPC like h/w

The pm code goes 'well I can suspend/resume in a second thats cool'
The screen code goes 'Hey I've got OLPC like video so thats ok'
The button driver can wake the system from suspend and queue an event


App runs on Android like h/w

The pm code goes 'well I can suspend/resume in a second thats cool'
The screen code goes 'Gee the screen goes blank if I go below level X' so
	I'll set a limit
The button driver can wake the system from suspend and queue an event


App runs on Android like h/w but not trusted

The pm code goes 'well tough, you can't do that, I'll refuse you'
	(Maybe user space wrapped by Android with a 'Cows wants to eat
	your phone alive [Refuse] [This Time Only] [Always] UI
	User hits refuse and Android duly assigns the code no guarantee
	and a hard limit of no guarantee.

The screen code goes 'tough'
The button driver can wake the system etc

Cows will get suspended for longer than one second whether it likes it or
not

App runs on a desktop PC

The pm code goes 'well I can't do suspend/resume in 1 second, but I can
do C6'
The screen goes 'I need C6'
The button driver goes 'I need C6'


Same app in each case and a lot less syscalls. No pathalogical cases
either - with suspend blockers you can get emergent synchronization
patterns between applications where each app rarely blocks suspends but
together their timings fall such that they never allow it. How do you
propose to even detect that ?


Ok now the screen

If I write to an X server and the server doesn't wish to talk to me it
ignores the stream and I block. This has been the case since the 1980s.

What is the problem here - your device driver for the display can block
tasks it doesn't want to use the display.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

If people don't mind, here is a greatly simplified summary of the 
comments and objections I have seen so far on this thread:

	The in-kernel suspend blocker implementation is okay, even
	beneficial.

	Opportunistic suspends are okay.

	The proposed userspace API is too Android-specific.

	More kernel mechanisms are needed for expressing processes'
	latency requirements.

The last one is obviously a longer-term issue, so let's ignore it for
now.  That leaves as the only point of contention the userspace
suspend-blocker API.

The proposal I made a couple of days ago removes this API and leaves
the other things (i.e., the in-kernel suspend blockers and
opportunistic suspend) intact.  In place of the userspace
kernel-blocker API, Android would have to implement a power manager
process that would essentially juggle all the latency requirements in
userspace.

Communication between the power manager process and the kernel would be 
limited to adding a new "opportunistic" entry to /sys/power/state -- 
something which could well be useful in its own right.  Even if this 
API turns out not to be good, it's simple enough that it could be 
removed pretty easily.

This answers Alan Cox's (and other's) desire not to implement a 
questionable or special-purpose API.  And it also answers Thomas's 
desire to make scheduling decisions based on latency requirements 
(although the answer is simply to punt all these decisions out of the 
kernel and into userspace -- which is reasonable for now since the 
alternative would require a long-term kernel development effort).

Indeed, having a power manager thread may well turn out to be a useful
thing -- but even if it doesn't, this scheme minimizes the damage while
still allowing the Android platform to use a vanilla kernel with only
limited modifications to their userspace.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

If people don't mind, here is a greatly simplified summary of the 
comments and objections I have seen so far on this thread:

	The in-kernel suspend blocker implementation is okay, even
	beneficial.

	Opportunistic suspends are okay.

	The proposed userspace API is too Android-specific.

	More kernel mechanisms are needed for expressing processes'
	latency requirements.

The last one is obviously a longer-term issue, so let's ignore it for
now.  That leaves as the only point of contention the userspace
suspend-blocker API.

The proposal I made a couple of days ago removes this API and leaves
the other things (i.e., the in-kernel suspend blockers and
opportunistic suspend) intact.  In place of the userspace
kernel-blocker API, Android would have to implement a power manager
process that would essentially juggle all the latency requirements in
userspace.

Communication between the power manager process and the kernel would be 
limited to adding a new "opportunistic" entry to /sys/power/state -- 
something which could well be useful in its own right.  Even if this 
API turns out not to be good, it's simple enough that it could be 
removed pretty easily.

This answers Alan Cox's (and other's) desire not to implement a 
questionable or special-purpose API.  And it also answers Thomas's 
desire to make scheduling decisions based on latency requirements 
(although the answer is simply to punt all these decisions out of the 
kernel and into userspace -- which is reasonable for now since the 
alternative would require a long-term kernel development effort).

Indeed, having a power manager thread may well turn out to be a useful
thing -- but even if it doesn't, this scheme minimizes the damage while
still allowing the Android platform to use a vanilla kernel with only
limited modifications to their userspace.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:10 +0100, Alan Cox wrote:
> > > Heck, for all I care, simply SIGKILL the thing and report it once the
> > > user starts looking at his screen again.
> > 
> > Provide incentive for Joe Clicker to improve his app, instead of cope
> > with the shit he created.
> 
> That isn't helpful. But if you feel like that I suggest you run with your
> memory management protection disabled, it's really on there to deal with
> crap code and its giving the wrong incentives. Come to think of it
> you might want to remove your seatbelts and any safety catches or airbags
> - it only encourages carelessness.
> 
> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')
> 
> Arguing that you don't need to do this isn't useful. Android has
> demonstrated a need to do this. RT has a need to do some of this.
> Virtualisation wants elements of this etc.

Sure, I fully agree with the task and per device QoS stuff. I'm just
saying that its good to inform the user that some app is severely
mis-behaving.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:10 +0100, Alan Cox wrote:
> > > Heck, for all I care, simply SIGKILL the thing and report it once the
> > > user starts looking at his screen again.
> > 
> > Provide incentive for Joe Clicker to improve his app, instead of cope
> > with the shit he created.
> 
> That isn't helpful. But if you feel like that I suggest you run with your
> memory management protection disabled, it's really on there to deal with
> crap code and its giving the wrong incentives. Come to think of it
> you might want to remove your seatbelts and any safety catches or airbags
> - it only encourages carelessness.
> 
> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')
> 
> Arguing that you don't need to do this isn't useful. Android has
> demonstrated a need to do this. RT has a need to do some of this.
> Virtualisation wants elements of this etc.

Sure, I fully agree with the task and per device QoS stuff. I'm just
saying that its good to inform the user that some app is severely
mis-behaving.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> 
>         Opportunistic suspends are okay.
> 
>         The proposed userspace API is too Android-specific.

I would argue opportunistic suspends are not ok, and therefore the
proposed API is utterly irrelevant.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> 
>         Opportunistic suspends are okay.
> 
>         The proposed userspace API is too Android-specific.

I would argue opportunistic suspends are not ok, and therefore the
proposed API is utterly irrelevant.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > Heck, for all I care, simply SIGKILL the thing and report it once the
> > user starts looking at his screen again.
> 
> Provide incentive for Joe Clicker to improve his app, instead of cope
> with the shit he created.

That isn't helpful. But if you feel like that I suggest you run with your
memory management protection disabled, it's really on there to deal with
crap code and its giving the wrong incentives. Come to think of it
you might want to remove your seatbelts and any safety catches or airbags
- it only encourages carelessness.

The reality is you need a sane, generic, race free way to express your
requirements (eg for hard RT) and ditto for constraining the expression
(for 'crapplications')

Arguing that you don't need to do this isn't useful. Android has
demonstrated a need to do this. RT has a need to do some of this.
Virtualisation wants elements of this etc.

The question is how you do it right.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > Heck, for all I care, simply SIGKILL the thing and report it once the
> > user starts looking at his screen again.
> 
> Provide incentive for Joe Clicker to improve his app, instead of cope
> with the shit he created.

That isn't helpful. But if you feel like that I suggest you run with your
memory management protection disabled, it's really on there to deal with
crap code and its giving the wrong incentives. Come to think of it
you might want to remove your seatbelts and any safety catches or airbags
- it only encourages carelessness.

The reality is you need a sane, generic, race free way to express your
requirements (eg for hard RT) and ditto for constraining the expression
(for 'crapplications')

Arguing that you don't need to do this isn't useful. Android has
demonstrated a need to do this. RT has a need to do some of this.
Virtualisation wants elements of this etc.

The question is how you do it right.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The proposal I made a couple of days ago removes this API and leaves
> the other things (i.e., the in-kernel suspend blockers and
> opportunistic suspend) intact.  In place of the userspace
> kernel-blocker API, Android would have to implement a power manager
> process that would essentially juggle all the latency requirements in
> userspace.

On the kernel side you really want to add two arguments from day one which
is the time in ms and the power state. We have enumerations of current
power states (plus add suspend) so this is easy to do. The governors may
not use them for a while but ACPI for example can use the latency pretty
fast. You want the information there from day one so it is captured
otherwise it ends up a right royal pain in the arse adjusting the API
later. If the numbers are in but don't always get used it'll be a lot
smoother.

> Communication between the power manager process and the kernel would be 
> limited to adding a new "opportunistic" entry to /sys/power/state -- 
> something which could well be useful in its own right.  Even if this 
> API turns out not to be good, it's simple enough that it could be 
> removed pretty easily.

Yes. Probably it really should be linked to a cpufreq driver thing -
cpufreq_android or whatever being the starting point but thats not a big
deal and it doesn't leak into all the apps either. This is detail however.

> Indeed, having a power manager thread may well turn out to be a useful
> thing -- but even if it doesn't, this scheme minimizes the damage while
> still allowing the Android platform to use a vanilla kernel with only
> limited modifications to their userspace.

There have been some horribly bad attempts to do this, but if it works
for Android and its encapsulated in cpufreq_android.c maybe with a private
interface to a single supporting daemon then it's not creating bad user
APIs, its not peeing in anyone elses pond and the policy will all be in
the kernel and a daemon which keeps the wrong platform knowledge out of
the application space.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The proposal I made a couple of days ago removes this API and leaves
> the other things (i.e., the in-kernel suspend blockers and
> opportunistic suspend) intact.  In place of the userspace
> kernel-blocker API, Android would have to implement a power manager
> process that would essentially juggle all the latency requirements in
> userspace.

On the kernel side you really want to add two arguments from day one which
is the time in ms and the power state. We have enumerations of current
power states (plus add suspend) so this is easy to do. The governors may
not use them for a while but ACPI for example can use the latency pretty
fast. You want the information there from day one so it is captured
otherwise it ends up a right royal pain in the arse adjusting the API
later. If the numbers are in but don't always get used it'll be a lot
smoother.

> Communication between the power manager process and the kernel would be 
> limited to adding a new "opportunistic" entry to /sys/power/state -- 
> something which could well be useful in its own right.  Even if this 
> API turns out not to be good, it's simple enough that it could be 
> removed pretty easily.

Yes. Probably it really should be linked to a cpufreq driver thing -
cpufreq_android or whatever being the starting point but thats not a big
deal and it doesn't leak into all the apps either. This is detail however.

> Indeed, having a power manager thread may well turn out to be a useful
> thing -- but even if it doesn't, this scheme minimizes the damage while
> still allowing the Android platform to use a vanilla kernel with only
> limited modifications to their userspace.

There have been some horribly bad attempts to do this, but if it works
for Android and its encapsulated in cpufreq_android.c maybe with a private
interface to a single supporting daemon then it's not creating bad user
APIs, its not peeing in anyone elses pond and the policy will all be in
the kernel and a daemon which keeps the wrong platform knowledge out of
the application space.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
> 
> > - Supporting Android needs well good
> > - Opportunistic suspend good
> > - Manner in which interface is expressed to userspace bad
> > - Latency constraint interface would be better
> > - Your existing behaviour can be implemented by a simplistic use of a
> >   latency constraint interface
> > - We can fix a pile of other directly connected things at the same time
> > - Implementation internals I care far less about because we can fix those
> >   later
> > - Suspend is just a power state
> > 
> > How does that fit your model and vision ?
> 
> I don't entirely see how this works. In order to deal with poorly 
> written applications, it's necessary to (optionally, based on some 
> policy) ignore them when it comes to the scheduler. The problem is how 
> to implement the optional nature of this in a race-free manner. This is 
> obviously a pathological case, but imagine an application that does 
> something along the following lines:
> 
> int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
> char foo;
> 
> while (1) {
> 	suspend_block();
> 	if (read(input, &foo, 1) > 0) {
> 		(do something)
> 		suspend_unblock();
> 	} else {
> 		suspend_unblock();
> 		(draw bouncing cows and clouds and tractor beams briefly)
> 	}
> }
> 
> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 
> one way which indicates to the scheduler that tasks in TASK_RUNNING 
> should be scheduled, and when the session is idle we set the flag the 
> other way and all processes in that cgroup get shifted to 
> TASK_INTERRUPTIBLE or something.
> 
> Except that doesn't work. If the session goes idle in the middle of the 
> app drawing a frame, we'll stop the process and the task will never call 
> read(). So the user hits a key, we wake up, nothing shifts from 
> TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go 
> back to sleep. The event never gets delivered.
> 
> Now let's try this in the Android world. The user hits a key and the 
> system wakes up. The input layer takes a suspend block. The application 
> now draws all the cows it wants to, takes its own suspend block and 
> reads the input device. This empties the queue and the kernel-level 
> suspend block is released. The application then processes the event 
> before releasing the suspend block. The event has been delivered and 
> handled.

Thanks for providing this example:

  1) It proves that suspend blockers are solely designed to encourage
     people to code crap.

  2) It exposes the main conceptual problem of the approach:

     The input layer in the kernel magically takes a suspend blocker
     and releases it in an equally magic way just to allow the crappy
     application to reach the point where it takes it's own suspend
     blocker and can react on the user input.
     
     And you need to do that, because the user applications suspend
     blocker magic is racy as hell. To work around that you sprinkle
     your suspend blocker magic all over the kernel instead of telling
     people how to solve the problem correctly.

     And what are you achieving with this versus power saving ?

     	 Exaclty _NOTHING_ ! 

     Simply because you move the cow drawing CPU time from the point
     where the device wants to go into suspend to the point where the
     user hits a key again. You even delay the reaction of your app to
     the user input by the time it needs to finish drawing cows.
 
     So you need to come up with a way better example why you need
     your blockers than with this prove of misconception.

> You can't express that with resource limits or QoS constraints. If you 
> want to deal with this kind of situation then, as far as I can tell, you 
> need either suspend blockers or something so close to them that it makes 
> no difference.

Wrong. If your application is interactive then you set the QoS
requirement once to interactive and be done.

So the correct point to make a power state decision is when the app
waits for a key press. At this point the kernel can take several
pathes:

      1) Keep the system alive because the input device is in active
       	 state and a key press is expected

      2) Go into supsend because the input device is deactivated after
      	 the screen lock kicked in.

This behaves exactly the same way in terms of power consumption as
your blocker example just without all the mess you are trying to
create.

And it allows the kernel to use intermediate power saving methods
(between idle and suspend) which might be available on some hardware.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
> 
> > - Supporting Android needs well good
> > - Opportunistic suspend good
> > - Manner in which interface is expressed to userspace bad
> > - Latency constraint interface would be better
> > - Your existing behaviour can be implemented by a simplistic use of a
> >   latency constraint interface
> > - We can fix a pile of other directly connected things at the same time
> > - Implementation internals I care far less about because we can fix those
> >   later
> > - Suspend is just a power state
> > 
> > How does that fit your model and vision ?
> 
> I don't entirely see how this works. In order to deal with poorly 
> written applications, it's necessary to (optionally, based on some 
> policy) ignore them when it comes to the scheduler. The problem is how 
> to implement the optional nature of this in a race-free manner. This is 
> obviously a pathological case, but imagine an application that does 
> something along the following lines:
> 
> int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
> char foo;
> 
> while (1) {
> 	suspend_block();
> 	if (read(input, &foo, 1) > 0) {
> 		(do something)
> 		suspend_unblock();
> 	} else {
> 		suspend_unblock();
> 		(draw bouncing cows and clouds and tractor beams briefly)
> 	}
> }
> 
> Now, if the user is playing this game, you want it to be scheduled. If 
> the user has put down their phone and the screen lock has kicked in, you 
> don't want it to be scheduled. So we could imagine some sort of cgroup 
> that contains untrusted tasks - when the session is active we set a flag 
> one way which indicates to the scheduler that tasks in TASK_RUNNING 
> should be scheduled, and when the session is idle we set the flag the 
> other way and all processes in that cgroup get shifted to 
> TASK_INTERRUPTIBLE or something.
> 
> Except that doesn't work. If the session goes idle in the middle of the 
> app drawing a frame, we'll stop the process and the task will never call 
> read(). So the user hits a key, we wake up, nothing shifts from 
> TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go 
> back to sleep. The event never gets delivered.
> 
> Now let's try this in the Android world. The user hits a key and the 
> system wakes up. The input layer takes a suspend block. The application 
> now draws all the cows it wants to, takes its own suspend block and 
> reads the input device. This empties the queue and the kernel-level 
> suspend block is released. The application then processes the event 
> before releasing the suspend block. The event has been delivered and 
> handled.

Thanks for providing this example:

  1) It proves that suspend blockers are solely designed to encourage
     people to code crap.

  2) It exposes the main conceptual problem of the approach:

     The input layer in the kernel magically takes a suspend blocker
     and releases it in an equally magic way just to allow the crappy
     application to reach the point where it takes it's own suspend
     blocker and can react on the user input.
     
     And you need to do that, because the user applications suspend
     blocker magic is racy as hell. To work around that you sprinkle
     your suspend blocker magic all over the kernel instead of telling
     people how to solve the problem correctly.

     And what are you achieving with this versus power saving ?

     	 Exaclty _NOTHING_ ! 

     Simply because you move the cow drawing CPU time from the point
     where the device wants to go into suspend to the point where the
     user hits a key again. You even delay the reaction of your app to
     the user input by the time it needs to finish drawing cows.
 
     So you need to come up with a way better example why you need
     your blockers than with this prove of misconception.

> You can't express that with resource limits or QoS constraints. If you 
> want to deal with this kind of situation then, as far as I can tell, you 
> need either suspend blockers or something so close to them that it makes 
> no difference.

Wrong. If your application is interactive then you set the QoS
requirement once to interactive and be done.

So the correct point to make a power state decision is when the app
waits for a key press. At this point the kernel can take several
pathes:

      1) Keep the system alive because the input device is in active
       	 state and a key press is expected

      2) Go into supsend because the input device is deactivated after
      	 the screen lock kicked in.

This behaves exactly the same way in terms of power consumption as
your blocker example just without all the mess you are trying to
create.

And it allows the kernel to use intermediate power saving methods
(between idle and suspend) which might be available on some hardware.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > 
> >         Opportunistic suspends are okay.
> > 
> >         The proposed userspace API is too Android-specific.
> 
> I would argue opportunistic suspends are not ok, and therefore the
> proposed API is utterly irrelevant.

Assuming you are happy that opportunistically entering C6 and the like is
ok via ACPI can you explain why you have a problem with opportunistic
suspend and why it is different to a very deep sleep CPU state such as we
have now (and which on many embedded platforms we deal with *is* sleeping
external devices too)

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > 
> >         Opportunistic suspends are okay.
> > 
> >         The proposed userspace API is too Android-specific.
> 
> I would argue opportunistic suspends are not ok, and therefore the
> proposed API is utterly irrelevant.

Assuming you are happy that opportunistically entering C6 and the like is
ok via ACPI can you explain why you have a problem with opportunistic
suspend and why it is different to a very deep sleep CPU state such as we
have now (and which on many embedded platforms we deal with *is* sleeping
external devices too)

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> On Thu, 27 May 2010 17:09:16 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > 
> > >         Opportunistic suspends are okay.
> > > 
> > >         The proposed userspace API is too Android-specific.
> > 
> > I would argue opportunistic suspends are not ok, and therefore the
> > proposed API is utterly irrelevant.
> 
> Assuming you are happy that opportunistically entering C6 and the like is
> ok via ACPI can you explain why you have a problem with opportunistic
> suspend and why it is different to a very deep sleep CPU state such as we
> have now (and which on many embedded platforms we deal with *is* sleeping
> external devices too)

Agreed, but I understood the opportunistic suspend line from Alan Stern
to mean the echo opportunistic > /sys/power/foo thing.

If you view it as an extra deep idle state I have no problem with it
(because its simply an idle state, nothing magic about those).

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> On Thu, 27 May 2010 17:09:16 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > 
> > >         Opportunistic suspends are okay.
> > > 
> > >         The proposed userspace API is too Android-specific.
> > 
> > I would argue opportunistic suspends are not ok, and therefore the
> > proposed API is utterly irrelevant.
> 
> Assuming you are happy that opportunistically entering C6 and the like is
> ok via ACPI can you explain why you have a problem with opportunistic
> suspend and why it is different to a very deep sleep CPU state such as we
> have now (and which on many embedded platforms we deal with *is* sleeping
> external devices too)

Agreed, but I understood the opportunistic suspend line from Alan Stern
to mean the echo opportunistic > /sys/power/foo thing.

If you view it as an extra deep idle state I have no problem with it
(because its simply an idle state, nothing magic about those).

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 17:09:16 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > 
> > > >         Opportunistic suspends are okay.
> > > > 
> > > >         The proposed userspace API is too Android-specific.
> > > 
> > > I would argue opportunistic suspends are not ok, and therefore the
> > > proposed API is utterly irrelevant.
> > 
> > Assuming you are happy that opportunistically entering C6 and the like is
> > ok via ACPI can you explain why you have a problem with opportunistic
> > suspend and why it is different to a very deep sleep CPU state such as we
> > have now (and which on many embedded platforms we deal with *is* sleeping
> > external devices too)
> 
> Agreed, but I understood the opportunistic suspend line from Alan Stern
> to mean the echo opportunistic > /sys/power/foo thing.

Yes, that's what I meant.  Why do you think it is any worse than "echo 
mem >/sys/power/state"?  The only difference is that it will block 
until all in-kernel suspend blockers are disabled.

Or do you also think that "echo mem >/sys/power/state" is evil and 
should be removed from the kernel as soon as possible?

And to answer Thomas's question: The whole reason for having in-kernel 
suspend blockers is so that userspace can tell the system to suspend 
without losing wakeup events.

Suppose a key is pressed just as a user program writes "mem" to
/sys/power/state.  The keyboard driver handles the keystroke and queues
an input event.  Then the system suspends and doesn't wake up until
some other event occurs -- even though the keypress was an important
one and it should have prevented the system from suspending.

With in-kernel suspend blockers and opportunistic suspend, this 
scenario is prevented.  That is their raison-d'etre.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 17:09:16 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > 
> > > >         Opportunistic suspends are okay.
> > > > 
> > > >         The proposed userspace API is too Android-specific.
> > > 
> > > I would argue opportunistic suspends are not ok, and therefore the
> > > proposed API is utterly irrelevant.
> > 
> > Assuming you are happy that opportunistically entering C6 and the like is
> > ok via ACPI can you explain why you have a problem with opportunistic
> > suspend and why it is different to a very deep sleep CPU state such as we
> > have now (and which on many embedded platforms we deal with *is* sleeping
> > external devices too)
> 
> Agreed, but I understood the opportunistic suspend line from Alan Stern
> to mean the echo opportunistic > /sys/power/foo thing.

Yes, that's what I meant.  Why do you think it is any worse than "echo 
mem >/sys/power/state"?  The only difference is that it will block 
until all in-kernel suspend blockers are disabled.

Or do you also think that "echo mem >/sys/power/state" is evil and 
should be removed from the kernel as soon as possible?

And to answer Thomas's question: The whole reason for having in-kernel 
suspend blockers is so that userspace can tell the system to suspend 
without losing wakeup events.

Suppose a key is pressed just as a user program writes "mem" to
/sys/power/state.  The keyboard driver handles the keystroke and queues
an input event.  Then the system suspends and doesn't wake up until
some other event occurs -- even though the keypress was an important
one and it should have prevented the system from suspending.

With in-kernel suspend blockers and opportunistic suspend, this 
scenario is prevented.  That is their raison-d'etre.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Now let's try this in the Android world. The user hits a key and the 
> > system wakes up. The input layer takes a suspend block. The application 
> > now draws all the cows it wants to, takes its own suspend block and 
> > reads the input device. This empties the queue and the kernel-level 
> > suspend block is released. The application then processes the event 
> > before releasing the suspend block. The event has been delivered and 
> > handled.
> 
> Thanks for providing this example:
> 
>   1) It proves that suspend blockers are solely designed to encourage
>      people to code crap.

No. Suspend blockers are designed to ensure that suspend isn't racy with 
respect to wakeup events. The bit that mitigates badly written 
applications is the bit where the scheduler doesn't run any more.

If you're happy with a single badly written application being able to 
cripple your power management story, you don't need opportunistic 
suspend. But you still have complications when it comes to deciding to 
enter suspend at the same time as you receive a wakeup event.

>      And you need to do that, because the user applications suspend
>      blocker magic is racy as hell. To work around that you sprinkle
>      your suspend blocker magic all over the kernel instead of telling
>      people how to solve the problem correctly.

What /is/ the correct way to solve this problem when entering explicit 
suspend states? How do you guarantee that an event has been delivered to 
userspace before transitioning into suspend? Now, this is a less 
interesting problem if you're not using opportunistic suspend, but it's 
still a problem.

>      Simply because you move the cow drawing CPU time from the point
>      where the device wants to go into suspend to the point where the
>      user hits a key again. You even delay the reaction of your app to
>      the user input by the time it needs to finish drawing cows.

It's how application mainloops tend to work.

> > You can't express that with resource limits or QoS constraints. If you 
> > want to deal with this kind of situation then, as far as I can tell, you 
> > need either suspend blockers or something so close to them that it makes 
> > no difference.
> 
> Wrong. If your application is interactive then you set the QoS
> requirement once to interactive and be done.
>
> So the correct point to make a power state decision is when the app
> waits for a key press. At this point the kernel can take several
> pathes:
> 
>       1) Keep the system alive because the input device is in active
>        	 state and a key press is expected
> 
>       2) Go into supsend because the input device is deactivated after
>       	 the screen lock kicked in.

That's no good. If the input device has been deactivated, how does the 
wakeup event get delivered to the application?
 
> This behaves exactly the same way in terms of power consumption as
> your blocker example just without all the mess you are trying to
> create.

And means that wakeup events don't get delivered. That's a shortcoming.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Now let's try this in the Android world. The user hits a key and the 
> > system wakes up. The input layer takes a suspend block. The application 
> > now draws all the cows it wants to, takes its own suspend block and 
> > reads the input device. This empties the queue and the kernel-level 
> > suspend block is released. The application then processes the event 
> > before releasing the suspend block. The event has been delivered and 
> > handled.
> 
> Thanks for providing this example:
> 
>   1) It proves that suspend blockers are solely designed to encourage
>      people to code crap.

No. Suspend blockers are designed to ensure that suspend isn't racy with 
respect to wakeup events. The bit that mitigates badly written 
applications is the bit where the scheduler doesn't run any more.

If you're happy with a single badly written application being able to 
cripple your power management story, you don't need opportunistic 
suspend. But you still have complications when it comes to deciding to 
enter suspend at the same time as you receive a wakeup event.

>      And you need to do that, because the user applications suspend
>      blocker magic is racy as hell. To work around that you sprinkle
>      your suspend blocker magic all over the kernel instead of telling
>      people how to solve the problem correctly.

What /is/ the correct way to solve this problem when entering explicit 
suspend states? How do you guarantee that an event has been delivered to 
userspace before transitioning into suspend? Now, this is a less 
interesting problem if you're not using opportunistic suspend, but it's 
still a problem.

>      Simply because you move the cow drawing CPU time from the point
>      where the device wants to go into suspend to the point where the
>      user hits a key again. You even delay the reaction of your app to
>      the user input by the time it needs to finish drawing cows.

It's how application mainloops tend to work.

> > You can't express that with resource limits or QoS constraints. If you 
> > want to deal with this kind of situation then, as far as I can tell, you 
> > need either suspend blockers or something so close to them that it makes 
> > no difference.
> 
> Wrong. If your application is interactive then you set the QoS
> requirement once to interactive and be done.
>
> So the correct point to make a power state decision is when the app
> waits for a key press. At this point the kernel can take several
> pathes:
> 
>       1) Keep the system alive because the input device is in active
>        	 state and a key press is expected
> 
>       2) Go into supsend because the input device is deactivated after
>       	 the screen lock kicked in.

That's no good. If the input device has been deactivated, how does the 
wakeup event get delivered to the application?
 
> This behaves exactly the same way in terms of power consumption as
> your blocker example just without all the mess you are trying to
> create.

And means that wakeup events don't get delivered. That's a shortcoming.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > > On Thu, 27 May 2010 17:09:16 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > > 
> > > > >         Opportunistic suspends are okay.
> > > > > 
> > > > >         The proposed userspace API is too Android-specific.
> > > > 
> > > > I would argue opportunistic suspends are not ok, and therefore the
> > > > proposed API is utterly irrelevant.
> > > 
> > > Assuming you are happy that opportunistically entering C6 and the like is
> > > ok via ACPI can you explain why you have a problem with opportunistic
> > > suspend and why it is different to a very deep sleep CPU state such as we
> > > have now (and which on many embedded platforms we deal with *is* sleeping
> > > external devices too)
> > 
> > Agreed, but I understood the opportunistic suspend line from Alan Stern
> > to mean the echo opportunistic > /sys/power/foo thing.
> 
> Yes, that's what I meant.  Why do you think it is any worse than "echo 
> mem >/sys/power/state"?  The only difference is that it will block 
> until all in-kernel suspend blockers are disabled.
> 
> Or do you also think that "echo mem >/sys/power/state" is evil and 
> should be removed from the kernel as soon as possible?
> 
> And to answer Thomas's question: The whole reason for having in-kernel 
> suspend blockers is so that userspace can tell the system to suspend 
> without losing wakeup events.
> 
> Suppose a key is pressed just as a user program writes "mem" to
> /sys/power/state.  The keyboard driver handles the keystroke and queues
> an input event.  Then the system suspends and doesn't wake up until
> some other event occurs -- even though the keypress was an important
> one and it should have prevented the system from suspending.
> 
> With in-kernel suspend blockers and opportunistic suspend, this 
> scenario is prevented.  That is their raison-d'etre.

I tend to disagree. You are still looking at suspend as some extra
esoteric mechanism. We should stop doing this and look at suspend (to
RAM) as an additional deep idle state, which is well defined in terms
of power savings and wakeup latency. That's what I think opportunistic
suspend is all about. Now if you look at our current idle states in
x86 the incoming keystroke is never lost. 

So when suspend does lose the wakeup event then we need to fix that,
but why do we need suspend blockers for this ? Let's take your
example:

> The keyboard driver handles the keystroke and queues an input
> event. Then the system goes into suspend ....

Why do we go into suspend at all? If there is an event queued then
something is woken up and got running, which is reason enough _not_ to
enter suspend. If that's broken in the current implementation then we
need to fix it, but not with a big hammer by adding another
interface. We have that information already and obviously we do not
use it, so lets figure out why before adding suspend blockers just
because they paper over the underlying problem.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > > On Thu, 27 May 2010 17:09:16 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > > 
> > > > >         Opportunistic suspends are okay.
> > > > > 
> > > > >         The proposed userspace API is too Android-specific.
> > > > 
> > > > I would argue opportunistic suspends are not ok, and therefore the
> > > > proposed API is utterly irrelevant.
> > > 
> > > Assuming you are happy that opportunistically entering C6 and the like is
> > > ok via ACPI can you explain why you have a problem with opportunistic
> > > suspend and why it is different to a very deep sleep CPU state such as we
> > > have now (and which on many embedded platforms we deal with *is* sleeping
> > > external devices too)
> > 
> > Agreed, but I understood the opportunistic suspend line from Alan Stern
> > to mean the echo opportunistic > /sys/power/foo thing.
> 
> Yes, that's what I meant.  Why do you think it is any worse than "echo 
> mem >/sys/power/state"?  The only difference is that it will block 
> until all in-kernel suspend blockers are disabled.
> 
> Or do you also think that "echo mem >/sys/power/state" is evil and 
> should be removed from the kernel as soon as possible?
> 
> And to answer Thomas's question: The whole reason for having in-kernel 
> suspend blockers is so that userspace can tell the system to suspend 
> without losing wakeup events.
> 
> Suppose a key is pressed just as a user program writes "mem" to
> /sys/power/state.  The keyboard driver handles the keystroke and queues
> an input event.  Then the system suspends and doesn't wake up until
> some other event occurs -- even though the keypress was an important
> one and it should have prevented the system from suspending.
> 
> With in-kernel suspend blockers and opportunistic suspend, this 
> scenario is prevented.  That is their raison-d'etre.

I tend to disagree. You are still looking at suspend as some extra
esoteric mechanism. We should stop doing this and look at suspend (to
RAM) as an additional deep idle state, which is well defined in terms
of power savings and wakeup latency. That's what I think opportunistic
suspend is all about. Now if you look at our current idle states in
x86 the incoming keystroke is never lost. 

So when suspend does lose the wakeup event then we need to fix that,
but why do we need suspend blockers for this ? Let's take your
example:

> The keyboard driver handles the keystroke and queues an input
> event. Then the system goes into suspend ....

Why do we go into suspend at all? If there is an event queued then
something is woken up and got running, which is reason enough _not_ to
enter suspend. If that's broken in the current implementation then we
need to fix it, but not with a big hammer by adding another
interface. We have that information already and obviously we do not
use it, so lets figure out why before adding suspend blockers just
because they paper over the underlying problem.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > Now, if the user is playing this game, you want it to be scheduled. If 
> > the user has put down their phone and the screen lock has kicked in, you 
> > don't want it to be scheduled. So we could imagine some sort of cgroup 
> > that contains untrusted tasks - when the session is active we set a flag 
> 
> I would hope not, because I'd rather prefer my app that used the screen
> to get the chance to save important data on what it was doing
> irrespective of the screen blank:  "I have an elegant proof for this
> problem but my battery has gone flat"

Perhaps set after callbacks are made. But given that the approach 
doesn't work anyway...

> What is the problem here - your device driver for the display can block
> tasks it doesn't want to use the display.

It's still racy. Going back to my example without any of the suspend 
blocking code, but using a network socket rather than an input device:

int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, &addr, sizeof(addr))
while (1) {
       if (read(input, &foo, 1) > 0) {
               (do something)
       } else {
               (draw bouncing cows and clouds and tractor beams briefly)
       }
}

A network packet arrives while we're drawing. Before we finish drawing, 
the policy timeout expires and the screen turns off. The app's drawing 
is blocked and so never gets to the point of reading the socket. The 
wakeup event has been lost.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > Now, if the user is playing this game, you want it to be scheduled. If 
> > the user has put down their phone and the screen lock has kicked in, you 
> > don't want it to be scheduled. So we could imagine some sort of cgroup 
> > that contains untrusted tasks - when the session is active we set a flag 
> 
> I would hope not, because I'd rather prefer my app that used the screen
> to get the chance to save important data on what it was doing
> irrespective of the screen blank:  "I have an elegant proof for this
> problem but my battery has gone flat"

Perhaps set after callbacks are made. But given that the approach 
doesn't work anyway...

> What is the problem here - your device driver for the display can block
> tasks it doesn't want to use the display.

It's still racy. Going back to my example without any of the suspend 
blocking code, but using a network socket rather than an input device:

int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, &addr, sizeof(addr))
while (1) {
       if (read(input, &foo, 1) > 0) {
               (do something)
       } else {
               (draw bouncing cows and clouds and tractor beams briefly)
       }
}

A network packet arrives while we're drawing. Before we finish drawing, 
the policy timeout expires and the screen turns off. The app's drawing 
is blocked and so never gets to the point of reading the socket. The 
wakeup event has been lost.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> No. Suspend blockers are designed to ensure that suspend isn't racy with 
> respect to wakeup events. The bit that mitigates badly written 
> applications is the bit where the scheduler doesn't run any more.

How does having applications taking blockers fix that - it makes it
worse. They are now blocking the kernel doing the right job.

> If you're happy with a single badly written application being able to 
> cripple your power management story, you don't need opportunistic

And taking a suspend blocker isn't "crippling your power management" ???
 
> What /is/ the correct way to solve this problem when entering explicit 
> suspend states? How do you guarantee that an event has been delivered to 
> userspace before transitioning into suspend? Now, this is a less 
> interesting problem if you're not using opportunistic suspend, but it's 
> still a problem.

The same way as we deal with low power states on other non PC devices ?

> That's no good. If the input device has been deactivated, how does the 
> wakeup event get delivered to the application?

If the input device is letting itself get de-activated in a way that can
lose events the input device driver is buggy. It's nobody elses business
how it does the its job, and certainly *not* the applications.

That's a kernel internal issue.

You know the resource constraint exists because the driver knows it is
open
Your QoS guarantees tell you what you desired latency of response at the
point you can become ready is.

That's all your need to do it right.

In kernel yes your device driver probably does need to say things like
'Don't go below C6 for a moment' just as a high speed serial port might
want to say 'Nothing over 10mS please'

I can't speak for Thomas, but I'm certainly not arguing that you don't
need something that looks more like the blocker side of the logic *in
kernel*, because there is stuff that you want to express which isn't tied
to the task.

So you need

	Userspace -> QoS guarantee expression, implied resource
			expression via device use. *NO* knowledge of
			device or platform in the application

	Kernel space 

		Drivers -> Explicit guarantee expression not bound to
			tasks. Driver encapsulates the variety in the
			device hardware and expresses it in a uniform
			manner to the idling/suspend logic

		CPU Freq -> Encapsulates the variety in the CPU and core
			power functionality of devices, makes policy
			based upon the uniform express from the drivers
			and tasks

All the autonomy is now in the right places, and we have requisite variety
to actually manage the situation.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> No. Suspend blockers are designed to ensure that suspend isn't racy with 
> respect to wakeup events. The bit that mitigates badly written 
> applications is the bit where the scheduler doesn't run any more.

How does having applications taking blockers fix that - it makes it
worse. They are now blocking the kernel doing the right job.

> If you're happy with a single badly written application being able to 
> cripple your power management story, you don't need opportunistic

And taking a suspend blocker isn't "crippling your power management" ???
 
> What /is/ the correct way to solve this problem when entering explicit 
> suspend states? How do you guarantee that an event has been delivered to 
> userspace before transitioning into suspend? Now, this is a less 
> interesting problem if you're not using opportunistic suspend, but it's 
> still a problem.

The same way as we deal with low power states on other non PC devices ?

> That's no good. If the input device has been deactivated, how does the 
> wakeup event get delivered to the application?

If the input device is letting itself get de-activated in a way that can
lose events the input device driver is buggy. It's nobody elses business
how it does the its job, and certainly *not* the applications.

That's a kernel internal issue.

You know the resource constraint exists because the driver knows it is
open
Your QoS guarantees tell you what you desired latency of response at the
point you can become ready is.

That's all your need to do it right.

In kernel yes your device driver probably does need to say things like
'Don't go below C6 for a moment' just as a high speed serial port might
want to say 'Nothing over 10mS please'

I can't speak for Thomas, but I'm certainly not arguing that you don't
need something that looks more like the blocker side of the logic *in
kernel*, because there is stuff that you want to express which isn't tied
to the task.

So you need

	Userspace -> QoS guarantee expression, implied resource
			expression via device use. *NO* knowledge of
			device or platform in the application

	Kernel space 

		Drivers -> Explicit guarantee expression not bound to
			tasks. Driver encapsulates the variety in the
			device hardware and expresses it in a uniform
			manner to the idling/suspend logic

		CPU Freq -> Encapsulates the variety in the CPU and core
			power functionality of devices, makes policy
			based upon the uniform express from the drivers
			and tasks

All the autonomy is now in the right places, and we have requisite variety
to actually manage the situation.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:

> I can't speak for Thomas, but I'm certainly not arguing that you don't
> need something that looks more like the blocker side of the logic *in
> kernel*, because there is stuff that you want to express which isn't tied
> to the task.

Sure, if you're not using opportunistic suspend then I don't think 
there's any real need for the userspace side of this. The question is 
how to implement something with the useful properties of opportunistic 
suspend without without implementing something pretty much equivalent to 
the userspace suspend blockers. I've sent another mail expressing why I 
don't think your proposed QoS style behaviour provides that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:

> I can't speak for Thomas, but I'm certainly not arguing that you don't
> need something that looks more like the blocker side of the logic *in
> kernel*, because there is stuff that you want to express which isn't tied
> to the task.

Sure, if you're not using opportunistic suspend then I don't think 
there's any real need for the userspace side of this. The question is 
how to implement something with the useful properties of opportunistic 
suspend without without implementing something pretty much equivalent to 
the userspace suspend blockers. I've sent another mail expressing why I 
don't think your proposed QoS style behaviour provides that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>If people don't mind, here is a greatly simplified summary of the
>comments and objections I have seen so far on this thread:
>
>	The in-kernel suspend blocker implementation is okay, even
>	beneficial.

I disagree here. I believe expressing that as QoS is much better. Let 
the kernel decide which power state is better as long as I can say I 
need 100us IRQ latency or 100ms wakeup latency.

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>If people don't mind, here is a greatly simplified summary of the
>comments and objections I have seen so far on this thread:
>
>	The in-kernel suspend blocker implementation is okay, even
>	beneficial.

I disagree here. I believe expressing that as QoS is much better. Let 
the kernel decide which power state is better as long as I can say I 
need 100us IRQ latency or 100ms wakeup latency.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 16:10:54 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')

And the thing is, even a well written app can be a 'crapplication'
depending on the context and mood of the user.

cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 16:10:54 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')

And the thing is, even a well written app can be a 'crapplication'
depending on the context and mood of the user.

cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > > Now, if the user is playing this game, you want it to be scheduled. If 
> > > the user has put down their phone and the screen lock has kicked in, you 
> > > don't want it to be scheduled. So we could imagine some sort of cgroup 
> > > that contains untrusted tasks - when the session is active we set a flag 
> > 
> > I would hope not, because I'd rather prefer my app that used the screen
> > to get the chance to save important data on what it was doing
> > irrespective of the screen blank:  "I have an elegant proof for this
> > problem but my battery has gone flat"
> 
> Perhaps set after callbacks are made. But given that the approach 
> doesn't work anyway...

Which approach doesn't work, and why ?

> > What is the problem here - your device driver for the display can block
> > tasks it doesn't want to use the display.
> 
> It's still racy. Going back to my example without any of the suspend 
> blocking code, but using a network socket rather than an input device:
> 
> int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> char foo;
> struct sockaddr addr;
> connect (input, &addr, sizeof(addr))
> while (1) {
>        if (read(input, &foo, 1) > 0) {
>                (do something)
>        } else {
>                (draw bouncing cows and clouds and tractor beams briefly)
>        }
> }
> 
> A network packet arrives while we're drawing. Before we finish drawing, 
> the policy timeout expires and the screen turns off.

Which is correct for a badly behaved application. You said you wanted to
constrain it. You've done so. Now I am not sure why such a "timeout"
would expire in the example as the task is clearly busy when drawing, or
is talking to someone else who is in turn busy. Someone somewhere is
actually drawing be it a driver or app code.

For a well behaved application you are drawing so you are running
drawing stuff so why would you suspend. The app has said it has a
latency constraint that suspend cannot meet, or has a device open that
cannot meet the constraints in suspend.

You also have the socket open so you can meaningfully extract resource
constraint information from that fact.

See it's not the read() that matters, it's the connect and the close. 

If your policy for a well behaved application is 'thou shalt not
suspend in a way that breaks its networking' then for a well behaving app
once I connect the socket we cannot suspend that app until such point as
the app closes the socket. At any other point we will break the
connection. Whether that is desirable is a policy question and you get to
pick how much you choose to trust an app and how you interpret the
information in your cpufreq and suspend drivers.

If you have wake-on-lan then the network stack might be smarter and
choose to express itself as

	'the constraint is C6 unless the input queue is empty in which
	 case suspend is ok as I have WoL and my network routing is such
	 that I can prove that interface will be used'

In truth I doubt much hardware can make such an inference but some phones
probably can. On the other hand for /dev/input/foo you can make the
inference very nicely thank you.

Again wake on lan information does not belong in the application !

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > > Now, if the user is playing this game, you want it to be scheduled. If 
> > > the user has put down their phone and the screen lock has kicked in, you 
> > > don't want it to be scheduled. So we could imagine some sort of cgroup 
> > > that contains untrusted tasks - when the session is active we set a flag 
> > 
> > I would hope not, because I'd rather prefer my app that used the screen
> > to get the chance to save important data on what it was doing
> > irrespective of the screen blank:  "I have an elegant proof for this
> > problem but my battery has gone flat"
> 
> Perhaps set after callbacks are made. But given that the approach 
> doesn't work anyway...

Which approach doesn't work, and why ?

> > What is the problem here - your device driver for the display can block
> > tasks it doesn't want to use the display.
> 
> It's still racy. Going back to my example without any of the suspend 
> blocking code, but using a network socket rather than an input device:
> 
> int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> char foo;
> struct sockaddr addr;
> connect (input, &addr, sizeof(addr))
> while (1) {
>        if (read(input, &foo, 1) > 0) {
>                (do something)
>        } else {
>                (draw bouncing cows and clouds and tractor beams briefly)
>        }
> }
> 
> A network packet arrives while we're drawing. Before we finish drawing, 
> the policy timeout expires and the screen turns off.

Which is correct for a badly behaved application. You said you wanted to
constrain it. You've done so. Now I am not sure why such a "timeout"
would expire in the example as the task is clearly busy when drawing, or
is talking to someone else who is in turn busy. Someone somewhere is
actually drawing be it a driver or app code.

For a well behaved application you are drawing so you are running
drawing stuff so why would you suspend. The app has said it has a
latency constraint that suspend cannot meet, or has a device open that
cannot meet the constraints in suspend.

You also have the socket open so you can meaningfully extract resource
constraint information from that fact.

See it's not the read() that matters, it's the connect and the close. 

If your policy for a well behaved application is 'thou shalt not
suspend in a way that breaks its networking' then for a well behaving app
once I connect the socket we cannot suspend that app until such point as
the app closes the socket. At any other point we will break the
connection. Whether that is desirable is a policy question and you get to
pick how much you choose to trust an app and how you interpret the
information in your cpufreq and suspend drivers.

If you have wake-on-lan then the network stack might be smarter and
choose to express itself as

	'the constraint is C6 unless the input queue is empty in which
	 case suspend is ok as I have WoL and my network routing is such
	 that I can prove that interface will be used'

In truth I doubt much hardware can make such an inference but some phones
probably can. On the other hand for /dev/input/foo you can make the
inference very nicely thank you.

Again wake on lan information does not belong in the application !

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Now let's try this in the Android world. The user hits a key and the 
> > > system wakes up. The input layer takes a suspend block. The application 
> > > now draws all the cows it wants to, takes its own suspend block and 
> > > reads the input device. This empties the queue and the kernel-level 
> > > suspend block is released. The application then processes the event 
> > > before releasing the suspend block. The event has been delivered and 
> > > handled.
> > 
> > Thanks for providing this example:
> > 
> >   1) It proves that suspend blockers are solely designed to encourage
> >      people to code crap.
> 
> No. Suspend blockers are designed to ensure that suspend isn't racy with 
> respect to wakeup events. The bit that mitigates badly written 
> applications is the bit where the scheduler doesn't run any more.
> 
> If you're happy with a single badly written application being able to 
> cripple your power management story, you don't need opportunistic 
> suspend. But you still have complications when it comes to deciding to 
> enter suspend at the same time as you receive a wakeup event.

Wrong. Setting the QoS requirements of the badly written app to any
latency will allow the kernel to suspend even if the crappy app is
active.

And again. I'm opposing the general chant that fixing crappy
applications in the kernel is a good thing. It's the worst decision we
could make.
 
> >      And you need to do that, because the user applications suspend
> >      blocker magic is racy as hell. To work around that you sprinkle
> >      your suspend blocker magic all over the kernel instead of telling
> >      people how to solve the problem correctly.
> 
> What /is/ the correct way to solve this problem when entering explicit 
> suspend states? How do you guarantee that an event has been delivered to 
> userspace before transitioning into suspend? Now, this is a less 
> interesting problem if you're not using opportunistic suspend, but it's 
> still a problem.

Holy crap. If an event happens _before_ we go into an idle state - and
I see suspend as an deeper idle state - then we do not go there at all.

The whole notion of treating suspend to RAM any different than a plain
idle C-State is wrong. It's not different at all. You just use a
different mechanism which has longer takedown and wakeup latencies and
requires to shut down stuff and setup extra wakeup sources.

And there is the whole problem. Switching from normal event delivery
to those special wakeup sources. That needs to be engineered in any
case carefuly and it does not matter whether you add suspend blockers
or not.
 
> >      Simply because you move the cow drawing CPU time from the point
> >      where the device wants to go into suspend to the point where the
> >      user hits a key again. You even delay the reaction of your app to
> >      the user input by the time it needs to finish drawing cows.
> 
> It's how application mainloops tend to work.

So what's the f*cking point ? You draw exactly the same amount of
power and still you are claiming that it's better or what ?
 
> > > You can't express that with resource limits or QoS constraints. If you 
> > > want to deal with this kind of situation then, as far as I can tell, you 
> > > need either suspend blockers or something so close to them that it makes 
> > > no difference.
> > 
> > Wrong. If your application is interactive then you set the QoS
> > requirement once to interactive and be done.
> >
> > So the correct point to make a power state decision is when the app
> > waits for a key press. At this point the kernel can take several
> > pathes:
> > 
> >       1) Keep the system alive because the input device is in active
> >        	 state and a key press is expected
> > 
> >       2) Go into supsend because the input device is deactivated after
> >       	 the screen lock kicked in.
> 
> That's no good. If the input device has been deactivated, how does the 
> wakeup event get delivered to the application?
>  
> > This behaves exactly the same way in terms of power consumption as
> > your blocker example just without all the mess you are trying to
> > create.
> 
> And means that wakeup events don't get delivered. That's a shortcoming.

That's utter nonsense. If we have a problem with missed wakeups then
it needs to be fixed and not papered over with suspend blocker magic.

I'm starting to get really grumpy about the chant that suspend
blockers are the only way to fix missed wakeups. That might be the
only way you can think of with your pink android glasses on, but again
this is not rocket science even if it does not fit into the current
way the kernel handles the whole suspend mechanism.

So if we really sit back and look at suspend as another idle state,
then we have first off the same requirements for entering it as we
have for any other idle state:

     No running tasks (and we can solve the don't care task problem
     nicely with QoS)

Aside of that we need to bring devices into a quiescent state and
setup the wakeup sources. That switch over needs to be done with and
without suspend blockers in a careful way for each SoC
implementation. 

If the interrupt happens _BEFORE_ we switch over to the quiescent
state, then we need to backout. If it happens after the switch then it
goes into the nirwana if the suspend wakeup has not been set up
correctly. If we have it setup correctly then we go into suspend just
to come back immediately. There is nothing you can do about that with
suspend blockers.

So if the interrupt comes in before we switch then we have that
information already today. We might not make use of it or just in a
racy way, but that does not warrant to work around that problem with a
big hammer approach.

You can try to lull me into cozy suspend blocker acceptance as long as
you want, but you better spend your time on either giving a coherent
explanation why suspend blockers are necessary or looking at the
underlying problem and fixing it in a technical correct way.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Now let's try this in the Android world. The user hits a key and the 
> > > system wakes up. The input layer takes a suspend block. The application 
> > > now draws all the cows it wants to, takes its own suspend block and 
> > > reads the input device. This empties the queue and the kernel-level 
> > > suspend block is released. The application then processes the event 
> > > before releasing the suspend block. The event has been delivered and 
> > > handled.
> > 
> > Thanks for providing this example:
> > 
> >   1) It proves that suspend blockers are solely designed to encourage
> >      people to code crap.
> 
> No. Suspend blockers are designed to ensure that suspend isn't racy with 
> respect to wakeup events. The bit that mitigates badly written 
> applications is the bit where the scheduler doesn't run any more.
> 
> If you're happy with a single badly written application being able to 
> cripple your power management story, you don't need opportunistic 
> suspend. But you still have complications when it comes to deciding to 
> enter suspend at the same time as you receive a wakeup event.

Wrong. Setting the QoS requirements of the badly written app to any
latency will allow the kernel to suspend even if the crappy app is
active.

And again. I'm opposing the general chant that fixing crappy
applications in the kernel is a good thing. It's the worst decision we
could make.
 
> >      And you need to do that, because the user applications suspend
> >      blocker magic is racy as hell. To work around that you sprinkle
> >      your suspend blocker magic all over the kernel instead of telling
> >      people how to solve the problem correctly.
> 
> What /is/ the correct way to solve this problem when entering explicit 
> suspend states? How do you guarantee that an event has been delivered to 
> userspace before transitioning into suspend? Now, this is a less 
> interesting problem if you're not using opportunistic suspend, but it's 
> still a problem.

Holy crap. If an event happens _before_ we go into an idle state - and
I see suspend as an deeper idle state - then we do not go there at all.

The whole notion of treating suspend to RAM any different than a plain
idle C-State is wrong. It's not different at all. You just use a
different mechanism which has longer takedown and wakeup latencies and
requires to shut down stuff and setup extra wakeup sources.

And there is the whole problem. Switching from normal event delivery
to those special wakeup sources. That needs to be engineered in any
case carefuly and it does not matter whether you add suspend blockers
or not.
 
> >      Simply because you move the cow drawing CPU time from the point
> >      where the device wants to go into suspend to the point where the
> >      user hits a key again. You even delay the reaction of your app to
> >      the user input by the time it needs to finish drawing cows.
> 
> It's how application mainloops tend to work.

So what's the f*cking point ? You draw exactly the same amount of
power and still you are claiming that it's better or what ?
 
> > > You can't express that with resource limits or QoS constraints. If you 
> > > want to deal with this kind of situation then, as far as I can tell, you 
> > > need either suspend blockers or something so close to them that it makes 
> > > no difference.
> > 
> > Wrong. If your application is interactive then you set the QoS
> > requirement once to interactive and be done.
> >
> > So the correct point to make a power state decision is when the app
> > waits for a key press. At this point the kernel can take several
> > pathes:
> > 
> >       1) Keep the system alive because the input device is in active
> >        	 state and a key press is expected
> > 
> >       2) Go into supsend because the input device is deactivated after
> >       	 the screen lock kicked in.
> 
> That's no good. If the input device has been deactivated, how does the 
> wakeup event get delivered to the application?
>  
> > This behaves exactly the same way in terms of power consumption as
> > your blocker example just without all the mess you are trying to
> > create.
> 
> And means that wakeup events don't get delivered. That's a shortcoming.

That's utter nonsense. If we have a problem with missed wakeups then
it needs to be fixed and not papered over with suspend blocker magic.

I'm starting to get really grumpy about the chant that suspend
blockers are the only way to fix missed wakeups. That might be the
only way you can think of with your pink android glasses on, but again
this is not rocket science even if it does not fit into the current
way the kernel handles the whole suspend mechanism.

So if we really sit back and look at suspend as another idle state,
then we have first off the same requirements for entering it as we
have for any other idle state:

     No running tasks (and we can solve the don't care task problem
     nicely with QoS)

Aside of that we need to bring devices into a quiescent state and
setup the wakeup sources. That switch over needs to be done with and
without suspend blockers in a careful way for each SoC
implementation. 

If the interrupt happens _BEFORE_ we switch over to the quiescent
state, then we need to backout. If it happens after the switch then it
goes into the nirwana if the suspend wakeup has not been set up
correctly. If we have it setup correctly then we go into suspend just
to come back immediately. There is nothing you can do about that with
suspend blockers.

So if the interrupt comes in before we switch then we have that
information already today. We might not make use of it or just in a
racy way, but that does not warrant to work around that problem with a
big hammer approach.

You can try to lull me into cozy suspend blocker acceptance as long as
you want, but you better spend your time on either giving a coherent
explanation why suspend blockers are necessary or looking at the
underlying problem and fixing it in a technical correct way.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:41:31PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 17:07:14 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Perhaps set after callbacks are made. But given that the approach 
> > doesn't work anyway...
> 
> Which approach doesn't work, and why ?

Sorry, using cgroups and scheduler tricks as a race-free replacement for 
opportunistic suspend.

> > It's still racy. Going back to my example without any of the suspend 
> > blocking code, but using a network socket rather than an input device:
> > 
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >        if (read(input, &foo, 1) > 0) {
> >                (do something)
> >        } else {
> >                (draw bouncing cows and clouds and tractor beams briefly)
> >        }
> > }
> > 
> > A network packet arrives while we're drawing. Before we finish drawing, 
> > the policy timeout expires and the screen turns off.
> 
> Which is correct for a badly behaved application. You said you wanted to
> constrain it. You've done so. Now I am not sure why such a "timeout"
> would expire in the example as the task is clearly busy when drawing, or
> is talking to someone else who is in turn busy. Someone somewhere is
> actually drawing be it a driver or app code.

The timeout would be at the userspace platform level. If I haven't 
touched the app for 30 seconds (and if the app hasn't taken any form of 
suspend block), the screen should turn off. In the current Android 
implementation that will then (in the absence of any kernel-level 
suspend blockers) result in the system transitioning into a fully 
suspended state.

> For a well behaved application you are drawing so you are running
> drawing stuff so why would you suspend. The app has said it has a
> latency constraint that suspend cannot meet, or has a device open that
> cannot meet the constraints in suspend.

Not at all. The fact that the application hasn't taken any sort of 
suspend block means that the application has indicated that it's happy 
with no longer being scheduled when the screen is shut off, *providing 
there's no wakeup event to be processed*.

> You also have the socket open so you can meaningfully extract resource
> constraint information from that fact.
> 
> See it's not the read() that matters, it's the connect and the close. 
> 
> If your policy for a well behaved application is 'thou shalt not
> suspend in a way that breaks its networking' then for a well behaving app
> once I connect the socket we cannot suspend that app until such point as
> the app closes the socket. At any other point we will break the
> connection. Whether that is desirable is a policy question and you get to
> pick how much you choose to trust an app and how you interpret the
> information in your cpufreq and suspend drivers.

Again, that's not the desired outcome. The desired outcome is that when 
the screen shuts off, the application no longer gets scheduled until a 
network packet arrives. The difference between these scenarios is large.

> If you have wake-on-lan then the network stack might be smarter and
> choose to express itself as
> 
> 	'the constraint is C6 unless the input queue is empty in which
> 	 case suspend is ok as I have WoL and my network routing is such
> 	 that I can prove that interface will be used'

This is still racy. Going back to this:

int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, &addr, sizeof(addr))
while (1) {
       if (read(input, &foo, 1) > 0) {
               (do something)
       } else {
		* SUSPEND OCCURS HERE *
               (draw bouncing cows and clouds and tractor beams briefly)
       }
}

A wakeup event now arrives. We use kernel level suspend blockers to 
prevent the system from going back to sleep until userspace has read the 
packet. The application finishes drawing its cows, reads the packet 
(thus releasing the kernel-level suspend block) and them immediately 
reaches the end of its timeslice. At this point the application has not 
had an opportunity to indicate in any way whether or not the packet has 
altered its constraints in any way. What stops us from immediately 
suspending again?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:41:31PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 17:07:14 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Perhaps set after callbacks are made. But given that the approach 
> > doesn't work anyway...
> 
> Which approach doesn't work, and why ?

Sorry, using cgroups and scheduler tricks as a race-free replacement for 
opportunistic suspend.

> > It's still racy. Going back to my example without any of the suspend 
> > blocking code, but using a network socket rather than an input device:
> > 
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >        if (read(input, &foo, 1) > 0) {
> >                (do something)
> >        } else {
> >                (draw bouncing cows and clouds and tractor beams briefly)
> >        }
> > }
> > 
> > A network packet arrives while we're drawing. Before we finish drawing, 
> > the policy timeout expires and the screen turns off.
> 
> Which is correct for a badly behaved application. You said you wanted to
> constrain it. You've done so. Now I am not sure why such a "timeout"
> would expire in the example as the task is clearly busy when drawing, or
> is talking to someone else who is in turn busy. Someone somewhere is
> actually drawing be it a driver or app code.

The timeout would be at the userspace platform level. If I haven't 
touched the app for 30 seconds (and if the app hasn't taken any form of 
suspend block), the screen should turn off. In the current Android 
implementation that will then (in the absence of any kernel-level 
suspend blockers) result in the system transitioning into a fully 
suspended state.

> For a well behaved application you are drawing so you are running
> drawing stuff so why would you suspend. The app has said it has a
> latency constraint that suspend cannot meet, or has a device open that
> cannot meet the constraints in suspend.

Not at all. The fact that the application hasn't taken any sort of 
suspend block means that the application has indicated that it's happy 
with no longer being scheduled when the screen is shut off, *providing 
there's no wakeup event to be processed*.

> You also have the socket open so you can meaningfully extract resource
> constraint information from that fact.
> 
> See it's not the read() that matters, it's the connect and the close. 
> 
> If your policy for a well behaved application is 'thou shalt not
> suspend in a way that breaks its networking' then for a well behaving app
> once I connect the socket we cannot suspend that app until such point as
> the app closes the socket. At any other point we will break the
> connection. Whether that is desirable is a policy question and you get to
> pick how much you choose to trust an app and how you interpret the
> information in your cpufreq and suspend drivers.

Again, that's not the desired outcome. The desired outcome is that when 
the screen shuts off, the application no longer gets scheduled until a 
network packet arrives. The difference between these scenarios is large.

> If you have wake-on-lan then the network stack might be smarter and
> choose to express itself as
> 
> 	'the constraint is C6 unless the input queue is empty in which
> 	 case suspend is ok as I have WoL and my network routing is such
> 	 that I can prove that interface will be used'

This is still racy. Going back to this:

int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, &addr, sizeof(addr))
while (1) {
       if (read(input, &foo, 1) > 0) {
               (do something)
       } else {
		* SUSPEND OCCURS HERE *
               (draw bouncing cows and clouds and tractor beams briefly)
       }
}

A wakeup event now arrives. We use kernel level suspend blockers to 
prevent the system from going back to sleep until userspace has read the 
packet. The application finishes drawing its cows, reads the packet 
(thus releasing the kernel-level suspend block) and them immediately 
reaches the end of its timeslice. At this point the application has not 
had an opportunity to indicate in any way whether or not the packet has 
altered its constraints in any way. What stops us from immediately 
suspending again?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > No. Suspend blockers are designed to ensure that suspend isn't racy with 
> > respect to wakeup events. The bit that mitigates badly written 
> > applications is the bit where the scheduler doesn't run any more.
> > 
> > If you're happy with a single badly written application being able to 
> > cripple your power management story, you don't need opportunistic 
> > suspend. But you still have complications when it comes to deciding to 
> > enter suspend at the same time as you receive a wakeup event.
> 
> Wrong. Setting the QoS requirements of the badly written app to any
> latency will allow the kernel to suspend even if the crappy app is
> active.

That's not what I want if I'm using the app at the time...

> And again. I'm opposing the general chant that fixing crappy
> applications in the kernel is a good thing. It's the worst decision we
> could make.

You still need the in-kernel suspend blockers if you want to guarantee 
that you can't lose wakeup events. But yes, if you're not concerned 
handling badly behaved applications then I believe that you can lose 
opportunistic suspend and just use the scheduler.

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

My question was about explicit suspend states, not implicitly handling 
an identical state based on scheduler constraints. Suspend-as-a-C-state 
isn't usable on x86 - you have to explicitly trigger it based on some 
policy. And if you want to be able to do that without risking the loss 
of wakeup events then you need in-kernel suspend blockers.

> I'm starting to get really grumpy about the chant that suspend
> blockers are the only way to fix missed wakeups. That might be the
> only way you can think of with your pink android glasses on, but again
> this is not rocket science even if it does not fit into the current
> way the kernel handles the whole suspend mechanism.

I don't work for Google. I'm not an Android developer.

> So if we really sit back and look at suspend as another idle state,
> then we have first off the same requirements for entering it as we
> have for any other idle state:

There are various platforms where we cannot treat suspend as an idle 
state. Any solution that requires that doesn't actually solve the 
problem. Yes, this is *trivial* if you can depend on the scheduler. But 
we can't, and so it's difficult.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > No. Suspend blockers are designed to ensure that suspend isn't racy with 
> > respect to wakeup events. The bit that mitigates badly written 
> > applications is the bit where the scheduler doesn't run any more.
> > 
> > If you're happy with a single badly written application being able to 
> > cripple your power management story, you don't need opportunistic 
> > suspend. But you still have complications when it comes to deciding to 
> > enter suspend at the same time as you receive a wakeup event.
> 
> Wrong. Setting the QoS requirements of the badly written app to any
> latency will allow the kernel to suspend even if the crappy app is
> active.

That's not what I want if I'm using the app at the time...

> And again. I'm opposing the general chant that fixing crappy
> applications in the kernel is a good thing. It's the worst decision we
> could make.

You still need the in-kernel suspend blockers if you want to guarantee 
that you can't lose wakeup events. But yes, if you're not concerned 
handling badly behaved applications then I believe that you can lose 
opportunistic suspend and just use the scheduler.

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

My question was about explicit suspend states, not implicitly handling 
an identical state based on scheduler constraints. Suspend-as-a-C-state 
isn't usable on x86 - you have to explicitly trigger it based on some 
policy. And if you want to be able to do that without risking the loss 
of wakeup events then you need in-kernel suspend blockers.

> I'm starting to get really grumpy about the chant that suspend
> blockers are the only way to fix missed wakeups. That might be the
> only way you can think of with your pink android glasses on, but again
> this is not rocket science even if it does not fit into the current
> way the kernel handles the whole suspend mechanism.

I don't work for Google. I'm not an Android developer.

> So if we really sit back and look at suspend as another idle state,
> then we have first off the same requirements for entering it as we
> have for any other idle state:

There are various platforms where we cannot treat suspend as an idle 
state. Any solution that requires that doesn't actually solve the 
problem. Yes, this is *trivial* if you can depend on the scheduler. But 
we can't, and so it's difficult.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

This is where you are wrong.  Maybe not wrong in principle, but wrong 
in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
implementation is _very_ different from C-states (or just "idle").

The primary difference is that the kernel can be forced into suspend
even when the system isn't idle.  In particular, it may be in the
middle of processing a potential wakeup event -- and the current design
gives the PM core no way to know if that is so.  This is a weakness
that in-kernel suspend blockers fix.

With C-states this can't happen.  If the CPU goes into a deeper C-state 
then ipso facto it isn't busy processing anything, much less a wakeup 
event.

Now maybe this difference is a bad thing, and the whole PM 
suspend/hibernate infrastructure should be rewritten.  But the fact, 
remains, that's how it works now.  And it can't be changed easily or 
quickly.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

This is where you are wrong.  Maybe not wrong in principle, but wrong 
in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
implementation is _very_ different from C-states (or just "idle").

The primary difference is that the kernel can be forced into suspend
even when the system isn't idle.  In particular, it may be in the
middle of processing a potential wakeup event -- and the current design
gives the PM core no way to know if that is so.  This is a weakness
that in-kernel suspend blockers fix.

With C-states this can't happen.  If the CPU goes into a deeper C-state 
then ipso facto it isn't busy processing anything, much less a wakeup 
event.

Now maybe this difference is a bad thing, and the whole PM 
suspend/hibernate infrastructure should be rewritten.  But the fact, 
remains, that's how it works now.  And it can't be changed easily or 
quickly.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

This is where you are wrong.  Maybe not wrong in principle, but wrong 
in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
implementation is _very_ different from C-states (or just "idle").

The primary difference is that the kernel can be forced into suspend
even when the system isn't idle.  In particular, it may be in the
middle of processing a potential wakeup event -- and the current design
gives the PM core no way to know if that is so.  This is a weakness
that in-kernel suspend blockers fix.

With C-states this can't happen.  If the CPU goes into a deeper C-state 
then ipso facto it isn't busy processing anything, much less a wakeup 
event.

Now maybe this difference is a bad thing, and the whole PM 
suspend/hibernate infrastructure should be rewritten.  But the fact, 
remains, that's how it works now.  And it can't be changed easily or 
quickly.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Cox wrote:
> That's all your need to do it right.
> 
> In kernel yes your device driver probably does need to say things like
> 'Don't go below C6 for a moment' just as a high speed serial port might
> want to say 'Nothing over 10mS please'
> 
> I can't speak for Thomas, but I'm certainly not arguing that you don't
> need something that looks more like the blocker side of the logic *in
> kernel*, because there is stuff that you want to express which isn't tied
> to the task.

I'm not opposed, but yes it needs to be expressed in quantifiable
terms, i.e. wakeup latency. That's just contributing to the global QoS
state of affairs even if it is not tied to a particular task. 

And that allows the driver to be intelligent about it. The serial port
at 9600 has definitely different requirements than at 115200.

But that's quite a different concept than the big hammer approach of
the blockers.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Cox wrote:
> That's all your need to do it right.
> 
> In kernel yes your device driver probably does need to say things like
> 'Don't go below C6 for a moment' just as a high speed serial port might
> want to say 'Nothing over 10mS please'
> 
> I can't speak for Thomas, but I'm certainly not arguing that you don't
> need something that looks more like the blocker side of the logic *in
> kernel*, because there is stuff that you want to express which isn't tied
> to the task.

I'm not opposed, but yes it needs to be expressed in quantifiable
terms, i.e. wakeup latency. That's just contributing to the global QoS
state of affairs even if it is not tied to a particular task. 

And that allows the driver to be intelligent about it. The serial port
at 9600 has definitely different requirements than at 115200.

But that's quite a different concept than the big hammer approach of
the blockers.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Felipe Balbi wrote:

> On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> >If people don't mind, here is a greatly simplified summary of the
> >comments and objections I have seen so far on this thread:
> >
> >	The in-kernel suspend blocker implementation is okay, even
> >	beneficial.
> 
> I disagree here. I believe expressing that as QoS is much better. Let 
> the kernel decide which power state is better as long as I can say I 
> need 100us IRQ latency or 100ms wakeup latency.

Does this mean you believe "echo mem >/sys/power/state" is bad and
should be removed?  Or "echo disk >/sys/power/state"?  They pay no
attention to latencies or other requirements.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Felipe Balbi wrote:

> On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> >If people don't mind, here is a greatly simplified summary of the
> >comments and objections I have seen so far on this thread:
> >
> >	The in-kernel suspend blocker implementation is okay, even
> >	beneficial.
> 
> I disagree here. I believe expressing that as QoS is much better. Let 
> the kernel decide which power state is better as long as I can say I 
> need 100us IRQ latency or 100ms wakeup latency.

Does this mean you believe "echo mem >/sys/power/state" is bad and
should be removed?  Or "echo disk >/sys/power/state"?  They pay no
attention to latencies or other requirements.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> 
> > I can't speak for Thomas, but I'm certainly not arguing that you don't
> > need something that looks more like the blocker side of the logic *in
> > kernel*, because there is stuff that you want to express which isn't tied
> > to the task.
> 
> Sure, if you're not using opportunistic suspend then I don't think 
> there's any real need for the userspace side of this. The question is 
> how to implement something with the useful properties of opportunistic 
> suspend without without implementing something pretty much equivalent to 
> the userspace suspend blockers. I've sent another mail expressing why I 
> don't think your proposed QoS style behaviour provides that.

Opportunistic suspend is just a deep idle state, nothing else. If the
overall QoS requirements allow to enter that deep idle state then the
kernel goes there. Same decision as for all other idle states. You
don't need any user space blocker for this decision, just sensible QoS
information.

Stop thinking about suspend as a special mechanism. It's not - except
for s2disk, which is an entirely different beast.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> 
> > I can't speak for Thomas, but I'm certainly not arguing that you don't
> > need something that looks more like the blocker side of the logic *in
> > kernel*, because there is stuff that you want to express which isn't tied
> > to the task.
> 
> Sure, if you're not using opportunistic suspend then I don't think 
> there's any real need for the userspace side of this. The question is 
> how to implement something with the useful properties of opportunistic 
> suspend without without implementing something pretty much equivalent to 
> the userspace suspend blockers. I've sent another mail expressing why I 
> don't think your proposed QoS style behaviour provides that.

Opportunistic suspend is just a deep idle state, nothing else. If the
overall QoS requirements allow to enter that deep idle state then the
kernel goes there. Same decision as for all other idle states. You
don't need any user space blocker for this decision, just sensible QoS
information.

Stop thinking about suspend as a special mechanism. It's not - except
for s2disk, which is an entirely different beast.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Sure, if you're not using opportunistic suspend then I don't think 
> > there's any real need for the userspace side of this. The question is 
> > how to implement something with the useful properties of opportunistic 
> > suspend without without implementing something pretty much equivalent to 
> > the userspace suspend blockers. I've sent another mail expressing why I 
> > don't think your proposed QoS style behaviour provides that.
> 
> Opportunistic suspend is just a deep idle state, nothing else.

No. The useful property of opportunistic suspend is that nothing gets 
scheduled. That's fundamentally different to a deep idle state.

> Stop thinking about suspend as a special mechanism. It's not - except
> for s2disk, which is an entirely different beast.

On PCs, suspend has more in common with s2disk than it does C states.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Sure, if you're not using opportunistic suspend then I don't think 
> > there's any real need for the userspace side of this. The question is 
> > how to implement something with the useful properties of opportunistic 
> > suspend without without implementing something pretty much equivalent to 
> > the userspace suspend blockers. I've sent another mail expressing why I 
> > don't think your proposed QoS style behaviour provides that.
> 
> Opportunistic suspend is just a deep idle state, nothing else.

No. The useful property of opportunistic suspend is that nothing gets 
scheduled. That's fundamentally different to a deep idle state.

> Stop thinking about suspend as a special mechanism. It's not - except
> for s2disk, which is an entirely different beast.

On PCs, suspend has more in common with s2disk than it does C states.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Sure, if you're not using opportunistic suspend then I don't think 
> > > there's any real need for the userspace side of this. The question is 
> > > how to implement something with the useful properties of opportunistic 
> > > suspend without without implementing something pretty much equivalent to 
> > > the userspace suspend blockers. I've sent another mail expressing why I 
> > > don't think your proposed QoS style behaviour provides that.
> > 
> > Opportunistic suspend is just a deep idle state, nothing else.
> 
> No. The useful property of opportunistic suspend is that nothing gets 
> scheduled. That's fundamentally different to a deep idle state.

I think Alan and Thomas but certainly I am saying is that you can get to
the same state without suspend.

Either you suspend (forcefully don't schedule stuff), or you end up
blocking all tasks on QoS/resource limits and end up with an idle system
that goes into a deep idle state (aka suspend).

So why isn't blocking every task on a QoS/resource good enough for you?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Sure, if you're not using opportunistic suspend then I don't think 
> > > there's any real need for the userspace side of this. The question is 
> > > how to implement something with the useful properties of opportunistic 
> > > suspend without without implementing something pretty much equivalent to 
> > > the userspace suspend blockers. I've sent another mail expressing why I 
> > > don't think your proposed QoS style behaviour provides that.
> > 
> > Opportunistic suspend is just a deep idle state, nothing else.
> 
> No. The useful property of opportunistic suspend is that nothing gets 
> scheduled. That's fundamentally different to a deep idle state.

I think Alan and Thomas but certainly I am saying is that you can get to
the same state without suspend.

Either you suspend (forcefully don't schedule stuff), or you end up
blocking all tasks on QoS/resource limits and end up with an idle system
that goes into a deep idle state (aka suspend).

So why isn't blocking every task on a QoS/resource good enough for you?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> 
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> attention to latencies or other requirements. 

Those are a whole different beast, those are basically a quick-off
button like thing. Forced suspend is conceptually a very different beast
from power-saving a running system.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> 
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> attention to latencies or other requirements. 

Those are a whole different beast, those are basically a quick-off
button like thing. Forced suspend is conceptually a very different beast
from power-saving a running system.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > No. Suspend blockers are designed to ensure that suspend isn't racy with 
> > > respect to wakeup events. The bit that mitigates badly written 
> > > applications is the bit where the scheduler doesn't run any more.
> > > 
> > > If you're happy with a single badly written application being able to 
> > > cripple your power management story, you don't need opportunistic 
> > > suspend. But you still have complications when it comes to deciding to 
> > > enter suspend at the same time as you receive a wakeup event.
> > 
> > Wrong. Setting the QoS requirements of the badly written app to any
> > latency will allow the kernel to suspend even if the crappy app is
> > active.
> 
> That's not what I want if I'm using the app at the time...

Your crappy app does not use suspend blockers either.
 
> > And again. I'm opposing the general chant that fixing crappy
> > applications in the kernel is a good thing. It's the worst decision we
> > could make.
> 
> You still need the in-kernel suspend blockers if you want to guarantee 
> that you can't lose wakeup events. But yes, if you're not concerned 
> handling badly behaved applications then I believe that you can lose 
> opportunistic suspend and just use the scheduler.

No, we do not. We need correctly implemented drivers and a safe
switchover from normal event delivery to wakeup based.
 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> 
> My question was about explicit suspend states, not implicitly handling 
> an identical state based on scheduler constraints. Suspend-as-a-C-state 
> isn't usable on x86 - you have to explicitly trigger it based on some 

And why not ? Just because suspend is not implemented as an ACPI
C-state ? 

Nonsense, if we want to push the system into suspend from the idle
state we can do that. It's just not implemented and we've never tried
to do it as it requires a non trivial amount of work, but I have done
it on an ARM two years ago as a prove of concept and it works like a
charm.

> policy. And if you want to be able to do that without risking the loss 
> of wakeup events then you need in-kernel suspend blockers.

Crap. Stop beating on those lost wakeup events. If we lose them then
the drivers are broken and do not handle the switch over correctly. Or
the suspend mechanism is broken as it does not evaluate the system
state correctly. Blockers are just papering over that w/o tackling the
real problem.

> > So if we really sit back and look at suspend as another idle state,
> > then we have first off the same requirements for entering it as we
> > have for any other idle state:
> 
> There are various platforms where we cannot treat suspend as an idle 
> state. Any solution that requires that doesn't actually solve the 
> problem. Yes, this is *trivial* if you can depend on the scheduler. But 
> we can't, and so it's difficult.

Stop handwaving. Which platforms prevent us to go into suspend from
idle ? Please point me to the relevant documentation which says so.

Just because we have not tried to implemented it does not mean that we
cannot implement it.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > No. Suspend blockers are designed to ensure that suspend isn't racy with 
> > > respect to wakeup events. The bit that mitigates badly written 
> > > applications is the bit where the scheduler doesn't run any more.
> > > 
> > > If you're happy with a single badly written application being able to 
> > > cripple your power management story, you don't need opportunistic 
> > > suspend. But you still have complications when it comes to deciding to 
> > > enter suspend at the same time as you receive a wakeup event.
> > 
> > Wrong. Setting the QoS requirements of the badly written app to any
> > latency will allow the kernel to suspend even if the crappy app is
> > active.
> 
> That's not what I want if I'm using the app at the time...

Your crappy app does not use suspend blockers either.
 
> > And again. I'm opposing the general chant that fixing crappy
> > applications in the kernel is a good thing. It's the worst decision we
> > could make.
> 
> You still need the in-kernel suspend blockers if you want to guarantee 
> that you can't lose wakeup events. But yes, if you're not concerned 
> handling badly behaved applications then I believe that you can lose 
> opportunistic suspend and just use the scheduler.

No, we do not. We need correctly implemented drivers and a safe
switchover from normal event delivery to wakeup based.
 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> 
> My question was about explicit suspend states, not implicitly handling 
> an identical state based on scheduler constraints. Suspend-as-a-C-state 
> isn't usable on x86 - you have to explicitly trigger it based on some 

And why not ? Just because suspend is not implemented as an ACPI
C-state ? 

Nonsense, if we want to push the system into suspend from the idle
state we can do that. It's just not implemented and we've never tried
to do it as it requires a non trivial amount of work, but I have done
it on an ARM two years ago as a prove of concept and it works like a
charm.

> policy. And if you want to be able to do that without risking the loss 
> of wakeup events then you need in-kernel suspend blockers.

Crap. Stop beating on those lost wakeup events. If we lose them then
the drivers are broken and do not handle the switch over correctly. Or
the suspend mechanism is broken as it does not evaluate the system
state correctly. Blockers are just papering over that w/o tackling the
real problem.

> > So if we really sit back and look at suspend as another idle state,
> > then we have first off the same requirements for entering it as we
> > have for any other idle state:
> 
> There are various platforms where we cannot treat suspend as an idle 
> state. Any solution that requires that doesn't actually solve the 
> problem. Yes, this is *trivial* if you can depend on the scheduler. But 
> we can't, and so it's difficult.

Stop handwaving. Which platforms prevent us to go into suspend from
idle ? Please point me to the relevant documentation which says so.

Just because we have not tried to implemented it does not mean that we
cannot implement it.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Thu, May 27, 2010 at 07:04:24PM +0200, ext Alan Stern wrote:
>On Thu, 27 May 2010, Felipe Balbi wrote:
>
>> On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>> >If people don't mind, here is a greatly simplified summary of the
>> >comments and objections I have seen so far on this thread:
>> >
>> >	The in-kernel suspend blocker implementation is okay, even
>> >	beneficial.
>>
>> I disagree here. I believe expressing that as QoS is much better. Let
>> the kernel decide which power state is better as long as I can say I
>> need 100us IRQ latency or 100ms wakeup latency.
>
>Does this mean you believe "echo mem >/sys/power/state" is bad and
>should be removed?  Or "echo disk >/sys/power/state"?  They pay no
>attention to latencies or other requirements.

no, not at all. I think they are also really useful. But I also think 
in-kernel suspend blockers are unnecessary. I think runtime pm + cpuidle 
+ cpufreq is well enough for all cases. We just need to give those three 
information about desired latencies.

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Thu, May 27, 2010 at 07:04:24PM +0200, ext Alan Stern wrote:
>On Thu, 27 May 2010, Felipe Balbi wrote:
>
>> On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>> >If people don't mind, here is a greatly simplified summary of the
>> >comments and objections I have seen so far on this thread:
>> >
>> >	The in-kernel suspend blocker implementation is okay, even
>> >	beneficial.
>>
>> I disagree here. I believe expressing that as QoS is much better. Let
>> the kernel decide which power state is better as long as I can say I
>> need 100us IRQ latency or 100ms wakeup latency.
>
>Does this mean you believe "echo mem >/sys/power/state" is bad and
>should be removed?  Or "echo disk >/sys/power/state"?  They pay no
>attention to latencies or other requirements.

no, not at all. I think they are also really useful. But I also think 
in-kernel suspend blockers are unnecessary. I think runtime pm + cpuidle 
+ cpufreq is well enough for all cases. We just need to give those three 
information about desired latencies.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
> 
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
>
> So why isn't blocking every task on a QoS/resource good enough for you?

Because you may then block them in such a way that they never handle an 
event that should wake them.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
> 
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
>
> So why isn't blocking every task on a QoS/resource good enough for you?

Because you may then block them in such a way that they never handle an 
event that should wake them.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote:
>Opportunistic suspend is just a deep idle state, nothing else. If the
>overall QoS requirements allow to enter that deep idle state then the
>kernel goes there. Same decision as for all other idle states. You
>don't need any user space blocker for this decision, just sensible QoS
>information.

agree completely with you. Adding virtual differences between power 
states is a bad idea and causes unnecessary complication to the system. 
If we have a generic way of describing desired latencies (irq, wakeup, 
throughput, whatever), then the kernel should decide what's the best 
power state for the current situation.

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote:
>Opportunistic suspend is just a deep idle state, nothing else. If the
>overall QoS requirements allow to enter that deep idle state then the
>kernel goes there. Same decision as for all other idle states. You
>don't need any user space blocker for this decision, just sensible QoS
>information.

agree completely with you. Adding virtual differences between power 
states is a bad idea and causes unnecessary complication to the system. 
If we have a generic way of describing desired latencies (irq, wakeup, 
throughput, whatever), then the kernel should decide what's the best 
power state for the current situation.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > > No. The useful property of opportunistic suspend is that nothing gets 
> > > scheduled. That's fundamentally different to a deep idle state.
> > 
> > I think Alan and Thomas but certainly I am saying is that you can get to
> > the same state without suspend.
> > 
> > Either you suspend (forcefully don't schedule stuff), or you end up
> > blocking all tasks on QoS/resource limits and end up with an idle system
> > that goes into a deep idle state (aka suspend).
> >
> > So why isn't blocking every task on a QoS/resource good enough for you?
> 
> Because you may then block them in such a way that they never handle an 
> event that should wake them.

*blink*, do explain?

Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.

How would we not wake them when we do turn the screen back on and start
servicing the pending requests again?

Pretty much the same for everything else, input events, WoL etc..

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > > No. The useful property of opportunistic suspend is that nothing gets 
> > > scheduled. That's fundamentally different to a deep idle state.
> > 
> > I think Alan and Thomas but certainly I am saying is that you can get to
> > the same state without suspend.
> > 
> > Either you suspend (forcefully don't schedule stuff), or you end up
> > blocking all tasks on QoS/resource limits and end up with an idle system
> > that goes into a deep idle state (aka suspend).
> >
> > So why isn't blocking every task on a QoS/resource good enough for you?
> 
> Because you may then block them in such a way that they never handle an 
> event that should wake them.

*blink*, do explain?

Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.

How would we not wake them when we do turn the screen back on and start
servicing the pending requests again?

Pretty much the same for everything else, input events, WoL etc..

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.
> 
> And there is the whole problem. Switching from normal event delivery
> to those special wakeup sources. That needs to be engineered in any
> case carefuly and it does not matter whether you add suspend blockers
> or not.

Ok, I just don't know the answer: How is it just another idle state if
the userspace gets frozen? Doesn't that bork the whole transition and
you need a userspace<->kernel synchronisation point to not loose events?

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.
> 
> And there is the whole problem. Switching from normal event delivery
> to those special wakeup sources. That needs to be engineered in any
> case carefuly and it does not matter whether you add suspend blockers
> or not.

Ok, I just don't know the answer: How is it just another idle state if
the userspace gets frozen? Doesn't that bork the whole transition and
you need a userspace<->kernel synchronisation point to not loose events?

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > You still need the in-kernel suspend blockers if you want to guarantee 
> > that you can't lose wakeup events. But yes, if you're not concerned 
> > handling badly behaved applications then I believe that you can lose 
> > opportunistic suspend and just use the scheduler.
> 
> No, we do not. We need correctly implemented drivers and a safe
> switchover from normal event delivery to wakeup based.

What is a "Correctly implemented driver" in this case? One that receives 
a wakeup event and then prevents suspend being entered until userspace 
has acknowledged that event? Because that's what an in-kernel suspend 
blocker is.

> > My question was about explicit suspend states, not implicitly handling 
> > an identical state based on scheduler constraints. Suspend-as-a-C-state 
> > isn't usable on x86 - you have to explicitly trigger it based on some 
> 
> And why not ? Just because suspend is not implemented as an ACPI
> C-state ? 
> 
> Nonsense, if we want to push the system into suspend from the idle
> state we can do that. It's just not implemented and we've never tried
> to do it as it requires a non trivial amount of work, but I have done
> it on an ARM two years ago as a prove of concept and it works like a
> charm.

ACPI provides no guarantees about what level of hardware functionality 
remains during S3. You don't have any useful ability to determine which 
events will generate wakeups. And from a purely practical point of view, 
since the latency is in the range of seconds, you'll never have a low 
enough wakeup rate to hit it.

> > policy. And if you want to be able to do that without risking the loss 
> > of wakeup events then you need in-kernel suspend blockers.
> 
> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just papering over that w/o tackling the
> real problem.

Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the 
driver to indicate whether the wakeup event has been handled. That's 
what they're there for. The in-kernel ones don't paper over anything.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > You still need the in-kernel suspend blockers if you want to guarantee 
> > that you can't lose wakeup events. But yes, if you're not concerned 
> > handling badly behaved applications then I believe that you can lose 
> > opportunistic suspend and just use the scheduler.
> 
> No, we do not. We need correctly implemented drivers and a safe
> switchover from normal event delivery to wakeup based.

What is a "Correctly implemented driver" in this case? One that receives 
a wakeup event and then prevents suspend being entered until userspace 
has acknowledged that event? Because that's what an in-kernel suspend 
blocker is.

> > My question was about explicit suspend states, not implicitly handling 
> > an identical state based on scheduler constraints. Suspend-as-a-C-state 
> > isn't usable on x86 - you have to explicitly trigger it based on some 
> 
> And why not ? Just because suspend is not implemented as an ACPI
> C-state ? 
> 
> Nonsense, if we want to push the system into suspend from the idle
> state we can do that. It's just not implemented and we've never tried
> to do it as it requires a non trivial amount of work, but I have done
> it on an ARM two years ago as a prove of concept and it works like a
> charm.

ACPI provides no guarantees about what level of hardware functionality 
remains during S3. You don't have any useful ability to determine which 
events will generate wakeups. And from a purely practical point of view, 
since the latency is in the range of seconds, you'll never have a low 
enough wakeup rate to hit it.

> > policy. And if you want to be able to do that without risking the loss 
> > of wakeup events then you need in-kernel suspend blockers.
> 
> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just papering over that w/o tackling the
> real problem.

Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the 
driver to indicate whether the wakeup event has been handled. That's 
what they're there for. The in-kernel ones don't paper over anything.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> 
> This is where you are wrong.  Maybe not wrong in principle, but wrong 
> in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
> implementation is _very_ different from C-states (or just "idle").

Holy bouncing cow. I damned good know that the current implementation
is not doing that and that suspend is implemented in a totally
different way. That does not mean that this is written in stone. We
CAN change that and fix it to gain opportunistic suspend.
 
> The primary difference is that the kernel can be forced into suspend
> even when the system isn't idle.  In particular, it may be in the
> middle of processing a potential wakeup event -- and the current design
> gives the PM core no way to know if that is so.  This is a weakness
> that in-kernel suspend blockers fix.

Oh no. They paper over a short coming. If there is a pending event,
the kernel knows that. It just does not make use of this
information. Blockers just paper over this by sprinkling
do_not_suspend() calls all over the place. What a sensible solution.

> With C-states this can't happen.  If the CPU goes into a deeper C-state 
> then ipso facto it isn't busy processing anything, much less a wakeup 
> event.

And that's the whole point of doing the opportunistic suspend with the
help of the scheduler.

> Now maybe this difference is a bad thing, and the whole PM 
> suspend/hibernate infrastructure should be rewritten.  But the fact, 
> remains, that's how it works now.  And it can't be changed easily or 
> quickly.

So what you are saying is that we better paper over the shortcomings
of our current implementation with do_not_suspend() code sprinkled all
over the place instead of sitting down and making suspend from idle
work. It's more or less trivial depending on the platform, but not
rocket science.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> 
> This is where you are wrong.  Maybe not wrong in principle, but wrong 
> in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
> implementation is _very_ different from C-states (or just "idle").

Holy bouncing cow. I damned good know that the current implementation
is not doing that and that suspend is implemented in a totally
different way. That does not mean that this is written in stone. We
CAN change that and fix it to gain opportunistic suspend.
 
> The primary difference is that the kernel can be forced into suspend
> even when the system isn't idle.  In particular, it may be in the
> middle of processing a potential wakeup event -- and the current design
> gives the PM core no way to know if that is so.  This is a weakness
> that in-kernel suspend blockers fix.

Oh no. They paper over a short coming. If there is a pending event,
the kernel knows that. It just does not make use of this
information. Blockers just paper over this by sprinkling
do_not_suspend() calls all over the place. What a sensible solution.

> With C-states this can't happen.  If the CPU goes into a deeper C-state 
> then ipso facto it isn't busy processing anything, much less a wakeup 
> event.

And that's the whole point of doing the opportunistic suspend with the
help of the scheduler.

> Now maybe this difference is a bad thing, and the whole PM 
> suspend/hibernate infrastructure should be rewritten.  But the fact, 
> remains, that's how it works now.  And it can't be changed easily or 
> quickly.

So what you are saying is that we better paper over the shortcomings
of our current implementation with do_not_suspend() code sprinkled all
over the place instead of sitting down and making suspend from idle
work. It's more or less trivial depending on the platform, but not
rocket science.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:

> Suppose X (or whatever windowing system) will block all clients that try
> to draw when you switch off your screen.
> 
> How would we not wake them when we do turn the screen back on and start
> servicing the pending requests again?

How (and why) does the WoL (which may be *any* packet, not just a magic 
one) turn the screen back on?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:

> Suppose X (or whatever windowing system) will block all clients that try
> to draw when you switch off your screen.
> 
> How would we not wake them when we do turn the screen back on and start
> servicing the pending requests again?

How (and why) does the WoL (which may be *any* packet, not just a magic 
one) turn the screen back on?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
> On Thu, 27 May 2010 18:45:25 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> > 
> > And there is the whole problem. Switching from normal event delivery
> > to those special wakeup sources. That needs to be engineered in any
> > case carefuly and it does not matter whether you add suspend blockers
> > or not.
> 
> Ok, I just don't know the answer: How is it just another idle state if
> the userspace gets frozen? Doesn't that bork the whole transition and
> you need a userspace<->kernel synchronisation point to not loose events?

There is no userspace to freeze when the runqueues are empty.

And as explained, you won't loose events if all the devices do a proper
state transition. To quote:

On Thu, 2010-05-27 at 18:45 +0200, Thomas Gleixner wrote:
> If the interrupt happens _BEFORE_ we switch over to the quiescent
> state, then we need to backout. If it happens after the switch then it
> goes into the nirwana if the suspend wakeup has not been set up
> correctly. If we have it setup correctly then we go into suspend just
> to come back immediately. There is nothing you can do about that with
> suspend blockers.
> 

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
> On Thu, 27 May 2010 18:45:25 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which has longer takedown and wakeup latencies and
> > requires to shut down stuff and setup extra wakeup sources.
> > 
> > And there is the whole problem. Switching from normal event delivery
> > to those special wakeup sources. That needs to be engineered in any
> > case carefuly and it does not matter whether you add suspend blockers
> > or not.
> 
> Ok, I just don't know the answer: How is it just another idle state if
> the userspace gets frozen? Doesn't that bork the whole transition and
> you need a userspace<->kernel synchronisation point to not loose events?

There is no userspace to freeze when the runqueues are empty.

And as explained, you won't loose events if all the devices do a proper
state transition. To quote:

On Thu, 2010-05-27 at 18:45 +0200, Thomas Gleixner wrote:
> If the interrupt happens _BEFORE_ we switch over to the quiescent
> state, then we need to backout. If it happens after the switch then it
> goes into the nirwana if the suspend wakeup has not been set up
> correctly. If we have it setup correctly then we go into suspend just
> to come back immediately. There is nothing you can do about that with
> suspend blockers.
> 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Felipe Balbi wrote:
> 
> > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > >If people don't mind, here is a greatly simplified summary of the
> > >comments and objections I have seen so far on this thread:
> > >
> > >	The in-kernel suspend blocker implementation is okay, even
> > >	beneficial.
> > 
> > I disagree here. I believe expressing that as QoS is much better. Let 
> > the kernel decide which power state is better as long as I can say I 
> > need 100us IRQ latency or 100ms wakeup latency.
> 
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed?  Or "echo disk >/sys/power/state"?  They pay no

mem should be replaced by an idle suspend to ram mechanism

> attention to latencies or other requirements.

s2disk is a totally different beast as it shuts down the box into the
complete power off state.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Felipe Balbi wrote:
> 
> > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > >If people don't mind, here is a greatly simplified summary of the
> > >comments and objections I have seen so far on this thread:
> > >
> > >	The in-kernel suspend blocker implementation is okay, even
> > >	beneficial.
> > 
> > I disagree here. I believe expressing that as QoS is much better. Let 
> > the kernel decide which power state is better as long as I can say I 
> > need 100us IRQ latency or 100ms wakeup latency.
> 
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed?  Or "echo disk >/sys/power/state"?  They pay no

mem should be replaced by an idle suspend to ram mechanism

> attention to latencies or other requirements.

s2disk is a totally different beast as it shuts down the box into the
complete power off state.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote:
> > > Opportunistic suspend is just a deep idle state, nothing else.
> > 
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> Nothing gets scheduled in a deep idle state either - its idle. We leave
> the idle state to schedule anything.

Certainly, if you can force the system to be idle then you don't need 
opportunistic suspend. But you haven't shown how to do that without it 
being racey.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote:
> > > Opportunistic suspend is just a deep idle state, nothing else.
> > 
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> Nothing gets scheduled in a deep idle state either - its idle. We leave
> the idle state to schedule anything.

Certainly, if you can force the system to be idle then you don't need 
opportunistic suspend. But you haven't shown how to do that without it 
being racey.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:23 +0100, Matthew Garrett wrote:
> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it. 

If all of userspace is blocked on devices, WTH is keeping us from
hitting it?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:23 +0100, Matthew Garrett wrote:
> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it. 

If all of userspace is blocked on devices, WTH is keeping us from
hitting it?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
> 
> > Suppose X (or whatever windowing system) will block all clients that try
> > to draw when you switch off your screen.
> > 
> > How would we not wake them when we do turn the screen back on and start
> > servicing the pending requests again?
> 
> How (and why) does the WoL (which may be *any* packet, not just a magic 
> one) turn the screen back on?

Why would you care about the screen for a network event?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
> 
> > Suppose X (or whatever windowing system) will block all clients that try
> > to draw when you switch off your screen.
> > 
> > How would we not wake them when we do turn the screen back on and start
> > servicing the pending requests again?
> 
> How (and why) does the WoL (which may be *any* packet, not just a magic 
> one) turn the screen back on?

Why would you care about the screen for a network event?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> > 
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > attention to latencies or other requirements. 
> 
> Those are a whole different beast, those are basically a quick-off
> button like thing. Forced suspend is conceptually a very different beast
> from power-saving a running system.

They may be different conceptually.  Nevertheless, Android uses forced 
suspend as a form of power saving.  Until better mechanisms are in 
place, it makes sense.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> > 
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > attention to latencies or other requirements. 
> 
> Those are a whole different beast, those are basically a quick-off
> button like thing. Forced suspend is conceptually a very different beast
> from power-saving a running system.

They may be different conceptually.  Nevertheless, Android uses forced 
suspend as a form of power saving.  Until better mechanisms are in 
place, it makes sense.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > Opportunistic suspend is just a deep idle state, nothing else.
> 
> No. The useful property of opportunistic suspend is that nothing gets 
> scheduled. That's fundamentally different to a deep idle state.

Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to schedule anything.

I believe the constraint is

- Do not auto-enter a state for which you cannot maintain the devices in
  use "properly".

On a current PC that generally means 'not suspend', on a lot of embedded
boards (including Android phones) it includes an opportunistic 'suspend'
and also several states half way between the PC deepest idles and suspend.

> > Stop thinking about suspend as a special mechanism. It's not - except
> > for s2disk, which is an entirely different beast.
> 
> On PCs, suspend has more in common with s2disk than it does C states.

Todays PCs are a special case. More to the point I don't think anyone is
expected opportunistic suspend to be useful on _todays_ x86 systems.

Even on todays PCs your assumption is questionable for virtual machines
where a VM suspend is a lot faster and rather useful.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > Opportunistic suspend is just a deep idle state, nothing else.
> 
> No. The useful property of opportunistic suspend is that nothing gets 
> scheduled. That's fundamentally different to a deep idle state.

Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to schedule anything.

I believe the constraint is

- Do not auto-enter a state for which you cannot maintain the devices in
  use "properly".

On a current PC that generally means 'not suspend', on a lot of embedded
boards (including Android phones) it includes an opportunistic 'suspend'
and also several states half way between the PC deepest idles and suspend.

> > Stop thinking about suspend as a special mechanism. It's not - except
> > for s2disk, which is an entirely different beast.
> 
> On PCs, suspend has more in common with s2disk than it does C states.

Todays PCs are a special case. More to the point I don't think anyone is
expected opportunistic suspend to be useful on _todays_ x86 systems.

Even on todays PCs your assumption is questionable for virtual machines
where a VM suspend is a lot faster and rather useful.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:

> Oh no. They paper over a short coming. If there is a pending event,
> the kernel knows that. It just does not make use of this
> information. Blockers just paper over this by sprinkling
> do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need 
to be able to enter suspend while the system isn't idle. There's two 
ways to do that:

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely 
on the scheduler, we need drivers to know whether userspace has consumed 
all wakeup events before allowing the transition to occur. Doing so 
requires either in-kernel suspend blockers or something that's almost 
identical.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:

> Oh no. They paper over a short coming. If there is a pending event,
> the kernel knows that. It just does not make use of this
> information. Blockers just paper over this by sprinkling
> do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need 
to be able to enter suspend while the system isn't idle. There's two 
ways to do that:

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely 
on the scheduler, we need drivers to know whether userspace has consumed 
all wakeup events before allowing the transition to occur. Doing so 
requires either in-kernel suspend blockers or something that's almost 
identical.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
> 
> They may be different conceptually.  Nevertheless, Android uses forced 
> suspend as a form of power saving.  Until better mechanisms are in 
> place, it makes sense. 

So let them, doesn't mean we have to merge it. Or will you saw your foot
off too if google were to promotes it?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
> 
> They may be different conceptually.  Nevertheless, Android uses forced 
> suspend as a form of power saving.  Until better mechanisms are in 
> place, it makes sense. 

So let them, doesn't mean we have to merge it. Or will you saw your foot
off too if google were to promotes it?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > one) turn the screen back on?
> 
> Why would you care about the screen for a network event?

Because the application that needs to handle the network packet is 
currently blocked trying to draw something to the screen.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > one) turn the screen back on?
> 
> Why would you care about the screen for a network event?

Because the application that needs to handle the network packet is 
currently blocked trying to draw something to the screen.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:

> > > Opportunistic suspend is just a deep idle state, nothing else.
> > 
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
> 
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
> 
> So why isn't blocking every task on a QoS/resource good enough for you?

On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle.  That used to be
the case on Android.  Arve has said that it isn't necessarily true any
more, but that's the way their software is set up.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:

> > > Opportunistic suspend is just a deep idle state, nothing else.
> > 
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
> 
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
> 
> So why isn't blocking every task on a QoS/resource good enough for you?

On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle.  That used to be
the case on Android.  Arve has said that it isn't necessarily true any
more, but that's the way their software is set up.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:

> > > Opportunistic suspend is just a deep idle state, nothing else.
> > 
> > No. The useful property of opportunistic suspend is that nothing gets 
> > scheduled. That's fundamentally different to a deep idle state.
> 
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
> 
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
> 
> So why isn't blocking every task on a QoS/resource good enough for you?

On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle.  That used to be
the case on Android.  Arve has said that it isn't necessarily true any
more, but that's the way their software is set up.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:

> Even if we could use suspend-via-deep-idle-state on PCs, 

( see Alan Cox's argument on PCs )

> we still need to be able to enter suspend while the system isn't idle.

_WHY_!?

We've been trying to tell you you don't need that.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:

> Even if we could use suspend-via-deep-idle-state on PCs, 

( see Alan Cox's argument on PCs )

> we still need to be able to enter suspend while the system isn't idle.

_WHY_!?

We've been trying to tell you you don't need that.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > > one) turn the screen back on?
> > 
> > Why would you care about the screen for a network event?
> 
> Because the application that needs to handle the network packet is 
> currently blocked trying to draw something to the screen.

Then that's an application bug right there, isn't it?

If should have listened to the window server telling its clients it was
going to go away. Drawing after you get that is your own damn fault ;-)

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > > one) turn the screen back on?
> > 
> > Why would you care about the screen for a network event?
> 
> Because the application that needs to handle the network packet is 
> currently blocked trying to draw something to the screen.

Then that's an application bug right there, isn't it?

If should have listened to the window server telling its clients it was
going to go away. Drawing after you get that is your own damn fault ;-)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just papering over that w/o tackling the
> real problem.

That's the point -- suspend does not evaluate the system state 
correctly because it doesn't have the necessary information.  Suspend 
blockers are a way of providing it that information.  They don't paper 
over the problem; they solve it.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just papering over that w/o tackling the
> real problem.

That's the point -- suspend does not evaluate the system state 
correctly because it doesn't have the necessary information.  Suspend 
blockers are a way of providing it that information.  They don't paper 
over the problem; they solve it.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just papering over that w/o tackling the
> real problem.

That's the point -- suspend does not evaluate the system state 
correctly because it doesn't have the necessary information.  Suspend 
blockers are a way of providing it that information.  They don't paper 
over the problem; they solve it.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:

> On some platforms (like those with ACPI), deeper power-savings are
> available by using forced suspend than by using idle. 

Sounds like something that's fixable, doesn't it?

>  That used to be
> the case on Android.  Arve has said that it isn't necessarily true any
> more, but that's the way their software is set up.

Who cares about their current software? We're arguing about sensible
interfaces for the technical problem posed.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:

> On some platforms (like those with ACPI), deeper power-savings are
> available by using forced suspend than by using idle. 

Sounds like something that's fixable, doesn't it?

>  That used to be
> the case on Android.  Arve has said that it isn't necessarily true any
> more, but that's the way their software is set up.

Who cares about their current software? We're arguing about sensible
interfaces for the technical problem posed.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > we still need to be able to enter suspend while the system isn't idle.
> 
> _WHY_!?

Because if I'm running a kernel build in a tmpfs and I hit the sleep 
key, I need to go to sleep. Blocking processes on driver access isn't 
sufficient.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > we still need to be able to enter suspend while the system isn't idle.
> 
> _WHY_!?

Because if I'm running a kernel build in a tmpfs and I hit the sleep 
key, I need to go to sleep. Blocking processes on driver access isn't 
sufficient.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> 
> mem should be replaced by an idle suspend to ram mechanism

In other words, you are suggesting that not only should the Android
patches not be accepted, in addition a large part of the PM suspend
framework should be rewritten?

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> 
> mem should be replaced by an idle suspend to ram mechanism

In other words, you are suggesting that not only should the Android
patches not be accepted, in addition a large part of the PM suspend
framework should be rewritten?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > Why would you care about the screen for a network event?
> > 
> > Because the application that needs to handle the network packet is 
> > currently blocked trying to draw something to the screen.
> 
> Then that's an application bug right there, isn't it?
> 
> If should have listened to the window server telling its clients it was
> going to go away. Drawing after you get that is your own damn fault ;-)

How long do you wait for applications to respond that they've stopped 
drawing? What if the application is heavily in swap at the time?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > Why would you care about the screen for a network event?
> > 
> > Because the application that needs to handle the network packet is 
> > currently blocked trying to draw something to the screen.
> 
> Then that's an application bug right there, isn't it?
> 
> If should have listened to the window server telling its clients it was
> going to go away. Drawing after you get that is your own damn fault ;-)

How long do you wait for applications to respond that they've stopped 
drawing? What if the application is heavily in swap at the time?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 19:25:27 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
> > On Thu, 27 May 2010 18:45:25 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> > 
> > > The whole notion of treating suspend to RAM any different than a plain
> > > idle C-State is wrong. It's not different at all. You just use a
> > > different mechanism which has longer takedown and wakeup latencies and
> > > requires to shut down stuff and setup extra wakeup sources.
> > > 
> > > And there is the whole problem. Switching from normal event delivery
> > > to those special wakeup sources. That needs to be engineered in any
> > > case carefuly and it does not matter whether you add suspend blockers
> > > or not.
> > 
> > Ok, I just don't know the answer: How is it just another idle state if
> > the userspace gets frozen? Doesn't that bork the whole transition and
> > you need a userspace<->kernel synchronisation point to not loose events?
> 
> There is no userspace to freeze when the runqueues are empty.

If in the imaginery situation where userspace can aquire certain
wakeup-constraints and loose certain wakeup-constraints, then it could
be that the system enters suspend without empty runqueues. 

> And as explained, you won't loose events if all the devices do a proper
> state transition. To quote:

I believe the problem beeing userspace frozen at an unopportune time.
So the wakeup event is processed (kernel-side) but userspace didn't
have time to reacquire the correct wakeup-constraint to process the
event.

I.e. the wakeup will be effectivly ignored.


Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 19:25:27 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
> > On Thu, 27 May 2010 18:45:25 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> > 
> > > The whole notion of treating suspend to RAM any different than a plain
> > > idle C-State is wrong. It's not different at all. You just use a
> > > different mechanism which has longer takedown and wakeup latencies and
> > > requires to shut down stuff and setup extra wakeup sources.
> > > 
> > > And there is the whole problem. Switching from normal event delivery
> > > to those special wakeup sources. That needs to be engineered in any
> > > case carefuly and it does not matter whether you add suspend blockers
> > > or not.
> > 
> > Ok, I just don't know the answer: How is it just another idle state if
> > the userspace gets frozen? Doesn't that bork the whole transition and
> > you need a userspace<->kernel synchronisation point to not loose events?
> 
> There is no userspace to freeze when the runqueues are empty.

If in the imaginery situation where userspace can aquire certain
wakeup-constraints and loose certain wakeup-constraints, then it could
be that the system enters suspend without empty runqueues. 

> And as explained, you won't loose events if all the devices do a proper
> state transition. To quote:

I believe the problem beeing userspace frozen at an unopportune time.
So the wakeup event is processed (kernel-side) but userspace didn't
have time to reacquire the correct wakeup-constraint to process the
event.

I.e. the wakeup will be effectivly ignored.


Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
> 
> > Even if we could use suspend-via-deep-idle-state on PCs, 
> 
> ( see Alan Cox's argument on PCs )
> 
> > we still need to be able to enter suspend while the system isn't idle.
> 
> _WHY_!?

You close your laptop's lid and throw the machine into a backpack.  At 
that time you want it to suspend even though it may not be idle.

> We've been trying to tell you you don't need that.

And I'm trying to tell you that you do.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
> 
> > Even if we could use suspend-via-deep-idle-state on PCs, 
> 
> ( see Alan Cox's argument on PCs )
> 
> > we still need to be able to enter suspend while the system isn't idle.
> 
> _WHY_!?

You close your laptop's lid and throw the machine into a backpack.  At 
that time you want it to suspend even though it may not be idle.

> We've been trying to tell you you don't need that.

And I'm trying to tell you that you do.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
> 
> > Even if we could use suspend-via-deep-idle-state on PCs, 
> 
> ( see Alan Cox's argument on PCs )
> 
> > we still need to be able to enter suspend while the system isn't idle.
> 
> _WHY_!?

You close your laptop's lid and throw the machine into a backpack.  At 
that time you want it to suspend even though it may not be idle.

> We've been trying to tell you you don't need that.

And I'm trying to tell you that you do.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network event?
> > > 
> > > Because the application that needs to handle the network packet is 
> > > currently blocked trying to draw something to the screen.
> > 
> > Then that's an application bug right there, isn't it?
> > 
> > If should have listened to the window server telling its clients it was
> > going to go away. Drawing after you get that is your own damn fault ;-)
> 
> How long do you wait for applications to respond that they've stopped 
> drawing? What if the application is heavily in swap at the time?

Since we're talking about a purely idle driven power saving, we wait
until the cpu is idle.

Note that it doesn't need to broadcast this, it could opt to reply with
that message on the first drawing attempt after it goes away and block
on the second.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network event?
> > > 
> > > Because the application that needs to handle the network packet is 
> > > currently blocked trying to draw something to the screen.
> > 
> > Then that's an application bug right there, isn't it?
> > 
> > If should have listened to the window server telling its clients it was
> > going to go away. Drawing after you get that is your own damn fault ;-)
> 
> How long do you wait for applications to respond that they've stopped 
> drawing? What if the application is heavily in swap at the time?

Since we're talking about a purely idle driven power saving, we wait
until the cpu is idle.

Note that it doesn't need to broadcast this, it could opt to reply with
that message on the first drawing attempt after it goes away and block
on the second.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

But that's a whole different issue. I agree that a forced suspend for
things like that make sense, just not for power managing a running
system. PC style hardware like that doesn't wake up from suspend for
funny things like a keypress either (good thing too).

Anyway all that already works (more or less), so I don't see the
problem.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

But that's a whole different issue. I agree that a forced suspend for
things like that make sense, just not for power managing a running
system. PC style hardware like that doesn't wake up from suspend for
funny things like a keypress either (good thing too).

Anyway all that already works (more or less), so I don't see the
problem.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> What is a "Correctly implemented driver" in this case? One that receives 
> a wakeup event and then prevents suspend being entered until userspace 
> has acknowledged that event? Because that's what an in-kernel suspend 
> blocker is.

Kernel side maybe - but even then its a subset of expressing
latency/lowest level requirements. That bit isn't really too contentious.
You need a kernel object to hang a constraint off.

> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it.

So PCs with current ACPI don't get opportunistic suspend capability. It
probably won't be supported on the Commodore Amiga either - your point ?

> Suspend blockers are the mechanism for the 
> driver to indicate whether the wakeup event has been handled. That's 
> what they're there for. The in-kernel ones don't paper over anything.

Semantically the in kernel blockers and the in kernel expression of
device driven constraints are the same thing except that instead of 
yes/no you replace the boolean with information.


So we go from

	block_suspend() / unblock_suspend()

to
	add_pm_constraint(latency, level) 
	remove_pm_constraint(latency, level);


And if Android choses to interpret that in its policy code as

	if (latency > MAGIC)
		suspend_is_cool();
	else
		suspend_isnt_cool();

that's now isolated in droidspace policy

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> What is a "Correctly implemented driver" in this case? One that receives 
> a wakeup event and then prevents suspend being entered until userspace 
> has acknowledged that event? Because that's what an in-kernel suspend 
> blocker is.

Kernel side maybe - but even then its a subset of expressing
latency/lowest level requirements. That bit isn't really too contentious.
You need a kernel object to hang a constraint off.

> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it.

So PCs with current ACPI don't get opportunistic suspend capability. It
probably won't be supported on the Commodore Amiga either - your point ?

> Suspend blockers are the mechanism for the 
> driver to indicate whether the wakeup event has been handled. That's 
> what they're there for. The in-kernel ones don't paper over anything.

Semantically the in kernel blockers and the in kernel expression of
device driven constraints are the same thing except that instead of 
yes/no you replace the boolean with information.


So we go from

	block_suspend() / unblock_suspend()

to
	add_pm_constraint(latency, level) 
	remove_pm_constraint(latency, level);


And if Android choses to interpret that in its policy code as

	if (latency > MAGIC)
		suspend_is_cool();
	else
		suspend_isnt_cool();

that's now isolated in droidspace policy

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > ACPI provides no guarantees about what level of hardware functionality 
> > remains during S3. You don't have any useful ability to determine which 
> > events will generate wakeups. And from a purely practical point of view, 
> > since the latency is in the range of seconds, you'll never have a low 
> > enough wakeup rate to hit it.
> 
> So PCs with current ACPI don't get opportunistic suspend capability. It
> probably won't be supported on the Commodore Amiga either - your point ?

Actually, the reverse - there's no terribly good way to make PCs work 
with scheduler-based suspend, but there's no reason why they wouldn't 
work with the current opportunistic suspend implementation.

> > Suspend blockers are the mechanism for the 
> > driver to indicate whether the wakeup event has been handled. That's 
> > what they're there for. The in-kernel ones don't paper over anything.
> 
> Semantically the in kernel blockers and the in kernel expression of
> device driven constraints are the same thing except that instead of 
> yes/no you replace the boolean with information.

In some cases, not all. It may be a latency constraint (in which case 
pm_qos is an appropriate mechanism), but instead it may be something 
like "A key was pressed but never read" or "A network packet was 
received but not delivered". These don't fit into the pm_qos model, but 
it's state that you have to track.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > ACPI provides no guarantees about what level of hardware functionality 
> > remains during S3. You don't have any useful ability to determine which 
> > events will generate wakeups. And from a purely practical point of view, 
> > since the latency is in the range of seconds, you'll never have a low 
> > enough wakeup rate to hit it.
> 
> So PCs with current ACPI don't get opportunistic suspend capability. It
> probably won't be supported on the Commodore Amiga either - your point ?

Actually, the reverse - there's no terribly good way to make PCs work 
with scheduler-based suspend, but there's no reason why they wouldn't 
work with the current opportunistic suspend implementation.

> > Suspend blockers are the mechanism for the 
> > driver to indicate whether the wakeup event has been handled. That's 
> > what they're there for. The in-kernel ones don't paper over anything.
> 
> Semantically the in kernel blockers and the in kernel expression of
> device driven constraints are the same thing except that instead of 
> yes/no you replace the boolean with information.

In some cases, not all. It may be a latency constraint (in which case 
pm_qos is an appropriate mechanism), but instead it may be something 
like "A key was pressed but never read" or "A network packet was 
received but not delivered". These don't fit into the pm_qos model, but 
it's state that you have to track.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:42 +0200, Florian Mickler wrote:

> If in the imaginery situation where userspace can aquire certain
> wakeup-constraints and loose certain wakeup-constraints, then it could
> be that the system enters suspend without empty runqueues. 

No. Wakeup constaints simply delay wakeups, not loose them.

If there's something runnable, we run it.

What could happen is that you try to program a timer every 5ms, but then
QoS won't let you and errors the timer_create() or something. But then
the app gets to deal with it.

> > And as explained, you won't loose events if all the devices do a proper
> > state transition. To quote:
> 
> I believe the problem beeing userspace frozen at an unopportune time.
> So the wakeup event is processed (kernel-side) but userspace didn't
> have time to reacquire the correct wakeup-constraint to process the
> event.
> 
> I.e. the wakeup will be effectivly ignored.

How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
handler gets run, handler generates a task wakeup, runqueue isn't empty,
we run stuff.

I'm not quite sure how to loose something there.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:42 +0200, Florian Mickler wrote:

> If in the imaginery situation where userspace can aquire certain
> wakeup-constraints and loose certain wakeup-constraints, then it could
> be that the system enters suspend without empty runqueues. 

No. Wakeup constaints simply delay wakeups, not loose them.

If there's something runnable, we run it.

What could happen is that you try to program a timer every 5ms, but then
QoS won't let you and errors the timer_create() or something. But then
the app gets to deal with it.

> > And as explained, you won't loose events if all the devices do a proper
> > state transition. To quote:
> 
> I believe the problem beeing userspace frozen at an unopportune time.
> So the wakeup event is processed (kernel-side) but userspace didn't
> have time to reacquire the correct wakeup-constraint to process the
> event.
> 
> I.e. the wakeup will be effectivly ignored.

How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
handler gets run, handler generates a task wakeup, runqueue isn't empty,
we run stuff.

I'm not quite sure how to loose something there.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > > Then that's an application bug right there, isn't it?
> > > 
> > > If should have listened to the window server telling its clients it was
> > > going to go away. Drawing after you get that is your own damn fault ;-)
> > 
> > How long do you wait for applications to respond that they've stopped 
> > drawing? What if the application is heavily in swap at the time?
> 
> Since we're talking about a purely idle driven power saving, we wait
> until the cpu is idle.

If that's what you're aiming for then you don't need to block 
applications on hardware access because they should all already have 
idled themselves.

> Note that it doesn't need to broadcast this, it could opt to reply with
> that message on the first drawing attempt after it goes away and block
> on the second.

That's more interesting, but you're changing semantics quite heavily at 
this point.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > > Then that's an application bug right there, isn't it?
> > > 
> > > If should have listened to the window server telling its clients it was
> > > going to go away. Drawing after you get that is your own damn fault ;-)
> > 
> > How long do you wait for applications to respond that they've stopped 
> > drawing? What if the application is heavily in swap at the time?
> 
> Since we're talking about a purely idle driven power saving, we wait
> until the cpu is idle.

If that's what you're aiming for then you don't need to block 
applications on hardware access because they should all already have 
idled themselves.

> Note that it doesn't need to broadcast this, it could opt to reply with
> that message on the first drawing attempt after it goes away and block
> on the second.

That's more interesting, but you're changing semantics quite heavily at 
this point.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote:

> You close your laptop's lid and throw the machine into a backpack.  At 
> that time you want it to suspend even though it may not be idle.
> 
> > We've been trying to tell you you don't need that.
> 
> And I'm trying to tell you that you do.

Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote:

> You close your laptop's lid and throw the machine into a backpack.  At 
> that time you want it to suspend even though it may not be idle.
> 
> > We've been trying to tell you you don't need that.
> 
> And I'm trying to tell you that you do.

Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:

> How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> handler gets run, handler generates a task wakeup, runqueue isn't empty,
> we run stuff.

If you're using idle-based suspend without any forced idling or blocking 
of applications then you don't lose wakeups. People keep conflating 
separate issues.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:

> How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> handler gets run, handler generates a task wakeup, runqueue isn't empty,
> we run stuff.

If you're using idle-based suspend without any forced idling or blocking 
of applications then you don't lose wakeups. People keep conflating 
separate issues.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:

> If that's what you're aiming for then you don't need to block 
> applications on hardware access because they should all already have 
> idled themselves.

Correct, a well behaved app would have. I thought we all agreed that
well behaved apps weren't the problem?

> > Note that it doesn't need to broadcast this, it could opt to reply with
> > that message on the first drawing attempt after it goes away and block
> > on the second.
> 
> That's more interesting, but you're changing semantics quite heavily at 
> this point.

So?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:

> If that's what you're aiming for then you don't need to block 
> applications on hardware access because they should all already have 
> idled themselves.

Correct, a well behaved app would have. I thought we all agreed that
well behaved apps weren't the problem?

> > Note that it doesn't need to broadcast this, it could opt to reply with
> > that message on the first drawing attempt after it goes away and block
> > on the second.
> 
> That's more interesting, but you're changing semantics quite heavily at 
> this point.

So?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:

> Shall we henceforth stop confusing forced suspend for laptops and
> powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid 
the risk of losing wakeups then you need in-kernel suspend blockers. 
That's entirely orthogonal to Android's runtime power management.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:

> Shall we henceforth stop confusing forced suspend for laptops and
> powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid 
the risk of losing wakeups then you need in-kernel suspend blockers. 
That's entirely orthogonal to Android's runtime power management.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > My question was about explicit suspend states, not implicitly handling 
> > > an identical state based on scheduler constraints. Suspend-as-a-C-state 
> > > isn't usable on x86 - you have to explicitly trigger it based on some 
> > 
> > And why not ? Just because suspend is not implemented as an ACPI
> > C-state ? 
> > 
> > Nonsense, if we want to push the system into suspend from the idle
> > state we can do that. It's just not implemented and we've never tried
> > to do it as it requires a non trivial amount of work, but I have done
> > it on an ARM two years ago as a prove of concept and it works like a
> > charm.
> 
> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it.

Right, it does not as of today. So we cannot use that on x86
hardware. Fine. That does not prevent us to implement it for
architectures which can do it. And if x86 comes to the point where it
can handle it as well we're going to use it. Where is the problem ? If
x86 cannot guarantee the wakeup sources it's not going to be used for
such devices. The kernel just does not provide the service for it, so
what ?
 
> > > policy. And if you want to be able to do that without risking the loss 
> > > of wakeup events then you need in-kernel suspend blockers.
> > 
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate the system
> > state correctly. Blockers are just papering over that w/o tackling the
> > real problem.
> 
> Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the 
> driver to indicate whether the wakeup event has been handled. That's 
> what they're there for. The in-kernel ones don't paper over anything.

So the driver says: events have been handled. Neat.

Now if that crappy app does not use the user space blockers or is not
allowed to use them, then what are you guaranteeing ? All you
guarantee is that the application has emptied the input queue. Nothing
else. And that's the same as setting the QoS guarantee to NONE.

An application which uses the blocker is just holding off the system
from going into deep idle. Nothing which cannot be done today.

So the only thing you are imposing to app writers is to use an
interface which solves nothing and does not save you any power at
all. 

If the application drops the blocker after processing the event and
before it goes back to the read event then you just postpone the CPU
usage and therefor power consumption to a later point in time instead
of going back to the blocking read right away. 

Again what is it saving ?  NOTHING!  And for nothing you want to mess
up the kernel big time ?

Runnable tasks and QoS guarantees are the indicators whether you can
go to opportunistic suspend or not. Everything else is just window
dressing.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > My question was about explicit suspend states, not implicitly handling 
> > > an identical state based on scheduler constraints. Suspend-as-a-C-state 
> > > isn't usable on x86 - you have to explicitly trigger it based on some 
> > 
> > And why not ? Just because suspend is not implemented as an ACPI
> > C-state ? 
> > 
> > Nonsense, if we want to push the system into suspend from the idle
> > state we can do that. It's just not implemented and we've never tried
> > to do it as it requires a non trivial amount of work, but I have done
> > it on an ARM two years ago as a prove of concept and it works like a
> > charm.
> 
> ACPI provides no guarantees about what level of hardware functionality 
> remains during S3. You don't have any useful ability to determine which 
> events will generate wakeups. And from a purely practical point of view, 
> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it.

Right, it does not as of today. So we cannot use that on x86
hardware. Fine. That does not prevent us to implement it for
architectures which can do it. And if x86 comes to the point where it
can handle it as well we're going to use it. Where is the problem ? If
x86 cannot guarantee the wakeup sources it's not going to be used for
such devices. The kernel just does not provide the service for it, so
what ?
 
> > > policy. And if you want to be able to do that without risking the loss 
> > > of wakeup events then you need in-kernel suspend blockers.
> > 
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate the system
> > state correctly. Blockers are just papering over that w/o tackling the
> > real problem.
> 
> Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the 
> driver to indicate whether the wakeup event has been handled. That's 
> what they're there for. The in-kernel ones don't paper over anything.

So the driver says: events have been handled. Neat.

Now if that crappy app does not use the user space blockers or is not
allowed to use them, then what are you guaranteeing ? All you
guarantee is that the application has emptied the input queue. Nothing
else. And that's the same as setting the QoS guarantee to NONE.

An application which uses the blocker is just holding off the system
from going into deep idle. Nothing which cannot be done today.

So the only thing you are imposing to app writers is to use an
interface which solves nothing and does not save you any power at
all. 

If the application drops the blocker after processing the event and
before it goes back to the read event then you just postpone the CPU
usage and therefor power consumption to a later point in time instead
of going back to the blocking read right away. 

Again what is it saving ?  NOTHING!  And for nothing you want to mess
up the kernel big time ?

Runnable tasks and QoS guarantees are the indicators whether you can
go to opportunistic suspend or not. Everything else is just window
dressing.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> 
> > If that's what you're aiming for then you don't need to block 
> > applications on hardware access because they should all already have 
> > idled themselves.
> 
> Correct, a well behaved app would have. I thought we all agreed that
> well behaved apps weren't the problem?

Ok. So the existing badly-behaved application ignores your request and 
then gets blocked. And now it no longer responds to wakeup events. So 
you penalise well-behaved applications without providing any benefits to 
badly-behaved ones.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> 
> > If that's what you're aiming for then you don't need to block 
> > applications on hardware access because they should all already have 
> > idled themselves.
> 
> Correct, a well behaved app would have. I thought we all agreed that
> well behaved apps weren't the problem?

Ok. So the existing badly-behaved application ignores your request and 
then gets blocked. And now it no longer responds to wakeup events. So 
you penalise well-behaved applications without providing any benefits to 
badly-behaved ones.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> network packet arrives. The difference between these scenarios is large.

Your application seems to change desired outcome every email. Sorry but
you need to explicitly explain and define a policy in full that we can
test ideas against. Otherwise this is useless.

> > If you have wake-on-lan then the network stack might be smarter and
> > choose to express itself as
> > 
> > 	'the constraint is C6 unless the input queue is empty in which
> > 	 case suspend is ok as I have WoL and my network routing is such
> > 	 that I can prove that interface will be used'
> 
> This is still racy. Going back to this:
> 
> int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> char foo;
> struct sockaddr addr;
> connect (input, &addr, sizeof(addr))
> while (1) {
>        if (read(input, &foo, 1) > 0) {
>                (do something)
>        } else {
> 		* SUSPEND OCCURS HERE *

Fine but then the packet will arrive and we will wake back up process the
packet and wake the task. See suspend is just like a deep sleep. If we
went to sleep there and the packet arrival doesn't rewake the box the
driver was buggy.

> reaches the end of its timeslice. At this point the application has not 
> had an opportunity to indicate in any way whether or not the packet has 
> altered its constraints in any way. What stops us from immediately 
> suspending again?

If my app level constraint before the packet is 'don't suspend' then my
constraint on receipt is 'don't suspend' so I won't suspend. If my
constraint is then lowered and I suspend I will suspend *after* the
lowering.

If my constraint is tightened then the decision to tighten is run under
the previous constraint. Which is fine, because if I have a case where I
must tighten my constraint within the tight constraint time I've screwed
up my app and need to fix it.

In reality almost all your userspace is going to look like 'trusted app'
or 'untrusted app' in droidthink and won't be transitioning in user space
(but may well be adding/losing kernel constraints)

This is good because it's another thing app authors don't have to care
about. It's good because apps can be run trusted/untrusted without
recompiling.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> network packet arrives. The difference between these scenarios is large.

Your application seems to change desired outcome every email. Sorry but
you need to explicitly explain and define a policy in full that we can
test ideas against. Otherwise this is useless.

> > If you have wake-on-lan then the network stack might be smarter and
> > choose to express itself as
> > 
> > 	'the constraint is C6 unless the input queue is empty in which
> > 	 case suspend is ok as I have WoL and my network routing is such
> > 	 that I can prove that interface will be used'
> 
> This is still racy. Going back to this:
> 
> int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> char foo;
> struct sockaddr addr;
> connect (input, &addr, sizeof(addr))
> while (1) {
>        if (read(input, &foo, 1) > 0) {
>                (do something)
>        } else {
> 		* SUSPEND OCCURS HERE *

Fine but then the packet will arrive and we will wake back up process the
packet and wake the task. See suspend is just like a deep sleep. If we
went to sleep there and the packet arrival doesn't rewake the box the
driver was buggy.

> reaches the end of its timeslice. At this point the application has not 
> had an opportunity to indicate in any way whether or not the packet has 
> altered its constraints in any way. What stops us from immediately 
> suspending again?

If my app level constraint before the packet is 'don't suspend' then my
constraint on receipt is 'don't suspend' so I won't suspend. If my
constraint is then lowered and I suspend I will suspend *after* the
lowering.

If my constraint is tightened then the decision to tighten is run under
the previous constraint. Which is fine, because if I have a case where I
must tighten my constraint within the tight constraint time I've screwed
up my app and need to fix it.

In reality almost all your userspace is going to look like 'trusted app'
or 'untrusted app' in droidthink and won't be transitioning in user space
(but may well be adding/losing kernel constraints)

This is good because it's another thing app authors don't have to care
about. It's good because apps can be run trusted/untrusted without
recompiling.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers. 
> That's entirely orthogonal to Android's runtime power management.

The simple fact of life is, on PC style hardware suspend is mostly about
missing events. I really _really_ want to miss mouse movement of my
bluetooth mouse when the gear is stowed in my backpack.

Its perfectly OK to miss events on _forced_ suspend.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers. 
> That's entirely orthogonal to Android's runtime power management.

The simple fact of life is, on PC style hardware suspend is mostly about
missing events. I really _really_ want to miss mouse movement of my
bluetooth mouse when the gear is stowed in my backpack.

Its perfectly OK to miss events on _forced_ suspend.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
> 
> > How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> > handler gets run, handler generates a task wakeup, runqueue isn't empty,
> > we run stuff.
> 
> If you're using idle-based suspend without any forced idling or blocking 
> of applications then you don't lose wakeups. People keep conflating 
> separate issues.

I still don't see how blocking applications will cause missed wakeups in
anything but a buggy application at worst, and even those will
eventually get the event when they unblock.

What seems to be the confusion?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
> 
> > How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> > handler gets run, handler generates a task wakeup, runqueue isn't empty,
> > we run stuff.
> 
> If you're using idle-based suspend without any forced idling or blocking 
> of applications then you don't lose wakeups. People keep conflating 
> separate issues.

I still don't see how blocking applications will cause missed wakeups in
anything but a buggy application at worst, and even those will
eventually get the event when they unblock.

What seems to be the confusion?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:40:19 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

Suspend as an idle state

Suspend as a 'hand of God' choice.

One is a performance optimisation the other is an operator executive
decision.

I'd prefer we avoided mixing them up. Everyone seems fairly happy with
the current operator ordered suspend behaviour I believe ?

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:40:19 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

Suspend as an idle state

Suspend as a 'hand of God' choice.

One is a performance optimisation the other is an operator executive
decision.

I'd prefer we avoided mixing them up. Everyone seems fairly happy with
the current operator ordered suspend behaviour I believe ?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> 
> > Oh no. They paper over a short coming. If there is a pending event,
> > the kernel knows that. It just does not make use of this
> > information. Blockers just paper over this by sprinkling
> > do_not_suspend() calls all over the place. What a sensible solution.
> 
> Even if we could use suspend-via-deep-idle-state on PCs, we still need 
> to be able to enter suspend while the system isn't idle. There's two 
> ways to do that:
> 
> 1) Force the system to be idle. Doing this race-free is difficult.
> 
> 2) Enter suspend even though the system isn't idle. Since we can't rely 
> on the scheduler, we need drivers to know whether userspace has consumed 
> all wakeup events before allowing the transition to occur. Doing so 
> requires either in-kernel suspend blockers or something that's almost 
> identical.

You're just not getting it. If user space has consumed the event is
not relevant at all.

What's relevant is whether the app has processed the event and reacted
accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the
app goes back in to blocked/idle state. You have to spend the CPU
cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue
empty indicator is just bullshit, because after emptying the queue the
kernel can go into suspend w/o any guarantee that the event has been
processed.

The whole concept sucks, as it does not solve anything. Burning power
now or in 100ms is the same thing power consumption wise.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> 
> > Oh no. They paper over a short coming. If there is a pending event,
> > the kernel knows that. It just does not make use of this
> > information. Blockers just paper over this by sprinkling
> > do_not_suspend() calls all over the place. What a sensible solution.
> 
> Even if we could use suspend-via-deep-idle-state on PCs, we still need 
> to be able to enter suspend while the system isn't idle. There's two 
> ways to do that:
> 
> 1) Force the system to be idle. Doing this race-free is difficult.
> 
> 2) Enter suspend even though the system isn't idle. Since we can't rely 
> on the scheduler, we need drivers to know whether userspace has consumed 
> all wakeup events before allowing the transition to occur. Doing so 
> requires either in-kernel suspend blockers or something that's almost 
> identical.

You're just not getting it. If user space has consumed the event is
not relevant at all.

What's relevant is whether the app has processed the event and reacted
accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the
app goes back in to blocked/idle state. You have to spend the CPU
cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue
empty indicator is just bullshit, because after emptying the queue the
kernel can go into suspend w/o any guarantee that the event has been
processed.

The whole concept sucks, as it does not solve anything. Burning power
now or in 100ms is the same thing power consumption wise.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > 
> > > If that's what you're aiming for then you don't need to block 
> > > applications on hardware access because they should all already have 
> > > idled themselves.
> > 
> > Correct, a well behaved app would have. I thought we all agreed that
> > well behaved apps weren't the problem?
> 
> Ok. So the existing badly-behaved application ignores your request and 
> then gets blocked. And now it no longer responds to wakeup events. 

It will, when it gets unblocked from whatever thing it got stuck on.

> So you penalise well-behaved applications without providing any benefits to 
> badly-behaved ones.

Uhm, how again is blocking a badly behaved app causing harm to the well
behaved one?

The well behaved one didn't get blocked and still happily waiting (on
its own accord, in sys_poll() or something) for something to happen, if
it would get an event it'd be placed on the runqueue and do its thing.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > 
> > > If that's what you're aiming for then you don't need to block 
> > > applications on hardware access because they should all already have 
> > > idled themselves.
> > 
> > Correct, a well behaved app would have. I thought we all agreed that
> > well behaved apps weren't the problem?
> 
> Ok. So the existing badly-behaved application ignores your request and 
> then gets blocked. And now it no longer responds to wakeup events. 

It will, when it gets unblocked from whatever thing it got stuck on.

> So you penalise well-behaved applications without providing any benefits to 
> badly-behaved ones.

Uhm, how again is blocking a badly behaved app causing harm to the well
behaved one?

The well behaved one didn't get blocked and still happily waiting (on
its own accord, in sys_poll() or something) for something to happen, if
it would get an event it'd be placed on the runqueue and do its thing.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate the system
> > state correctly. Blockers are just papering over that w/o tackling the
> > real problem.
> 
> That's the point -- suspend does not evaluate the system state 
> correctly because it doesn't have the necessary information.  Suspend 
> blockers are a way of providing it that information.  They don't paper 
> over the problem; they solve it.

Nonsense. The system state is well defined when a event is pending and
we just have to say good bye to the idea that forced suspend is a good
solution. It's not as it does not guarantee the event processing in
badly written apps and it does move the power consumption to a later
point in time for those apps which acquire/drop the blockers.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate the system
> > state correctly. Blockers are just papering over that w/o tackling the
> > real problem.
> 
> That's the point -- suspend does not evaluate the system state 
> correctly because it doesn't have the necessary information.  Suspend 
> blockers are a way of providing it that information.  They don't paper 
> over the problem; they solve it.

Nonsense. The system state is well defined when a event is pending and
we just have to say good bye to the idea that forced suspend is a good
solution. It's not as it does not guarantee the event processing in
badly written apps and it does move the power consumption to a later
point in time for those apps which acquire/drop the blockers.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network event?
> > > 
> > > Because the application that needs to handle the network packet is 
> > > currently blocked trying to draw something to the screen.
> > 
> > Then that's an application bug right there, isn't it?
> > 
> > If should have listened to the window server telling its clients it was
> > going to go away. Drawing after you get that is your own damn fault ;-)
> 
> How long do you wait for applications to respond that they've stopped 
> drawing? What if the application is heavily in swap at the time?

Very realistic scenario on a mobile phone. 

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network event?
> > > 
> > > Because the application that needs to handle the network packet is 
> > > currently blocked trying to draw something to the screen.
> > 
> > Then that's an application bug right there, isn't it?
> > 
> > If should have listened to the window server telling its clients it was
> > going to go away. Drawing after you get that is your own damn fault ;-)
> 
> How long do you wait for applications to respond that they've stopped 
> drawing? What if the application is heavily in swap at the time?

Very realistic scenario on a mobile phone. 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> > 
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >        if (read(input, &foo, 1) > 0) {
> >                (do something)
> >        } else {
> > 		* SUSPEND OCCURS HERE *
> 
> Fine but then the packet will arrive and we will wake back up process the
> packet and wake the task. See suspend is just like a deep sleep. If we
> went to sleep there and the packet arrival doesn't rewake the box the
> driver was buggy.

Yes, there's no problem so far. The question is how you guarantee that 
the application has had the opportunity to handle the packet.

> > reaches the end of its timeslice. At this point the application has not 
> > had an opportunity to indicate in any way whether or not the packet has 
> > altered its constraints in any way. What stops us from immediately 
> > suspending again?
> 
> If my app level constraint before the packet is 'don't suspend' then my
> constraint on receipt is 'don't suspend' so I won't suspend. If my
> constraint is then lowered and I suspend I will suspend *after* the
> lowering.

If the app level constraint before the packet was "don't suspend", we 
wouldn't have suspended. Here's a description of the desired behaviour 
of the application as you requested:

The application is a network monitoring app that renders server state 
via animated bouncing cows. The desired behaviour is that the 
application will cease to be scheduled if the session becomes idle 
(where idle is defined as the system having received no user input for 
30 seconds) but that push notifications from the server still be 
received in order to allow the application to present the user with 
critical alerts.

Under Android:

User puts down phone. 30 seconds later the screen turns off and releases 
the last user-level suspend block. The phone enters suspend and the 
application is suspended. A network packet is received, causing the 
network driver to take a suspend block. The application finishes the 
frame it was drawing, takes its own suspend block and reads the network 
packet. In doing so the network driver releases its suspend block, but 
since userspace is holding one the phone stays awake. The application 
then handles the event as necessary, releases its suspend block and the 
phone goes to sleep again.

I don't see how this behaviour can be emulated in your model.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> > 
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >        if (read(input, &foo, 1) > 0) {
> >                (do something)
> >        } else {
> > 		* SUSPEND OCCURS HERE *
> 
> Fine but then the packet will arrive and we will wake back up process the
> packet and wake the task. See suspend is just like a deep sleep. If we
> went to sleep there and the packet arrival doesn't rewake the box the
> driver was buggy.

Yes, there's no problem so far. The question is how you guarantee that 
the application has had the opportunity to handle the packet.

> > reaches the end of its timeslice. At this point the application has not 
> > had an opportunity to indicate in any way whether or not the packet has 
> > altered its constraints in any way. What stops us from immediately 
> > suspending again?
> 
> If my app level constraint before the packet is 'don't suspend' then my
> constraint on receipt is 'don't suspend' so I won't suspend. If my
> constraint is then lowered and I suspend I will suspend *after* the
> lowering.

If the app level constraint before the packet was "don't suspend", we 
wouldn't have suspended. Here's a description of the desired behaviour 
of the application as you requested:

The application is a network monitoring app that renders server state 
via animated bouncing cows. The desired behaviour is that the 
application will cease to be scheduled if the session becomes idle 
(where idle is defined as the system having received no user input for 
30 seconds) but that push notifications from the server still be 
received in order to allow the application to present the user with 
critical alerts.

Under Android:

User puts down phone. 30 seconds later the screen turns off and releases 
the last user-level suspend block. The phone enters suspend and the 
application is suspended. A network packet is received, causing the 
network driver to take a suspend block. The application finishes the 
frame it was drawing, takes its own suspend block and reads the network 
packet. In doing so the network driver releases its suspend block, but 
since userspace is holding one the phone stays awake. The application 
then handles the event as necessary, releases its suspend block and the 
phone goes to sleep again.

I don't see how this behaviour can be emulated in your model.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> >
> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> >> > opportunistic suspend, and a wakeup event occurs but no suspend
> >> > blockers get enabled by the handler, what causes the system to go back
> >> > into suspend after the event is handled?  Isn't that a loop of some
> >> > sort?
> >> >
> >>
> >> Yes it is a loop. I think what you are missing is that it only loops
> >> repeatedly if the driver that aborts suspend does not use a suspend
> >> blocker.
> >
> > You mean "the driver that handles the wakeup event".  I was asking what
> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> > a suspend blocker is used then its release causes another suspend
> > attempt, with no looping.
> >
> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >>
> >> It is a significant power drain.
> >
> > Not in the situation I was discussing.
> >
> 
> If you meant it spend most of the time suspended, then I agree. It
> only wastes power when a driver blocks suspend by returning an error
> from its suspend hook and we are forced to loop doing no useful work.
> 

If driver refuses to suspend that means there are events that need
processing. I fail to see why it would be called "looping doing no
useful work".

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> >
> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> >> > opportunistic suspend, and a wakeup event occurs but no suspend
> >> > blockers get enabled by the handler, what causes the system to go back
> >> > into suspend after the event is handled?  Isn't that a loop of some
> >> > sort?
> >> >
> >>
> >> Yes it is a loop. I think what you are missing is that it only loops
> >> repeatedly if the driver that aborts suspend does not use a suspend
> >> blocker.
> >
> > You mean "the driver that handles the wakeup event".  I was asking what
> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> > a suspend blocker is used then its release causes another suspend
> > attempt, with no looping.
> >
> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >>
> >> It is a significant power drain.
> >
> > Not in the situation I was discussing.
> >
> 
> If you meant it spend most of the time suspended, then I agree. It
> only wastes power when a driver blocks suspend by returning an error
> from its suspend hook and we are forced to loop doing no useful work.
> 

If driver refuses to suspend that means there are events that need
processing. I fail to see why it would be called "looping doing no
useful work".

-- 
Dmitry

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

That's the difference between opportunistic and enforced suspend. On
enforced suspend the QoS guarantee is forced to NONE for everything
and you go down no matter what. When you decide to push the wakeup
button the system restores.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> > 
> > _WHY_!?
> 
> Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> key, I need to go to sleep. Blocking processes on driver access isn't 
> sufficient.

That's the difference between opportunistic and enforced suspend. On
enforced suspend the QoS guarantee is forced to NONE for everything
and you go down no matter what. When you decide to push the wakeup
button the system restores.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> > If you want to support forced suspend for laptops and you want to avoid 
> > the risk of losing wakeups then you need in-kernel suspend blockers. 
> > That's entirely orthogonal to Android's runtime power management.
> 
> The simple fact of life is, on PC style hardware suspend is mostly about
> missing events. I really _really_ want to miss mouse movement of my
> bluetooth mouse when the gear is stowed in my backpack.

That's fine - those shouldn't be configured as wakeup events.

> Its perfectly OK to miss events on _forced_ suspend.

No, it's not. Forced suspend may be in response to hitting a key, but it 
may also be in response to a 30 minute timeout expiring. If I get a WoL 
packet in the 0.5 of a second between userspace deciding to suspend and 
actually doing so, the system shouldn't suspend.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> > If you want to support forced suspend for laptops and you want to avoid 
> > the risk of losing wakeups then you need in-kernel suspend blockers. 
> > That's entirely orthogonal to Android's runtime power management.
> 
> The simple fact of life is, on PC style hardware suspend is mostly about
> missing events. I really _really_ want to miss mouse movement of my
> bluetooth mouse when the gear is stowed in my backpack.

That's fine - those shouldn't be configured as wakeup events.

> Its perfectly OK to miss events on _forced_ suspend.

No, it's not. Forced suspend may be in response to hitting a key, but it 
may also be in response to a 30 minute timeout expiring. If I get a WoL 
packet in the 0.5 of a second between userspace deciding to suspend and 
actually doing so, the system shouldn't suspend.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:

> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> the current operator ordered suspend behaviour I believe ?

No. The current mechanism can lose wakeup events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:

> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> the current operator ordered suspend behaviour I believe ?

No. The current mechanism can lose wakeup events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:05:39PM +0200, Thomas Gleixner wrote:

> You're just not getting it. If user space has consumed the event is
> not relevant at all.
> 
> What's relevant is whether the app has processed the event and reacted
> accordingly. That's all that matters.

And how do you know that? We can't rely on the process scheduler.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:05:39PM +0200, Thomas Gleixner wrote:

> You're just not getting it. If user space has consumed the event is
> not relevant at all.
> 
> What's relevant is whether the app has processed the event and reacted
> accordingly. That's all that matters.

And how do you know that? We can't rely on the process scheduler.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
> 
> Actually, the reverse - there's no terribly good way to make PCs work 
> with scheduler-based suspend, but there's no reason why they wouldn't 
> work with the current opportunistic suspend implementation.

If one works so does the other.

> In some cases, not all. It may be a latency constraint (in which case 
> pm_qos is an appropriate mechanism), but instead it may be something 
> like "A key was pressed but never read" or "A network packet was 
> received but not delivered". These don't fit into the pm_qos model, but 
> it's state that you have to track.

I never mentioned pm_qos, just latency *and* knowing what suspend states
are acceptable. You need both.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
> 
> Actually, the reverse - there's no terribly good way to make PCs work 
> with scheduler-based suspend, but there's no reason why they wouldn't 
> work with the current opportunistic suspend implementation.

If one works so does the other.

> In some cases, not all. It may be a latency constraint (in which case 
> pm_qos is an appropriate mechanism), but instead it may be something 
> like "A key was pressed but never read" or "A network packet was 
> received but not delivered". These don't fit into the pm_qos model, but 
> it's state that you have to track.

I never mentioned pm_qos, just latency *and* knowing what suspend states
are acceptable. You need both.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > > 
> > > > If that's what you're aiming for then you don't need to block 
> > > > applications on hardware access because they should all already have 
> > > > idled themselves.
> > > 
> > > Correct, a well behaved app would have. I thought we all agreed that
> > > well behaved apps weren't the problem?
> > 
> > Ok. So the existing badly-behaved application ignores your request and 
> > then gets blocked. And now it no longer responds to wakeup events. 
> 
> It will, when it gets unblocked from whatever thing it got stuck on.

It's blocked on the screen being turned off. It's supposed to be reading 
a network packet. How does it ever get to reading the network packet?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > > 
> > > > If that's what you're aiming for then you don't need to block 
> > > > applications on hardware access because they should all already have 
> > > > idled themselves.
> > > 
> > > Correct, a well behaved app would have. I thought we all agreed that
> > > well behaved apps weren't the problem?
> > 
> > Ok. So the existing badly-behaved application ignores your request and 
> > then gets blocked. And now it no longer responds to wakeup events. 
> 
> It will, when it gets unblocked from whatever thing it got stuck on.

It's blocked on the screen being turned off. It's supposed to be reading 
a network packet. How does it ever get to reading the network packet?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> If I get a WoL 
> packet in the 0.5 of a second between userspace deciding to suspend and 
> actually doing so, the system shouldn't suspend. 

Please re-read Thomas' description of how a driver should do the state
transition.

So either we get the packet before suspend, and we cancel the suspend,
or we get it after and we wake up. What's the problem, and how does that
need suspend blockers?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> If I get a WoL 
> packet in the 0.5 of a second between userspace deciding to suspend and 
> actually doing so, the system shouldn't suspend. 

Please re-read Thomas' description of how a driver should do the state
transition.

So either we get the packet before suspend, and we cancel the suspend,
or we get it after and we wake up. What's the problem, and how does that
need suspend blockers?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > > ACPI provides no guarantees about what level of hardware functionality 
> > > remains during S3. You don't have any useful ability to determine which 
> > > events will generate wakeups. And from a purely practical point of view, 
> > > since the latency is in the range of seconds, you'll never have a low 
> > > enough wakeup rate to hit it.
> > 
> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
> 
> Actually, the reverse - there's no terribly good way to make PCs work 
> with scheduler-based suspend, but there's no reason why they wouldn't 
> work with the current opportunistic suspend implementation.

How does that solve the problems you mentioned above ? Wakeup
guarantees, latencies ...

It's not a prove of the technical correctness of the approach if it
can provide a useless functionality.
 
Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > > ACPI provides no guarantees about what level of hardware functionality 
> > > remains during S3. You don't have any useful ability to determine which 
> > > events will generate wakeups. And from a purely practical point of view, 
> > > since the latency is in the range of seconds, you'll never have a low 
> > > enough wakeup rate to hit it.
> > 
> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
> 
> Actually, the reverse - there's no terribly good way to make PCs work 
> with scheduler-based suspend, but there's no reason why they wouldn't 
> work with the current opportunistic suspend implementation.

How does that solve the problems you mentioned above ? Wakeup
guarantees, latencies ...

It's not a prove of the technical correctness of the approach if it
can provide a useless functionality.
 
Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:12:15PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > How long do you wait for applications to respond that they've stopped 
> > drawing? What if the application is heavily in swap at the time?
> 
> Very realistic scenario on a mobile phone. 

If the aim is to produce a solution that isn't special-cased to specific 
devices, thinking about how long an application may take to respond is 
entirely relevant.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:12:15PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > How long do you wait for applications to respond that they've stopped 
> > drawing? What if the application is heavily in swap at the time?
> 
> Very realistic scenario on a mobile phone. 

If the aim is to produce a solution that isn't special-cased to specific 
devices, thinking about how long an application may take to respond is 
entirely relevant.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:57:19 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers.

It isn't suspend blockers or nothing. Look at the bigger picture.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:57:19 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers.

It isn't suspend blockers or nothing. Look at the bigger picture.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:17:16PM +0100, Alan Cox wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work 
> > with scheduler-based suspend, but there's no reason why they wouldn't 
> > work with the current opportunistic suspend implementation.
> 
> If one works so does the other.

Not at all. The entire point of opportunistic suspend is that I don't 
care is currently in TASK_RUNNABLE or has a timer that's due to expire 
in 100msec - based on policy (through not having any held suspend 
blockers), I'll go to sleep. That's easily possible on PCs.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:17:16PM +0100, Alan Cox wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work 
> > with scheduler-based suspend, but there's no reason why they wouldn't 
> > work with the current opportunistic suspend implementation.
> 
> If one works so does the other.

Not at all. The entire point of opportunistic suspend is that I don't 
care is currently in TASK_RUNNABLE or has a timer that's due to expire 
in 100msec - based on policy (through not having any held suspend 
blockers), I'll go to sleep. That's easily possible on PCs.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:

> It's blocked on the screen being turned off. It's supposed to be reading 
> a network packet. How does it ever get to reading the network packet?

Its blocked because its a buggy app, who cares about misbehaviour in a
buggy app?

If it were a proper app it wouldn't have gotten blocked and would've
been able to receive the network packet.

I thought we'd already been over this?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:

> It's blocked on the screen being turned off. It's supposed to be reading 
> a network packet. How does it ever get to reading the network packet?

Its blocked because its a buggy app, who cares about misbehaviour in a
buggy app?

If it were a proper app it wouldn't have gotten blocked and would've
been able to receive the network packet.

I thought we'd already been over this?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work 
> > with scheduler-based suspend, but there's no reason why they wouldn't 
> > work with the current opportunistic suspend implementation.
> 
> How does that solve the problems you mentioned above ? Wakeup
> guarantees, latencies ...

Latency doesn't matter because we don't care when the next timer is due 
to expire. Wakeup guarantees can be provided via the suspend blocker 
implementation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work 
> > with scheduler-based suspend, but there's no reason why they wouldn't 
> > work with the current opportunistic suspend implementation.
> 
> How does that solve the problems you mentioned above ? Wakeup
> guarantees, latencies ...

Latency doesn't matter because we don't care when the next timer is due 
to expire. Wakeup guarantees can be provided via the suspend blocker 
implementation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > ACPI provides no guarantees about what level of hardware functionality 
> > remains during S3. You don't have any useful ability to determine which 
> > events will generate wakeups. And from a purely practical point of view, 
> > since the latency is in the range of seconds, you'll never have a low 
> > enough wakeup rate to hit it.
> 
> Right, it does not as of today. So we cannot use that on x86
> hardware. Fine. That does not prevent us to implement it for
> architectures which can do it. And if x86 comes to the point where it
> can handle it as well we're going to use it. Where is the problem ? If
> x86 cannot guarantee the wakeup sources it's not going to be used for
> such devices. The kernel just does not provide the service for it, so
> what ?

We were talking about PCs. Suspend-as-c-state is already implemented for 
OMAP.

> So the only thing you are imposing to app writers is to use an
> interface which solves nothing and does not save you any power at
> all. 

It's already been demonstrated that the Android approach saves power.

> Runnable tasks and QoS guarantees are the indicators whether you can
> go to opportunistic suspend or not. Everything else is just window
> dressing.

As I keep saying, this is all much less interesting if you don't care 
about handling suboptimal applications. If you do care about them then 
the Android approach works. Nobody has demonstrated a scheduler-based 
one that does.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > ACPI provides no guarantees about what level of hardware functionality 
> > remains during S3. You don't have any useful ability to determine which 
> > events will generate wakeups. And from a purely practical point of view, 
> > since the latency is in the range of seconds, you'll never have a low 
> > enough wakeup rate to hit it.
> 
> Right, it does not as of today. So we cannot use that on x86
> hardware. Fine. That does not prevent us to implement it for
> architectures which can do it. And if x86 comes to the point where it
> can handle it as well we're going to use it. Where is the problem ? If
> x86 cannot guarantee the wakeup sources it's not going to be used for
> such devices. The kernel just does not provide the service for it, so
> what ?

We were talking about PCs. Suspend-as-c-state is already implemented for 
OMAP.

> So the only thing you are imposing to app writers is to use an
> interface which solves nothing and does not save you any power at
> all. 

It's already been demonstrated that the Android approach saves power.

> Runnable tasks and QoS guarantees are the indicators whether you can
> go to opportunistic suspend or not. Everything else is just window
> dressing.

As I keep saying, this is all much less interesting if you don't care 
about handling suboptimal applications. If you do care about them then 
the Android approach works. Nobody has demonstrated a scheduler-based 
one that does.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend. 
> 
> Please re-read Thomas' description of how a driver should do the state
> transition.
>
> So either we get the packet before suspend, and we cancel the suspend,
> or we get it after and we wake up. What's the problem, and how does that
> need suspend blockers?

In order to cancel the suspend we need to keep track of whether 
userspace has consumed the event and reacted appropriately. Since we 
can't do this with the process scheduler, we end up with something that 
looks like suspend blockers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend. 
> 
> Please re-read Thomas' description of how a driver should do the state
> transition.
>
> So either we get the packet before suspend, and we cancel the suspend,
> or we get it after and we wake up. What's the problem, and how does that
> need suspend blockers?

In order to cancel the suspend we need to keep track of whether 
userspace has consumed the event and reacted appropriately. Since we 
can't do this with the process scheduler, we end up with something that 
looks like suspend blockers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
> 
> > It's blocked on the screen being turned off. It's supposed to be reading 
> > a network packet. How does it ever get to reading the network packet?
> 
> Its blocked because its a buggy app, who cares about misbehaviour in a
> buggy app?

So why bother blocking? Just kill the app and tell the user. If you want 
to support suboptimal apps then blocking isn't sufficient. If you don't 
want to then blocking isn't necessary.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
> 
> > It's blocked on the screen being turned off. It's supposed to be reading 
> > a network packet. How does it ever get to reading the network packet?
> 
> Its blocked because its a buggy app, who cares about misbehaviour in a
> buggy app?

So why bother blocking? Just kill the app and tell the user. If you want 
to support suboptimal apps then blocking isn't sufficient. If you don't 
want to then blocking isn't necessary.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> So you need
> 
> 	Userspace -> QoS guarantee expression, implied resource
> 			expression via device use. *NO* knowledge of
> 			device or platform in the application

I have a pile of use cases where I want to turn off "implied resource
expression via device use."  There are two orthogonal variables to
consider:

1.  I'm drawing cows on the screen (or asking another process to do so
on my behalf).

2.  I care whether anyone can actually see the cows, and I'm willing
(or not) to burn power to make them visible.

Quite often, I'm drawing cows but I don't care about cow visibility,
so I would tell PM to turn the display off when the PM framework is
looking for ways to conserve power; however, if the animated cow is part
of an alarm clock application, then I want the display on, powering it
up if was previously turned off.

A real-world example of this is a backup process on a file server.
I'd like to tell the kernel that the backup process's CPU usage and
disk I/O is *not* implied resource expression, and if there's no other
processes using the CPU or disks, the kernel can just power down the
drives or idle the CPU on a whim.  The backup process can hang until
some other process comes along to wake the drives and CPU up again,
and then the backups will run during the idle time while the drive
is waiting for new requests from other processes.  Obviously if the
backup process is trying to write dirty pages to a powered-down drive
there will be problems (memory starvation and lost data come to mind),
so I'd make sure I don't do that.

I'd also like to change my mind about these sorts of things on the fly,
without requiring hooks in the backup process itself.  I'm thinking
of a syscall with PID, FD, mode bits (read/write?  iowait/runnable?),
and policy (whether usage implies expression).

I can express mostly the same things if "policy" was "maximum latency,"
but not all.  Consider how you'd have to specify latencies to get hard
disks that spin down when idle, spin up immediately if read requests are
issued, but wait several minutes to spin up if write requests are issued.
I can't specify that with a single latency value since it would result
in either unacceptably large latencies in some cases, or the disks
would never spin down.  I'd need a matrix with drive power states as
rows and read/write operations as columns, either per process or per
file descriptor.  Also something in user-space needs to know about the
approximate value for hard disk spin-up times in order to set their PM
QoS constraints high enough to be useful but also low enough to be useful.

Well, maybe the last problem can be resolved by specifying QoS constraints
in bands.  You'd have a QOS_OTHER band that applies to processes that
haven't specified a constraint, and a QOS_EXPLICIT band that applies to
those that have, and you'd be able to change all the QOS_OTHER processes
at once.

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> So you need
> 
> 	Userspace -> QoS guarantee expression, implied resource
> 			expression via device use. *NO* knowledge of
> 			device or platform in the application

I have a pile of use cases where I want to turn off "implied resource
expression via device use."  There are two orthogonal variables to
consider:

1.  I'm drawing cows on the screen (or asking another process to do so
on my behalf).

2.  I care whether anyone can actually see the cows, and I'm willing
(or not) to burn power to make them visible.

Quite often, I'm drawing cows but I don't care about cow visibility,
so I would tell PM to turn the display off when the PM framework is
looking for ways to conserve power; however, if the animated cow is part
of an alarm clock application, then I want the display on, powering it
up if was previously turned off.

A real-world example of this is a backup process on a file server.
I'd like to tell the kernel that the backup process's CPU usage and
disk I/O is *not* implied resource expression, and if there's no other
processes using the CPU or disks, the kernel can just power down the
drives or idle the CPU on a whim.  The backup process can hang until
some other process comes along to wake the drives and CPU up again,
and then the backups will run during the idle time while the drive
is waiting for new requests from other processes.  Obviously if the
backup process is trying to write dirty pages to a powered-down drive
there will be problems (memory starvation and lost data come to mind),
so I'd make sure I don't do that.

I'd also like to change my mind about these sorts of things on the fly,
without requiring hooks in the backup process itself.  I'm thinking
of a syscall with PID, FD, mode bits (read/write?  iowait/runnable?),
and policy (whether usage implies expression).

I can express mostly the same things if "policy" was "maximum latency,"
but not all.  Consider how you'd have to specify latencies to get hard
disks that spin down when idle, spin up immediately if read requests are
issued, but wait several minutes to spin up if write requests are issued.
I can't specify that with a single latency value since it would result
in either unacceptably large latencies in some cases, or the disks
would never spin down.  I'd need a matrix with drive power states as
rows and read/write operations as columns, either per process or per
file descriptor.  Also something in user-space needs to know about the
approximate value for hard disk spin-up times in order to set their PM
QoS constraints high enough to be useful but also low enough to be useful.

Well, maybe the last problem can be resolved by specifying QoS constraints
in bands.  You'd have a QOS_OTHER band that applies to processes that
haven't specified a constraint, and a QOS_EXPLICIT band that applies to
those that have, and you'd be able to change all the QOS_OTHER processes
at once.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
>
>> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
>> the current operator ordered suspend behaviour I believe ?
>
> No. The current mechanism can lose wakeup events.

And the proposed solution (suspend blockers) does nothing to solve the
loss of wakeup events during forced suspend.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
>
>> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
>> the current operator ordered suspend behaviour I believe ?
>
> No. The current mechanism can lose wakeup events.

And the proposed solution (suspend blockers) does nothing to solve the
loss of wakeup events during forced suspend.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Yes, there's no problem so far. The question is how you guarantee that 
> the application has had the opportunity to handle the packet.

Because the application has said that it wants QoS guarantees. It wants
to know that if the events it can receive occur it will wake up within
the timescale.

So it receives the event. It's now running, not idle so we won't suspend
it.

At some point in time it will become idle again _or_ the CPU limit will
get it.


If the app is not trusted then we might suspend it before it handles the
packet. That is fine, it's not trusted and we will do that when we decide
its in the system interest to suspend it anyway.

You still don't lose the event because on resume the task will do its
processing.


> The application is a network monitoring app that renders server state 
> via animated bouncing cows. The desired behaviour is that the 
> application will cease to be scheduled if the session becomes idle 
> (where idle is defined as the system having received no user input for 
> 30 seconds) but that push notifications from the server still be 
> received in order to allow the application to present the user with 
> critical alerts.

This is a bit confusing - does the screen come back on for such events,
what constraints is the server operating under ? How does your code look
- it's hard to imagine the examples you've given as being workable given
they would block on network packet wait when a critical event occurs.
Are you using poll or threads or what ?

> Under Android:
> 
> User puts down phone. 30 seconds later the screen turns off and releases 
> the last user-level suspend block. The phone enters suspend and the 
> application is suspended. A network packet is received, causing the 
> network driver to take a suspend block. The application finishes the 
> frame it was drawing, takes its own suspend block and reads the network 
> packet. In doing so the network driver releases its suspend block, but 
> since userspace is holding one the phone stays awake. The application 
> then handles the event as necessary, releases its suspend block and the 
> phone goes to sleep again.
> 
> I don't see how this behaviour can be emulated in your model.

User puts down phone. 30 seconds later the X server decides to turn the
screen off and closes the device. This probalby releases the constraint
held via the display driver not to suspend. Any further draw requests will
block.

System looks at the other tasks and sees they are idle and can sink to a
low power state. Cows is either blocked on a packet receive or could even
be blocked on writing to the display (or both if its a realistic example
and using poll)

Everyone is idle, we can sleep

The kernel looks at the constraints it has
	- must not sink to a state below which network receive of packets
	  fails
	- must not sink below a state where whatever is needed for the
	  critical alert code etc to do its stuff
	- must not sink to a state which takes more than [constraint]
	  seconds to get back out of

It picks 'opportunistic suspend'
It goes to sleep

A packet arrives
It wakes the hardware
We are busy, we do not wish to suspend
It processes the packet
It wakes the user app
It starts processing the packet
[We are busy, we do not wish to suspend]

Presumably your display server listens to waking back up and decides to
re-activate the screen (your example is unclear and implies it carries on
processing the extra frame in the dark which seems a bit silly ?

I still don't see a problem. 

I think your problem arises because you start from the basis that forcing
suspend is special. As Thomas has said there are working implementations
where suspend is an idle mode.

The moment you discard that specific notion everything works, as it does
today on other embedded platforms.

Now what do you do if the app is burning too much processor time. That's
a QoS question too. We've got cpu limits, we've got SIGXCPU, we don't
have "cpu per second" type limits but that isn't hard to do either.

Stop transitioning Run->Forced Suspend. If you've got stuff stuck running
then deal with it by constraining it to go idle or by blowing it out of
the water. PM will then do the rest.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Yes, there's no problem so far. The question is how you guarantee that 
> the application has had the opportunity to handle the packet.

Because the application has said that it wants QoS guarantees. It wants
to know that if the events it can receive occur it will wake up within
the timescale.

So it receives the event. It's now running, not idle so we won't suspend
it.

At some point in time it will become idle again _or_ the CPU limit will
get it.


If the app is not trusted then we might suspend it before it handles the
packet. That is fine, it's not trusted and we will do that when we decide
its in the system interest to suspend it anyway.

You still don't lose the event because on resume the task will do its
processing.


> The application is a network monitoring app that renders server state 
> via animated bouncing cows. The desired behaviour is that the 
> application will cease to be scheduled if the session becomes idle 
> (where idle is defined as the system having received no user input for 
> 30 seconds) but that push notifications from the server still be 
> received in order to allow the application to present the user with 
> critical alerts.

This is a bit confusing - does the screen come back on for such events,
what constraints is the server operating under ? How does your code look
- it's hard to imagine the examples you've given as being workable given
they would block on network packet wait when a critical event occurs.
Are you using poll or threads or what ?

> Under Android:
> 
> User puts down phone. 30 seconds later the screen turns off and releases 
> the last user-level suspend block. The phone enters suspend and the 
> application is suspended. A network packet is received, causing the 
> network driver to take a suspend block. The application finishes the 
> frame it was drawing, takes its own suspend block and reads the network 
> packet. In doing so the network driver releases its suspend block, but 
> since userspace is holding one the phone stays awake. The application 
> then handles the event as necessary, releases its suspend block and the 
> phone goes to sleep again.
> 
> I don't see how this behaviour can be emulated in your model.

User puts down phone. 30 seconds later the X server decides to turn the
screen off and closes the device. This probalby releases the constraint
held via the display driver not to suspend. Any further draw requests will
block.

System looks at the other tasks and sees they are idle and can sink to a
low power state. Cows is either blocked on a packet receive or could even
be blocked on writing to the display (or both if its a realistic example
and using poll)

Everyone is idle, we can sleep

The kernel looks at the constraints it has
	- must not sink to a state below which network receive of packets
	  fails
	- must not sink below a state where whatever is needed for the
	  critical alert code etc to do its stuff
	- must not sink to a state which takes more than [constraint]
	  seconds to get back out of

It picks 'opportunistic suspend'
It goes to sleep

A packet arrives
It wakes the hardware
We are busy, we do not wish to suspend
It processes the packet
It wakes the user app
It starts processing the packet
[We are busy, we do not wish to suspend]

Presumably your display server listens to waking back up and decides to
re-activate the screen (your example is unclear and implies it carries on
processing the extra frame in the dark which seems a bit silly ?

I still don't see a problem. 

I think your problem arises because you start from the basis that forcing
suspend is special. As Thomas has said there are working implementations
where suspend is an idle mode.

The moment you discard that specific notion everything works, as it does
today on other embedded platforms.

Now what do you do if the app is burning too much processor time. That's
a QoS question too. We've got cpu limits, we've got SIGXCPU, we don't
have "cpu per second" type limits but that isn't hard to do either.

Stop transitioning Run->Forced Suspend. If you've got stuff stuck running
then deal with it by constraining it to go idle or by blowing it out of
the water. PM will then do the rest.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > ACPI provides no guarantees about what level of hardware functionality 
> > > remains during S3. You don't have any useful ability to determine which 
> > > events will generate wakeups. And from a purely practical point of view, 
> > > since the latency is in the range of seconds, you'll never have a low 
> > > enough wakeup rate to hit it.
> > 
> > Right, it does not as of today. So we cannot use that on x86
> > hardware. Fine. That does not prevent us to implement it for
> > architectures which can do it. And if x86 comes to the point where it
> > can handle it as well we're going to use it. Where is the problem ? If
> > x86 cannot guarantee the wakeup sources it's not going to be used for
> > such devices. The kernel just does not provide the service for it, so
> > what ?
> 
> We were talking about PCs. Suspend-as-c-state is already implemented for 
> OMAP.
 
Ah, now we talk about PCs. And all of a sudden the problem of the
unability of determining wakeup sources is not longer relevant ? So
how do you guarantee that we don't miss one if we cant figure out
which ones are kept alive in S3 ?

> > So the only thing you are imposing to app writers is to use an
> > interface which solves nothing and does not save you any power at
> > all. 
> 
> It's already been demonstrated that the Android approach saves power.

Demonstrated ? Care to explain me how it makes a difference:

while (1) {
  block();
  read();
  process_event();
  unblock();
		---> suspend
		<--- resume
  do_crap();	1000000 cycles
}

vs.

while (1) {
  read();
		---> suspend
		<--- resume
  process_event();
  do_crap();	1000000 cycles
}

You spend the damned 10000000 cycles in any case just at a different
point in time. So if you are so convinced and have fully understood
all the implications, please enlighten me why do_crap() costs less
power with the blockers approach.

An you are also stubbornly refusing to answer my analysis about the
effect on apps which do not use the blocker or are not allowed to.

1) The kernel blocker does not guarantee that the lousy app has
   processed the event. It just guarantees that the lousy app has
   emptied the input queue. So what's the point of the kernel blocker
   in that case ?

2) What's the difference on setting that app to QoS(NONE) and let the
   kernel happily ignore it.

Come up with real explanations and numbers and not just the "it has
been demonstrated" chant which is not holding water if you look at the
above.
 
> > Runnable tasks and QoS guarantees are the indicators whether you can
> > go to opportunistic suspend or not. Everything else is just window
> > dressing.
> 
> As I keep saying, this is all much less interesting if you don't care 
> about handling suboptimal applications. If you do care about them then 
> the Android approach works. Nobody has demonstrated a scheduler-based 
> one that does.

That does not make the android approach any better. They should have
talked to us upfront and not after the fact. Just because they decided
to do that in their google basement w/o talking to people who care is
not proving that it's a good solution and even less a reason to merge
it as is.

The kernel history is full of examples where crappy solutions got
rejected and kept out of the kernel for a long time even if there was
a need for them in the application field and they got shipped in
quantities with out of tree patches (NOHZ, high resolution timers,
...). At some point people stopped arguing for crappy solutions and
sat down and got it right. The problem of power management and
opportunistic suspend is not different in any way.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > ACPI provides no guarantees about what level of hardware functionality 
> > > remains during S3. You don't have any useful ability to determine which 
> > > events will generate wakeups. And from a purely practical point of view, 
> > > since the latency is in the range of seconds, you'll never have a low 
> > > enough wakeup rate to hit it.
> > 
> > Right, it does not as of today. So we cannot use that on x86
> > hardware. Fine. That does not prevent us to implement it for
> > architectures which can do it. And if x86 comes to the point where it
> > can handle it as well we're going to use it. Where is the problem ? If
> > x86 cannot guarantee the wakeup sources it's not going to be used for
> > such devices. The kernel just does not provide the service for it, so
> > what ?
> 
> We were talking about PCs. Suspend-as-c-state is already implemented for 
> OMAP.
 
Ah, now we talk about PCs. And all of a sudden the problem of the
unability of determining wakeup sources is not longer relevant ? So
how do you guarantee that we don't miss one if we cant figure out
which ones are kept alive in S3 ?

> > So the only thing you are imposing to app writers is to use an
> > interface which solves nothing and does not save you any power at
> > all. 
> 
> It's already been demonstrated that the Android approach saves power.

Demonstrated ? Care to explain me how it makes a difference:

while (1) {
  block();
  read();
  process_event();
  unblock();
		---> suspend
		<--- resume
  do_crap();	1000000 cycles
}

vs.

while (1) {
  read();
		---> suspend
		<--- resume
  process_event();
  do_crap();	1000000 cycles
}

You spend the damned 10000000 cycles in any case just at a different
point in time. So if you are so convinced and have fully understood
all the implications, please enlighten me why do_crap() costs less
power with the blockers approach.

An you are also stubbornly refusing to answer my analysis about the
effect on apps which do not use the blocker or are not allowed to.

1) The kernel blocker does not guarantee that the lousy app has
   processed the event. It just guarantees that the lousy app has
   emptied the input queue. So what's the point of the kernel blocker
   in that case ?

2) What's the difference on setting that app to QoS(NONE) and let the
   kernel happily ignore it.

Come up with real explanations and numbers and not just the "it has
been demonstrated" chant which is not holding water if you look at the
above.
 
> > Runnable tasks and QoS guarantees are the indicators whether you can
> > go to opportunistic suspend or not. Everything else is just window
> > dressing.
> 
> As I keep saying, this is all much less interesting if you don't care 
> about handling suboptimal applications. If you do care about them then 
> the Android approach works. Nobody has demonstrated a scheduler-based 
> one that does.

That does not make the android approach any better. They should have
talked to us upfront and not after the fact. Just because they decided
to do that in their google basement w/o talking to people who care is
not proving that it's a good solution and even less a reason to merge
it as is.

The kernel history is full of examples where crappy solutions got
rejected and kept out of the kernel for a long time even if there was
a need for them in the application field and they got shipped in
quantities with out of tree patches (NOHZ, high resolution timers,
...). At some point people stopped arguing for crappy solutions and
sat down and got it right. The problem of power management and
opportunistic suspend is not different in any way.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > > If I get a WoL 
> > > packet in the 0.5 of a second between userspace deciding to suspend and 
> > > actually doing so, the system shouldn't suspend. 
> > 
> > Please re-read Thomas' description of how a driver should do the state
> > transition.
> >
> > So either we get the packet before suspend, and we cancel the suspend,
> > or we get it after and we wake up. What's the problem, and how does that
> > need suspend blockers?
> 
> In order to cancel the suspend we need to keep track of whether 
> userspace has consumed the event and reacted appropriately. Since we 
> can't do this with the process scheduler, we end up with something that 
> looks like suspend blockers.

And the scheduler based approach does exactly this and provides
exactly the same non guarantees to applications which are set to
QoS(NONE) as it does to applications which do not (or are not allowed
to) use the user space suspend blockers.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > > If I get a WoL 
> > > packet in the 0.5 of a second between userspace deciding to suspend and 
> > > actually doing so, the system shouldn't suspend. 
> > 
> > Please re-read Thomas' description of how a driver should do the state
> > transition.
> >
> > So either we get the packet before suspend, and we cancel the suspend,
> > or we get it after and we wake up. What's the problem, and how does that
> > need suspend blockers?
> 
> In order to cancel the suspend we need to keep track of whether 
> userspace has consumed the event and reacted appropriately. Since we 
> can't do this with the process scheduler, we end up with something that 
> looks like suspend blockers.

And the scheduler based approach does exactly this and provides
exactly the same non guarantees to applications which are set to
QoS(NONE) as it does to applications which do not (or are not allowed
to) use the user space suspend blockers.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote:
> > The application is a network monitoring app that renders server state 
> > via animated bouncing cows. The desired behaviour is that the 
> > application will cease to be scheduled if the session becomes idle 
> > (where idle is defined as the system having received no user input for 
> > 30 seconds) but that push notifications from the server still be 
> > received in order to allow the application to present the user with 
> > critical alerts.
> 
> This is a bit confusing - does the screen come back on for such events,
> what constraints is the server operating under ? How does your code look
> - it's hard to imagine the examples you've given as being workable given
> they would block on network packet wait when a critical event occurs.
> Are you using poll or threads or what ?

It's code that's broadly identical to what I posted. The screen will 
come on if the event is critical, won't otherwise.

> > Under Android:
> > 
> > User puts down phone. 30 seconds later the screen turns off and releases 
> > the last user-level suspend block. The phone enters suspend and the 
> > application is suspended. A network packet is received, causing the 
> > network driver to take a suspend block. The application finishes the 
> > frame it was drawing, takes its own suspend block and reads the network 
> > packet. In doing so the network driver releases its suspend block, but 
> > since userspace is holding one the phone stays awake. The application 
> > then handles the event as necessary, releases its suspend block and the 
> > phone goes to sleep again.
> > 
> > I don't see how this behaviour can be emulated in your model.
> 
> User puts down phone. 30 seconds later the X server decides to turn the
> screen off and closes the device. This probalby releases the constraint
> held via the display driver not to suspend. Any further draw requests will
> block.
>
> System looks at the other tasks and sees they are idle and can sink to a
> low power state. Cows is either blocked on a packet receive or could even
> be blocked on writing to the display (or both if its a realistic example
> and using poll)

Even if it's using poll, it could block purely on the display if X turns 
the screen off between poll() waking and the write being made.
 
> The kernel looks at the constraints it has
> 	- must not sink to a state below which network receive of packets
> 	  fails
> 	- must not sink below a state where whatever is needed for the
> 	  critical alert code etc to do its stuff
> 	- must not sink to a state which takes more than [constraint]
> 	  seconds to get back out of
> 
> It picks 'opportunistic suspend'
> It goes to sleep
> 
> A packet arrives
> It wakes the hardware
> We are busy, we do not wish to suspend
> It processes the packet
> It wakes the user app
> It starts processing the packet

If it's blocked on the write then it only starts processing the packet 
again if the screen wakes up. You need to power up every piece of 
hardware that an application's blocked on, just in case they need to 
complete that read or write in order to get back to the event loop where 
they have the opportunity to read the network packet.

So, yes, I think this can work in that case. But it doesn't work in 
others - you won't idle applications that aren't accessing hardware 
drivers.

As an aside, I think this is a good idea in any case since a fringe 
benefit is the removal of the requirement to use the process freezer in 
suspend to RAM...

> Stop transitioning Run->Forced Suspend. If you've got stuff stuck running
> then deal with it by constraining it to go idle or by blowing it out of
> the water. PM will then do the rest.

The problem is determining how to constrain it to go idle, where "idle" 
is defined as "Doesn't wake up until a wakeup event is received". It's 
acceptable for something to use as much CPU as it wants when the user is 
actively interacting with the device, but in most cases processes 
shouldn't be permitted to use any CPU when the session is idle. The 
question is how to implement something that allows a CPU-guzzling 
application to be idled without impairing its ability to process wakeup 
events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote:
> > The application is a network monitoring app that renders server state 
> > via animated bouncing cows. The desired behaviour is that the 
> > application will cease to be scheduled if the session becomes idle 
> > (where idle is defined as the system having received no user input for 
> > 30 seconds) but that push notifications from the server still be 
> > received in order to allow the application to present the user with 
> > critical alerts.
> 
> This is a bit confusing - does the screen come back on for such events,
> what constraints is the server operating under ? How does your code look
> - it's hard to imagine the examples you've given as being workable given
> they would block on network packet wait when a critical event occurs.
> Are you using poll or threads or what ?

It's code that's broadly identical to what I posted. The screen will 
come on if the event is critical, won't otherwise.

> > Under Android:
> > 
> > User puts down phone. 30 seconds later the screen turns off and releases 
> > the last user-level suspend block. The phone enters suspend and the 
> > application is suspended. A network packet is received, causing the 
> > network driver to take a suspend block. The application finishes the 
> > frame it was drawing, takes its own suspend block and reads the network 
> > packet. In doing so the network driver releases its suspend block, but 
> > since userspace is holding one the phone stays awake. The application 
> > then handles the event as necessary, releases its suspend block and the 
> > phone goes to sleep again.
> > 
> > I don't see how this behaviour can be emulated in your model.
> 
> User puts down phone. 30 seconds later the X server decides to turn the
> screen off and closes the device. This probalby releases the constraint
> held via the display driver not to suspend. Any further draw requests will
> block.
>
> System looks at the other tasks and sees they are idle and can sink to a
> low power state. Cows is either blocked on a packet receive or could even
> be blocked on writing to the display (or both if its a realistic example
> and using poll)

Even if it's using poll, it could block purely on the display if X turns 
the screen off between poll() waking and the write being made.
 
> The kernel looks at the constraints it has
> 	- must not sink to a state below which network receive of packets
> 	  fails
> 	- must not sink below a state where whatever is needed for the
> 	  critical alert code etc to do its stuff
> 	- must not sink to a state which takes more than [constraint]
> 	  seconds to get back out of
> 
> It picks 'opportunistic suspend'
> It goes to sleep
> 
> A packet arrives
> It wakes the hardware
> We are busy, we do not wish to suspend
> It processes the packet
> It wakes the user app
> It starts processing the packet

If it's blocked on the write then it only starts processing the packet 
again if the screen wakes up. You need to power up every piece of 
hardware that an application's blocked on, just in case they need to 
complete that read or write in order to get back to the event loop where 
they have the opportunity to read the network packet.

So, yes, I think this can work in that case. But it doesn't work in 
others - you won't idle applications that aren't accessing hardware 
drivers.

As an aside, I think this is a good idea in any case since a fringe 
benefit is the removal of the requirement to use the process freezer in 
suspend to RAM...

> Stop transitioning Run->Forced Suspend. If you've got stuff stuck running
> then deal with it by constraining it to go idle or by blowing it out of
> the water. PM will then do the rest.

The problem is determining how to constrain it to go idle, where "idle" 
is defined as "Doesn't wake up until a wakeup event is received". It's 
acceptable for something to use as much CPU as it wants when the user is 
actively interacting with the device, but in most cases processes 
shouldn't be permitted to use any CPU when the session is idle. The 
question is how to implement something that allows a CPU-guzzling 
application to be idled without impairing its ability to process wakeup 
events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Cox wrote:

> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
> 
> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).
> 
> So your position would seem to be "we have a race but can debate how big
> is permissible"
> 
> The usual model is
> 
> "At no point should we be in a position when entering a suspend style
>  deep sleep where we neither abort the suspend, nor commit to a
>  suspend/resume sequence if the events we care about occur"
> 
> and that is why the hardware model is
> 
> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

And if a platform can not guarantee the wakeup or the lossless
transition of states then you can not solve this by throwing blockers
or whatever into the code.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Cox wrote:

> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
> 
> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).
> 
> So your position would seem to be "we have a race but can debate how big
> is permissible"
> 
> The usual model is
> 
> "At no point should we be in a position when entering a suspend style
>  deep sleep where we neither abort the suspend, nor commit to a
>  suspend/resume sequence if the events we care about occur"
> 
> and that is why the hardware model is
> 
> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

And if a platform can not guarantee the wakeup or the lossless
transition of states then you can not solve this by throwing blockers
or whatever into the code.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> No, it's not. Forced suspend may be in response to hitting a key, but it 

You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.

> may also be in response to a 30 minute timeout expiring. If I get a WoL 
> packet in the 0.5 of a second between userspace deciding to suspend and 
> actually doing so, the system shouldn't suspend.

I don't think that argument holds water in the form you have it

What about 5 nanoseconds before you suspend. Now you can't do that (laws
of physics and stuff).

So your position would seem to be "we have a race but can debate how big
is permissible"

The usual model is

"At no point should we be in a position when entering a suspend style
 deep sleep where we neither abort the suspend, nor commit to a
 suspend/resume sequence if the events we care about occur"

and that is why the hardware model is

	Set wake flags
	Check if idle
	If idle
		Suspend
	else
		Clear wake flags
		Unwind

and the wake flags guarantee that an event at any point after the wake
flags are set until they are cleared will cause a suspend to be resumed,
possibly immediately after the suspend.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> No, it's not. Forced suspend may be in response to hitting a key, but it 

You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.

> may also be in response to a 30 minute timeout expiring. If I get a WoL 
> packet in the 0.5 of a second between userspace deciding to suspend and 
> actually doing so, the system shouldn't suspend.

I don't think that argument holds water in the form you have it

What about 5 nanoseconds before you suspend. Now you can't do that (laws
of physics and stuff).

So your position would seem to be "we have a race but can debate how big
is permissible"

The usual model is

"At no point should we be in a position when entering a suspend style
 deep sleep where we neither abort the suspend, nor commit to a
 suspend/resume sequence if the events we care about occur"

and that is why the hardware model is

	Set wake flags
	Check if idle
	If idle
		Suspend
	else
		Clear wake flags
		Unwind

and the wake flags guarantee that an event at any point after the wake
flags are set until they are cleared will cause a suspend to be resumed,
possibly immediately after the suspend.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers. 
> That's entirely orthogonal to Android's runtime power management.

Rather than continue going around in circles, let's agree that what the 
Android people want is a new version of forced suspend -- not a 
power-saving idle mode.  As such, latency is simply not relevant.

Here's an idea for a new approach that avoids the need for in-kernel 
suspend blockers.  I don't know exactly how or if it can be made to 
work, but at least it's a different way of looking at the problem.

A normal forced suspend is unconditional: It stops the system no matter 
what is happening.  The Android people want to make it conditional: 
Don't stop the system until nothing "important" is happening.

So what is "important"?  A possible definition could go like this.  
Let's add a per-process (or per-thread) flag to mark "important" 
processes.  And let's say that a process with this flag set is doing 
"important" work unless it is blocked inside a poll() system call.

Given that definition, an opportunistic suspend is a forced suspend 
that waits until no important processes are doing important work (i.e., 
all important processes are stuck inside poll).

Is this adequate to meet Android's needs?  I don't know.  It can handle 
the case of a program waiting for a keystroke or network packet to 
arrive.

Does it allow for sufficient accounting statistics and debugging 
capability?  I don't know -- no doubt this depends on how it is 
implemented.

Can it be made to work?  I don't know -- in fact, I don't even know how
the poll() system call works internally.  Certainly there is one
complication that needs to be handled: While a suspend is underway, the
important processes will be frozen and hence not sitting inside the
poll() call.  If an event occurs that normally would cause the poll to
complete, we would need to make it abort the suspend.  But it's
difficult to detect when this happens.  It may be necessary to _avoid_
freezing the important processes in order for this to work.

The advantages:

	No more suspend blockers cluttering up random drivers all over
	the kernel.  All the work is centralized in the poll()  
	routines and the PM core.

	It is driven by userspace policy (which processes to mark as
	"important") rather than kernel choice.

Is this doable?  Is it worth doing?  Is it better than using suspend 
blockers?

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers. 
> That's entirely orthogonal to Android's runtime power management.

Rather than continue going around in circles, let's agree that what the 
Android people want is a new version of forced suspend -- not a 
power-saving idle mode.  As such, latency is simply not relevant.

Here's an idea for a new approach that avoids the need for in-kernel 
suspend blockers.  I don't know exactly how or if it can be made to 
work, but at least it's a different way of looking at the problem.

A normal forced suspend is unconditional: It stops the system no matter 
what is happening.  The Android people want to make it conditional: 
Don't stop the system until nothing "important" is happening.

So what is "important"?  A possible definition could go like this.  
Let's add a per-process (or per-thread) flag to mark "important" 
processes.  And let's say that a process with this flag set is doing 
"important" work unless it is blocked inside a poll() system call.

Given that definition, an opportunistic suspend is a forced suspend 
that waits until no important processes are doing important work (i.e., 
all important processes are stuck inside poll).

Is this adequate to meet Android's needs?  I don't know.  It can handle 
the case of a program waiting for a keystroke or network packet to 
arrive.

Does it allow for sufficient accounting statistics and debugging 
capability?  I don't know -- no doubt this depends on how it is 
implemented.

Can it be made to work?  I don't know -- in fact, I don't even know how
the poll() system call works internally.  Certainly there is one
complication that needs to be handled: While a suspend is underway, the
important processes will be frozen and hence not sitting inside the
poll() call.  If an event occurs that normally would cause the poll to
complete, we would need to make it abort the suspend.  But it's
difficult to detect when this happens.  It may be necessary to _avoid_
freezing the important processes in order for this to work.

The advantages:

	No more suspend blockers cluttering up random drivers all over
	the kernel.  All the work is centralized in the poll()  
	routines and the PM core.

	It is driven by userspace policy (which processes to mark as
	"important") rather than kernel choice.

Is this doable?  Is it worth doing?  Is it better than using suspend 
blockers?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> 
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
> 
> If you want to support forced suspend for laptops and you want to avoid 
> the risk of losing wakeups then you need in-kernel suspend blockers. 
> That's entirely orthogonal to Android's runtime power management.

Rather than continue going around in circles, let's agree that what the 
Android people want is a new version of forced suspend -- not a 
power-saving idle mode.  As such, latency is simply not relevant.

Here's an idea for a new approach that avoids the need for in-kernel 
suspend blockers.  I don't know exactly how or if it can be made to 
work, but at least it's a different way of looking at the problem.

A normal forced suspend is unconditional: It stops the system no matter 
what is happening.  The Android people want to make it conditional: 
Don't stop the system until nothing "important" is happening.

So what is "important"?  A possible definition could go like this.  
Let's add a per-process (or per-thread) flag to mark "important" 
processes.  And let's say that a process with this flag set is doing 
"important" work unless it is blocked inside a poll() system call.

Given that definition, an opportunistic suspend is a forced suspend 
that waits until no important processes are doing important work (i.e., 
all important processes are stuck inside poll).

Is this adequate to meet Android's needs?  I don't know.  It can handle 
the case of a program waiting for a keystroke or network packet to 
arrive.

Does it allow for sufficient accounting statistics and debugging 
capability?  I don't know -- no doubt this depends on how it is 
implemented.

Can it be made to work?  I don't know -- in fact, I don't even know how
the poll() system call works internally.  Certainly there is one
complication that needs to be handled: While a suspend is underway, the
important processes will be frozen and hence not sitting inside the
poll() call.  If an event occurs that normally would cause the poll to
complete, we would need to make it abort the suspend.  But it's
difficult to detect when this happens.  It may be necessary to _avoid_
freezing the important processes in order for this to work.

The advantages:

	No more suspend blockers cluttering up random drivers all over
	the kernel.  All the work is centralized in the poll()  
	routines and the PM core.

	It is driven by userspace policy (which processes to mark as
	"important") rather than kernel choice.

Is this doable?  Is it worth doing?  Is it better than using suspend 
blockers?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 19:17:58 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > > > 
> > > > > If that's what you're aiming for then you don't need to block 
> > > > > applications on hardware access because they should all already have 
> > > > > idled themselves.
> > > > 
> > > > Correct, a well behaved app would have. I thought we all agreed that
> > > > well behaved apps weren't the problem?
> > > 
> > > Ok. So the existing badly-behaved application ignores your request and 
> > > then gets blocked. And now it no longer responds to wakeup events. 
> > 
> > It will, when it gets unblocked from whatever thing it got stuck on.
> 
> It's blocked on the screen being turned off. It's supposed to be reading 
> a network packet. How does it ever get to reading the network packet?

Thats a stupid argument. If you write broken code then it doesn't work.
You know if I do

	ls < unopenedfifo

it blocks too.

There is a difference between dealing with apps that overconsume
resources and arbitarily broken code (which your suspend blocker case
doesn't fix either but makes worse).

Can we stick to sane stuff ?

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 19:17:58 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > > > 
> > > > > If that's what you're aiming for then you don't need to block 
> > > > > applications on hardware access because they should all already have 
> > > > > idled themselves.
> > > > 
> > > > Correct, a well behaved app would have. I thought we all agreed that
> > > > well behaved apps weren't the problem?
> > > 
> > > Ok. So the existing badly-behaved application ignores your request and 
> > > then gets blocked. And now it no longer responds to wakeup events. 
> > 
> > It will, when it gets unblocked from whatever thing it got stuck on.
> 
> It's blocked on the screen being turned off. It's supposed to be reading 
> a network packet. How does it ever get to reading the network packet?

Thats a stupid argument. If you write broken code then it doesn't work.
You know if I do

	ls < unopenedfifo

it blocks too.

There is a difference between dealing with apps that overconsume
resources and arbitarily broken code (which your suspend blocker case
doesn't fix either but makes worse).

Can we stick to sane stuff ?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > We were talking about PCs. Suspend-as-c-state is already implemented for 
> > OMAP.
>  
> Ah, now we talk about PCs. And all of a sudden the problem of the
> unability of determining wakeup sources is not longer relevant ? So
> how do you guarantee that we don't miss one if we cant figure out
> which ones are kept alive in S3 ?

A wakeup event is defined as one that wakes the system - if a system 
can't be woken by a specific event then it's impossible to lose it, 
since it wasn't a wakeup event to begin with.

> > > So the only thing you are imposing to app writers is to use an
> > > interface which solves nothing and does not save you any power at
> > > all. 
> > 
> > It's already been demonstrated that the Android approach saves power.
> 
> Demonstrated ? Care to explain me how it makes a difference:
> 
> while (1) {
>   block();
>   read();
>   process_event();
>   unblock();
> 		---> suspend
> 		<--- resume
>   do_crap();	1000000 cycles
> }
> 
> vs.
> 
> while (1) {
>   read();
> 		---> suspend
> 		<--- resume
>   process_event();
>   do_crap();	1000000 cycles
> }
> 
> You spend the damned 10000000 cycles in any case just at a different
> point in time. So if you are so convinced and have fully understood
> all the implications, please enlighten me why do_crap() costs less
> power with the blockers approach.

Consider the case where the read() is non-blocking.

> 1) The kernel blocker does not guarantee that the lousy app has
>    processed the event. It just guarantees that the lousy app has
>    emptied the input queue. So what's the point of the kernel blocker
>    in that case ?

Yes, I think you're right here. You need the userspace component as well 
for this to work correctly.

> 2) What's the difference on setting that app to QoS(NONE) and let the
>    kernel happily ignore it.

What sets that flag, and how does it interact with an application that 
never makes a blocking system call?

> Come up with real explanations and numbers and not just the "it has
> been demonstrated" chant which is not holding water if you look at the
> above.

The numbers were earlier in the thread.

> The kernel history is full of examples where crappy solutions got
> rejected and kept out of the kernel for a long time even if there was
> a need for them in the application field and they got shipped in
> quantities with out of tree patches (NOHZ, high resolution timers,
> ...). At some point people stopped arguing for crappy solutions and
> sat down and got it right. The problem of power management and
> opportunistic suspend is not different in any way.

Yes, and I'd agree with this if anyone seemed to have any idea how to do 
it right. But despite all the heat and noise in this thread, all we've 
got is an expression that it should be handled by the scheduler (a 
viewpoint I agree with) without any explanation of how to switch 
policies in such a way that applications idle without losing wakeup 
events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > We were talking about PCs. Suspend-as-c-state is already implemented for 
> > OMAP.
>  
> Ah, now we talk about PCs. And all of a sudden the problem of the
> unability of determining wakeup sources is not longer relevant ? So
> how do you guarantee that we don't miss one if we cant figure out
> which ones are kept alive in S3 ?

A wakeup event is defined as one that wakes the system - if a system 
can't be woken by a specific event then it's impossible to lose it, 
since it wasn't a wakeup event to begin with.

> > > So the only thing you are imposing to app writers is to use an
> > > interface which solves nothing and does not save you any power at
> > > all. 
> > 
> > It's already been demonstrated that the Android approach saves power.
> 
> Demonstrated ? Care to explain me how it makes a difference:
> 
> while (1) {
>   block();
>   read();
>   process_event();
>   unblock();
> 		---> suspend
> 		<--- resume
>   do_crap();	1000000 cycles
> }
> 
> vs.
> 
> while (1) {
>   read();
> 		---> suspend
> 		<--- resume
>   process_event();
>   do_crap();	1000000 cycles
> }
> 
> You spend the damned 10000000 cycles in any case just at a different
> point in time. So if you are so convinced and have fully understood
> all the implications, please enlighten me why do_crap() costs less
> power with the blockers approach.

Consider the case where the read() is non-blocking.

> 1) The kernel blocker does not guarantee that the lousy app has
>    processed the event. It just guarantees that the lousy app has
>    emptied the input queue. So what's the point of the kernel blocker
>    in that case ?

Yes, I think you're right here. You need the userspace component as well 
for this to work correctly.

> 2) What's the difference on setting that app to QoS(NONE) and let the
>    kernel happily ignore it.

What sets that flag, and how does it interact with an application that 
never makes a blocking system call?

> Come up with real explanations and numbers and not just the "it has
> been demonstrated" chant which is not holding water if you look at the
> above.

The numbers were earlier in the thread.

> The kernel history is full of examples where crappy solutions got
> rejected and kept out of the kernel for a long time even if there was
> a need for them in the application field and they got shipped in
> quantities with out of tree patches (NOHZ, high resolution timers,
> ...). At some point people stopped arguing for crappy solutions and
> sat down and got it right. The problem of power management and
> opportunistic suspend is not different in any way.

Yes, and I'd agree with this if anyone seemed to have any idea how to do 
it right. But despite all the heat and noise in this thread, all we've 
got is an expression that it should be handled by the scheduler (a 
viewpoint I agree with) without any explanation of how to switch 
policies in such a way that applications idle without losing wakeup 
events.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > If one works so does the other.
> 
> Not at all. The entire point of opportunistic suspend is that I don't 
> care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> in 100msec - based on policy (through not having any held suspend 
> blockers), I'll go to sleep. That's easily possible on PCs.

Yes I appreciate what suspend blockers are trying to do. Now how does
that connect with my first sentence ?

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > If one works so does the other.
> 
> Not at all. The entire point of opportunistic suspend is that I don't 
> care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> in 100msec - based on policy (through not having any held suspend 
> blockers), I'll go to sleep. That's easily possible on PCs.

Yes I appreciate what suspend blockers are trying to do. Now how does
that connect with my first sentence ?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:03:13PM +0100, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.

Sigh. No. Forced suspend is a fact of life, and suspend blockers improve 
the ability to support it. It's orthogonal to more general runtime PM.

> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).

Drivers should enable wakeups before they disable interrupts. So either 
the packet hits the IRQ handler and the driver takes a suspend block 
(aborting suspend in the process) or it doesn't, the GPE goes high and 
the system resumes immediately after entering S3.

> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

Exactly. So the 5 nanosecond case is already handled. The interesting 
case is where userspace makes the decision to go to sleep and starts 
performing various housekeeping tasks before triggering the suspend. You 
need some way to abort that suspend. The hardware may be long idle by 
then, so you can't just look at the hardware state.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:03:13PM +0100, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.

Sigh. No. Forced suspend is a fact of life, and suspend blockers improve 
the ability to support it. It's orthogonal to more general runtime PM.

> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).

Drivers should enable wakeups before they disable interrupts. So either 
the packet hits the IRQ handler and the driver takes a suspend block 
(aborting suspend in the process) or it doesn't, the GPE goes high and 
the system resumes immediately after entering S3.

> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

Exactly. So the 5 nanosecond case is already handled. The interesting 
case is where userspace makes the decision to go to sleep and starts 
performing various housekeeping tasks before triggering the suspend. You 
need some way to abort that suspend. The hardware may be long idle by 
then, so you can't just look at the hardware state.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> I still don't see how blocking applications will cause missed wakeups in
> anything but a buggy application at worst, and even those will
> eventually get the event when they unblock.
> 
> What seems to be the confusion?

During forced suspend, applications are block because they are frozen.

When an event occurs, the application is notified somehow.  But it 
can't respond because it is frozen.  Hence the event remains sitting in 
a kernel queue and the system goes ahead and suspends anyway.  The 
application doesn't get thawed until the system wakes up at some 
indefinite time in the future.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> I still don't see how blocking applications will cause missed wakeups in
> anything but a buggy application at worst, and even those will
> eventually get the event when they unblock.
> 
> What seems to be the confusion?

During forced suspend, applications are block because they are frozen.

When an event occurs, the application is notified somehow.  But it 
can't respond because it is frozen.  Hence the event remains sitting in 
a kernel queue and the system goes ahead and suspends anyway.  The 
application doesn't get thawed until the system wakes up at some 
indefinite time in the future.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> I still don't see how blocking applications will cause missed wakeups in
> anything but a buggy application at worst, and even those will
> eventually get the event when they unblock.
> 
> What seems to be the confusion?

During forced suspend, applications are block because they are frozen.

When an event occurs, the application is notified somehow.  But it 
can't respond because it is frozen.  Hence the event remains sitting in 
a kernel queue and the system goes ahead and suspends anyway.  The 
application doesn't get thawed until the system wakes up at some 
indefinite time in the future.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > > 
> > > _WHY_!?
> > 
> > Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> > key, I need to go to sleep. Blocking processes on driver access isn't 
> > sufficient.
> 
> But that's a whole different issue. I agree that a forced suspend for
> things like that make sense, just not for power managing a running
> system.

Why not?  Or rather, why shouldn't it?

> PC style hardware like that doesn't wake up from suspend for
> funny things like a keypress either (good thing too).

Yes it does.  If I close the lid of my laptop, wait a few seconds for 
it to suspend, then open the lid (which does not wake it up), and hit a 
key -- it wakes up.

> Anyway all that already works (more or less), so I don't see the
> problem.

The "less" part is the problem.  It would be nice to have a forced 
suspend mode that is more dicriminating: Instead of activating 
immediately it would wait until all pending events were handled.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > > 
> > > _WHY_!?
> > 
> > Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> > key, I need to go to sleep. Blocking processes on driver access isn't 
> > sufficient.
> 
> But that's a whole different issue. I agree that a forced suspend for
> things like that make sense, just not for power managing a running
> system.

Why not?  Or rather, why shouldn't it?

> PC style hardware like that doesn't wake up from suspend for
> funny things like a keypress either (good thing too).

Yes it does.  If I close the lid of my laptop, wait a few seconds for 
it to suspend, then open the lid (which does not wake it up), and hit a 
key -- it wakes up.

> Anyway all that already works (more or less), so I don't see the
> problem.

The "less" part is the problem.  It would be nice to have a forced 
suspend mode that is more dicriminating: Instead of activating 
immediately it would wait until all pending events were handled.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > > 
> > > _WHY_!?
> > 
> > Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> > key, I need to go to sleep. Blocking processes on driver access isn't 
> > sufficient.
> 
> But that's a whole different issue. I agree that a forced suspend for
> things like that make sense, just not for power managing a running
> system.

Why not?  Or rather, why shouldn't it?

> PC style hardware like that doesn't wake up from suspend for
> funny things like a keypress either (good thing too).

Yes it does.  If I close the lid of my laptop, wait a few seconds for 
it to suspend, then open the lid (which does not wake it up), and hit a 
key -- it wakes up.

> Anyway all that already works (more or less), so I don't see the
> problem.

The "less" part is the problem.  It would be nice to have a forced 
suspend mode that is more dicriminating: Instead of activating 
immediately it would wait until all pending events were handled.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The problem is determining how to constrain it to go idle, where "idle" 
> is defined as "Doesn't wake up until a wakeup event is received". It's 
> acceptable for something to use as much CPU as it wants when the user is 
> actively interacting with the device, but in most cases processes 
> shouldn't be permitted to use any CPU when the session is idle. The 
> question is how to implement something that allows a CPU-guzzling 
> application to be idled without impairing its ability to process wakeup 
> events.

>From your literal description:

setpriority. signal, process groups.

	kill(-desktopgroup, SIGSTOP);
	kill(-desktopgroup, SIGCONT);
	kill(pid_i_am_crit_eventing, SIGCONT);

or SIGTSTP might be friendlier as a well behaved smart app can catch it,
fire it into the event loop and elegantly save and sleep.

Some window managers played with doing setpriority for focussed windows.
OLPC the same thing for OOM targets via /proc/oom_adj

The scheduler can happily do this, the power management will also
recognize STOPPED processes as no impediment to suspend.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The problem is determining how to constrain it to go idle, where "idle" 
> is defined as "Doesn't wake up until a wakeup event is received". It's 
> acceptable for something to use as much CPU as it wants when the user is 
> actively interacting with the device, but in most cases processes 
> shouldn't be permitted to use any CPU when the session is idle. The 
> question is how to implement something that allows a CPU-guzzling 
> application to be idled without impairing its ability to process wakeup 
> events.

>From your literal description:

setpriority. signal, process groups.

	kill(-desktopgroup, SIGSTOP);
	kill(-desktopgroup, SIGCONT);
	kill(pid_i_am_crit_eventing, SIGCONT);

or SIGTSTP might be friendlier as a well behaved smart app can catch it,
fire it into the event loop and elegantly save and sleep.

Some window managers played with doing setpriority for focussed windows.
OLPC the same thing for OOM targets via /proc/oom_adj

The scheduler can happily do this, the power management will also
recognize STOPPED processes as no impediment to suspend.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Rather than continue going around in circles, let's agree that what the 
> Android people want is a new version of forced suspend -- not a 

I don't think this is true. I think that is the root of the problem.

I don't disagree with the user experience they are trying to create or
the fact something is needed to make it possible (if it turns out we
can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are
'when nothing is running' into suspend.

So for me the real question on that side of this specific case is 'how
do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Rather than continue going around in circles, let's agree that what the 
> Android people want is a new version of forced suspend -- not a 

I don't think this is true. I think that is the root of the problem.

I don't disagree with the user experience they are trying to create or
the fact something is needed to make it possible (if it turns out we
can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are
'when nothing is running' into suspend.

So for me the real question on that side of this specific case is 'how
do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Rather than continue going around in circles, let's agree that what the 
> Android people want is a new version of forced suspend -- not a 

I don't think this is true. I think that is the root of the problem.

I don't disagree with the user experience they are trying to create or
the fact something is needed to make it possible (if it turns out we
can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are
'when nothing is running' into suspend.

So for me the real question on that side of this specific case is 'how
do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:

> The scheduler can happily do this, the power management will also
> recognize STOPPED processes as no impediment to suspend.

But wakeup events won't be delivered to STOPped processes, and there's 
also the race of an application being in the middle of handling a wakeup 
event when you send it the signal.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:

> The scheduler can happily do this, the power management will also
> recognize STOPPED processes as no impediment to suspend.

But wakeup events won't be delivered to STOPped processes, and there's 
also the race of an application being in the middle of handling a wakeup 
event when you send it the signal.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote:
> Even if it's using poll, it could block purely on the display if X turns 
> the screen off between poll() waking and the write being made.

That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for.

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote:
> Even if it's using poll, it could block purely on the display if X turns 
> the screen off between poll() waking and the write being made.

That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > Rather than continue going around in circles, let's agree that what the 
> > Android people want is a new version of forced suspend -- not a 
> 
> I don't think this is true. I think that is the root of the problem.

Of course it's true.  Just ask Arve -- he wants opportunistic suspend 
and it _is_ a variant of forced suspend.  Ergo he wants a new type of 
forced suspend.

Maybe that's not what he _ought_ to want.  Nevertheless, there are 
valid reasons for wanting it.

> I don't disagree with the user experience they are trying to create or
> the fact something is needed to make it possible (if it turns out we
> can't already do it).
> 
> Forced suspend is sticking stuff in running state into suspend
> 
> Power management models (such as Thomas ARM box) which we know work are
> 'when nothing is running' into suspend.
> 
> So for me the real question on that side of this specific case is 'how
> do you make sure those tasks are idle when you need them to be'
> 
> QoS ?
> Spanking them from user space ?
> Drivers enforcing policy elements by blocking tasks ?

Currently we use the freezer.  But it is a blunt tool -- it freezes 
every user process.  Also, it doesn't actually make processes 
unrunnable; it just arranges things so that when they do run, they 
immediately put themselves back to sleep.

And the forced-suspend design relies on the fact that processes remain 
frozen throughout.  If we leave some processes unfrozen and one of them 
somehow becomes runnable, that means we have to abort the forced 
suspend before the process is allowed to run.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > Rather than continue going around in circles, let's agree that what the 
> > Android people want is a new version of forced suspend -- not a 
> 
> I don't think this is true. I think that is the root of the problem.

Of course it's true.  Just ask Arve -- he wants opportunistic suspend 
and it _is_ a variant of forced suspend.  Ergo he wants a new type of 
forced suspend.

Maybe that's not what he _ought_ to want.  Nevertheless, there are 
valid reasons for wanting it.

> I don't disagree with the user experience they are trying to create or
> the fact something is needed to make it possible (if it turns out we
> can't already do it).
> 
> Forced suspend is sticking stuff in running state into suspend
> 
> Power management models (such as Thomas ARM box) which we know work are
> 'when nothing is running' into suspend.
> 
> So for me the real question on that side of this specific case is 'how
> do you make sure those tasks are idle when you need them to be'
> 
> QoS ?
> Spanking them from user space ?
> Drivers enforcing policy elements by blocking tasks ?

Currently we use the freezer.  But it is a blunt tool -- it freezes 
every user process.  Also, it doesn't actually make processes 
unrunnable; it just arranges things so that when they do run, they 
immediately put themselves back to sleep.

And the forced-suspend design relies on the fact that processes remain 
frozen throughout.  If we leave some processes unfrozen and one of them 
somehow becomes runnable, that means we have to abort the forced 
suspend before the process is allowed to run.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > Rather than continue going around in circles, let's agree that what the 
> > Android people want is a new version of forced suspend -- not a 
> 
> I don't think this is true. I think that is the root of the problem.

Of course it's true.  Just ask Arve -- he wants opportunistic suspend 
and it _is_ a variant of forced suspend.  Ergo he wants a new type of 
forced suspend.

Maybe that's not what he _ought_ to want.  Nevertheless, there are 
valid reasons for wanting it.

> I don't disagree with the user experience they are trying to create or
> the fact something is needed to make it possible (if it turns out we
> can't already do it).
> 
> Forced suspend is sticking stuff in running state into suspend
> 
> Power management models (such as Thomas ARM box) which we know work are
> 'when nothing is running' into suspend.
> 
> So for me the real question on that side of this specific case is 'how
> do you make sure those tasks are idle when you need them to be'
> 
> QoS ?
> Spanking them from user space ?
> Drivers enforcing policy elements by blocking tasks ?

Currently we use the freezer.  But it is a blunt tool -- it freezes 
every user process.  Also, it doesn't actually make processes 
unrunnable; it just arranges things so that when they do run, they 
immediately put themselves back to sleep.

And the forced-suspend design relies on the fact that processes remain 
frozen throughout.  If we leave some processes unfrozen and one of them 
somehow becomes runnable, that means we have to abort the forced 
suspend before the process is allowed to run.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Sigh. No. Forced suspend is a fact of life

'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.

> Drivers should enable wakeups before they disable interrupts. So either 
> the packet hits the IRQ handler and the driver takes a suspend block 
> (aborting suspend in the process) or it doesn't, the GPE goes high and 
> the system resumes immediately after entering S3.
> 
> > 	Set wake flags
> > 	Check if idle
> > 	If idle
> > 		Suspend
> > 	else
> > 		Clear wake flags
> > 		Unwind
> > 
> > and the wake flags guarantee that an event at any point after the wake
> > flags are set until they are cleared will cause a suspend to be resumed,
> > possibly immediately after the suspend.
> 
> Exactly. So the 5 nanosecond case is already handled. The interesting 
> case is where userspace makes the decision to go to sleep and starts 
> performing various housekeeping tasks before triggering the suspend. You 
> need some way to abort that suspend. 

See above. You can't always abort the suspend you may have to go full
circle. Not only that but the exactly algorithm above can be applied
user to kernel as well as kernel to hardware.

Given your average app author I think I'd rather just run their suspend
then their resume handling back to back anyway because it's a single
tested code path, while half way through cases in apps will *never* get
tested or work properly.

So I guess if you are driving this rom user space (which I take it you
are given you talk about housekeeping)

	foreach app we need to suspend
		kick app to suspend (signal)
		(policy) kick harder if needed (SIGSTOP/bitch/shall I
					kill it dialogue)
	rendezvous (apps now all sleeping or dead)

X
	if (we still want to suspend) {
		prod kernel
		kernel suspends
		kernel resumes
	}
	resume all the apps


The important msising bit from that is 'set wake flags'.

Now what actually happens here beyond point X. Any event that gets kernel
processed moves the task into RUNNING. Any event that occurs after that
point causes the hardware to go suspend/resume. If not the driver is
buggy.

Now replace "kernel suspends" with "let the kernel know it can drop into
suspend level idle". The power management code will handle the races
beyond point X for you.

So for that you simply need a constraint to remain above suspend level
idle that you drop where it says "prod kernel" and pick up on "resume"

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Sigh. No. Forced suspend is a fact of life

'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.

> Drivers should enable wakeups before they disable interrupts. So either 
> the packet hits the IRQ handler and the driver takes a suspend block 
> (aborting suspend in the process) or it doesn't, the GPE goes high and 
> the system resumes immediately after entering S3.
> 
> > 	Set wake flags
> > 	Check if idle
> > 	If idle
> > 		Suspend
> > 	else
> > 		Clear wake flags
> > 		Unwind
> > 
> > and the wake flags guarantee that an event at any point after the wake
> > flags are set until they are cleared will cause a suspend to be resumed,
> > possibly immediately after the suspend.
> 
> Exactly. So the 5 nanosecond case is already handled. The interesting 
> case is where userspace makes the decision to go to sleep and starts 
> performing various housekeeping tasks before triggering the suspend. You 
> need some way to abort that suspend. 

See above. You can't always abort the suspend you may have to go full
circle. Not only that but the exactly algorithm above can be applied
user to kernel as well as kernel to hardware.

Given your average app author I think I'd rather just run their suspend
then their resume handling back to back anyway because it's a single
tested code path, while half way through cases in apps will *never* get
tested or work properly.

So I guess if you are driving this rom user space (which I take it you
are given you talk about housekeeping)

	foreach app we need to suspend
		kick app to suspend (signal)
		(policy) kick harder if needed (SIGSTOP/bitch/shall I
					kill it dialogue)
	rendezvous (apps now all sleeping or dead)

X
	if (we still want to suspend) {
		prod kernel
		kernel suspends
		kernel resumes
	}
	resume all the apps


The important msising bit from that is 'set wake flags'.

Now what actually happens here beyond point X. Any event that gets kernel
processed moves the task into RUNNING. Any event that occurs after that
point causes the hardware to go suspend/resume. If not the driver is
buggy.

Now replace "kernel suspends" with "let the kernel know it can drop into
suspend level idle". The power management code will handle the races
beyond point X for you.

So for that you simply need a constraint to remain above suspend level
idle that you drop where it says "prod kernel" and pick up on "resume"

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
> 
> > The scheduler can happily do this, the power management will also
> > recognize STOPPED processes as no impediment to suspend.
> 
> But wakeup events won't be delivered to STOPped processes, and there's 

Try the following

	cat <pipe
	kill -STOP catpid

	echo "wombats are cool" > pipe
	kill -CONT catpid

it will echo "wombats are cool"

The event was not lost.

> also the race of an application being in the middle of handling a wakeup 
> event when you send it the signal.

sigmask()

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
> 
> > The scheduler can happily do this, the power management will also
> > recognize STOPPED processes as no impediment to suspend.
> 
> But wakeup events won't be delivered to STOPped processes, and there's 

Try the following

	cat <pipe
	kill -STOP catpid

	echo "wombats are cool" > pipe
	kill -CONT catpid

it will echo "wombats are cool"

The event was not lost.

> also the race of an application being in the middle of handling a wakeup 
> event when you send it the signal.

sigmask()

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 19:23:03 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Actually, the reverse - there's no terribly good way to make PCs work 
> > > with scheduler-based suspend, but there's no reason why they wouldn't 
> > > work with the current opportunistic suspend implementation.
> > 
> > How does that solve the problems you mentioned above ? Wakeup
> > guarantees, latencies ...
> 
> Latency doesn't matter because we don't care when the next timer is due 
> to expire.

In your specific current implementation. It matters a hell of a lot in
most cases.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 19:23:03 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Actually, the reverse - there's no terribly good way to make PCs work 
> > > with scheduler-based suspend, but there's no reason why they wouldn't 
> > > work with the current opportunistic suspend implementation.
> > 
> > How does that solve the problems you mentioned above ? Wakeup
> > guarantees, latencies ...
> 
> Latency doesn't matter because we don't care when the next timer is due 
> to expire.

In your specific current implementation. It matters a hell of a lot in
most cases.

Alan

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Thursday 27 May 2010, Dmitry Torokhov wrote:
> On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> > 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> > > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> > >
> > >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> > >> > opportunistic suspend, and a wakeup event occurs but no suspend
> > >> > blockers get enabled by the handler, what causes the system to go back
> > >> > into suspend after the event is handled?  Isn't that a loop of some
> > >> > sort?
> > >> >
> > >>
> > >> Yes it is a loop. I think what you are missing is that it only loops
> > >> repeatedly if the driver that aborts suspend does not use a suspend
> > >> blocker.
> > >
> > > You mean "the driver that handles the wakeup event".  I was asking what
> > > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> > > a suspend blocker is used then its release causes another suspend
> > > attempt, with no looping.
> > >
> > >> > And even if it isn't, so what?  What's wrong with looping behavior?
> > >>
> > >> It is a significant power drain.
> > >
> > > Not in the situation I was discussing.
> > >
> > 
> > If you meant it spend most of the time suspended, then I agree. It
> > only wastes power when a driver blocks suspend by returning an error
> > from its suspend hook and we are forced to loop doing no useful work.
> > 
> 
> If driver refuses to suspend that means there are events that need
> processing. I fail to see why it would be called "looping doing no
> useful work".

I guess Arve meant the case of events that didn't propagate to user space.

Rafael


> 
> 

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Rafael J. Wysocki]

On Thursday 27 May 2010, Dmitry Torokhov wrote:
> On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> > 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> > > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> > >
> > >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> > >> > opportunistic suspend, and a wakeup event occurs but no suspend
> > >> > blockers get enabled by the handler, what causes the system to go back
> > >> > into suspend after the event is handled?  Isn't that a loop of some
> > >> > sort?
> > >> >
> > >>
> > >> Yes it is a loop. I think what you are missing is that it only loops
> > >> repeatedly if the driver that aborts suspend does not use a suspend
> > >> blocker.
> > >
> > > You mean "the driver that handles the wakeup event".  I was asking what
> > > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> > > a suspend blocker is used then its release causes another suspend
> > > attempt, with no looping.
> > >
> > >> > And even if it isn't, so what?  What's wrong with looping behavior?
> > >>
> > >> It is a significant power drain.
> > >
> > > Not in the situation I was discussing.
> > >
> > 
> > If you meant it spend most of the time suspended, then I agree. It
> > only wastes power when a driver blocks suspend by returning an error
> > from its suspend hook and we are forced to loop doing no useful work.
> > 
> 
> If driver refuses to suspend that means there are events that need
> processing. I fail to see why it would be called "looping doing no
> useful work".

I guess Arve meant the case of events that didn't propagate to user space.

Rafael


> 
> 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote:

> So I guess if you are driving this rom user space (which I take it you
> are given you talk about housekeeping)
> 
> 	foreach app we need to suspend
> 		kick app to suspend (signal)
> 		(policy) kick harder if needed (SIGSTOP/bitch/shall I
> 					kill it dialogue)

This would need to be atomic, but in any case:

1) Policy decision is made
2) Wakeup event is received by task
3) Task gets stopped between receiving the event and handing it off to 
policy agent

At which point you suspend when you should have remained awake.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote:

> So I guess if you are driving this rom user space (which I take it you
> are given you talk about housekeeping)
> 
> 	foreach app we need to suspend
> 		kick app to suspend (signal)
> 		(policy) kick harder if needed (SIGSTOP/bitch/shall I
> 					kill it dialogue)

This would need to be atomic, but in any case:

1) Policy decision is made
2) Wakeup event is received by task
3) Task gets stopped between receiving the event and handing it off to 
policy agent

At which point you suspend when you should have remained awake.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> We were talking about PCs. Suspend-as-c-state is already implemented for 
> OMAP.

"You" were talking about PCs. Some of us are interested in the making
Linux do the right thing not adding platform specific hacks all over the
userspace of all the apps.
 
> > So the only thing you are imposing to app writers is to use an
> > interface which solves nothing and does not save you any power at
> > all. 
> 
> It's already been demonstrated that the Android approach saves power.

So do lots of other things

> > Runnable tasks and QoS guarantees are the indicators whether you can
> > go to opportunistic suspend or not. Everything else is just window
> > dressing.
> 
> As I keep saying, this is all much less interesting if you don't care 
> about handling suboptimal applications. If you do care about them then 

I don't believe the Android one does either. It maybe handles a subset in
a specific case.

> the Android approach works. Nobody has demonstrated a scheduler-based 
> one that does.

I would point you at the web, cgi scripts and the huge Linux server farms
fielding billions of hits per second on crap cgi scripts.

That doesn't mean the Android one is the right approach. Nobody has
explained to me how you don't get synchronization effects in Android or
indeed answered several of the questions pointing out holes in the
Android model. The fact we are at rev 8 says something too - that the
Android 'proof' isn't old or tested either !

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> We were talking about PCs. Suspend-as-c-state is already implemented for 
> OMAP.

"You" were talking about PCs. Some of us are interested in the making
Linux do the right thing not adding platform specific hacks all over the
userspace of all the apps.
 
> > So the only thing you are imposing to app writers is to use an
> > interface which solves nothing and does not save you any power at
> > all. 
> 
> It's already been demonstrated that the Android approach saves power.

So do lots of other things

> > Runnable tasks and QoS guarantees are the indicators whether you can
> > go to opportunistic suspend or not. Everything else is just window
> > dressing.
> 
> As I keep saying, this is all much less interesting if you don't care 
> about handling suboptimal applications. If you do care about them then 

I don't believe the Android one does either. It maybe handles a subset in
a specific case.

> the Android approach works. Nobody has demonstrated a scheduler-based 
> one that does.

I would point you at the web, cgi scripts and the huge Linux server farms
fielding billions of hits per second on crap cgi scripts.

That doesn't mean the Android one is the right approach. Nobody has
explained to me how you don't get synchronization effects in Android or
indeed answered several of the questions pointing out holes in the
Android model. The fact we are at rev 8 says something too - that the
Android 'proof' isn't old or tested either !

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 20:29:26 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > But wakeup events won't be delivered to STOPped processes, and there's 
> 
> Try the following
> 
> 	cat <pipe
> 	kill -STOP catpid
> 
> 	echo "wombats are cool" > pipe
> 	kill -CONT catpid
> 
> it will echo "wombats are cool"
> 
> The event was not lost.

Not lost, but not delivered. So you need your policy agent to send 
SIGCONT when you receive any wakeup event, which either means proxying 
all your network traffic through your policy agent or having some 
mechanism for alerting the policy agent whenever you leave the deep idle 
state.

> > also the race of an application being in the middle of handling a wakeup 
> > event when you send it the signal.
> 
> sigmask()

Doesn't help - I may be hit by the signal between the poll() unblocking 
and me having the opportunity to call sigmask().

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 20:29:26 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > But wakeup events won't be delivered to STOPped processes, and there's 
> 
> Try the following
> 
> 	cat <pipe
> 	kill -STOP catpid
> 
> 	echo "wombats are cool" > pipe
> 	kill -CONT catpid
> 
> it will echo "wombats are cool"
> 
> The event was not lost.

Not lost, but not delivered. So you need your policy agent to send 
SIGCONT when you receive any wakeup event, which either means proxying 
all your network traffic through your policy agent or having some 
mechanism for alerting the policy agent whenever you leave the deep idle 
state.

> > also the race of an application being in the middle of handling a wakeup 
> > event when you send it the signal.
> 
> sigmask()

Doesn't help - I may be hit by the signal between the poll() unblocking 
and me having the opportunity to call sigmask().

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > We were talking about PCs. Suspend-as-c-state is already implemented for 
> > > OMAP.
> >  
> > Ah, now we talk about PCs. And all of a sudden the problem of the
> > unability of determining wakeup sources is not longer relevant ? So
> > how do you guarantee that we don't miss one if we cant figure out
> > which ones are kept alive in S3 ?
> 
> A wakeup event is defined as one that wakes the system - if a system 
> can't be woken by a specific event then it's impossible to lose it, 
> since it wasn't a wakeup event to begin with.

So where is the problem ?
 
> > > > So the only thing you are imposing to app writers is to use an
> > > > interface which solves nothing and does not save you any power at
> > > > all. 
> > > 
> > > It's already been demonstrated that the Android approach saves power.
> > 
> > Demonstrated ? Care to explain me how it makes a difference:
> > 
> > while (1) {
> >   block();
> >   read();
> >   process_event();
> >   unblock();
> > 		---> suspend
> > 		<--- resume
> >   do_crap();	1000000 cycles
> > }
> > 
> > vs.
> > 
> > while (1) {
> >   read();
> > 		---> suspend
> > 		<--- resume
> >   process_event();
> >   do_crap();	1000000 cycles
> > }
> > 
> > You spend the damned 10000000 cycles in any case just at a different
> > point in time. So if you are so convinced and have fully understood
> > all the implications, please enlighten me why do_crap() costs less
> > power with the blockers approach.
> 
> Consider the case where the read() is non-blocking.

Which I consider in the same range as the application which does:

      while (1);

> > 1) The kernel blocker does not guarantee that the lousy app has
> >    processed the event. It just guarantees that the lousy app has
> >    emptied the input queue. So what's the point of the kernel blocker
> >    in that case ?
> 
> Yes, I think you're right here. You need the userspace component as well 
> for this to work correctly.
>
> > 2) What's the difference on setting that app to QoS(NONE) and let the
> >    kernel happily ignore it.
> 
> What sets that flag, and how does it interact with an application that 
> never makes a blocking system call?

  QoS(NONE) would be default policy for untrusted apps in the same way
  as you'd refuse the usage of supsend blockers for untrusted apps.
  
  while (1); is definitely not an application which should be granted
  trusted rights, right ?

  block_suspend(); while(1);
  
  is the same as:

  QoS(minimal latency); while(1);

  So if you really go to trust an "while (1);" application you better
  make sure that this app has the appropriate QoS(NONE) or QoS(10s)
  call in it before letting it lose.
 
> > Come up with real explanations and numbers and not just the "it has
> > been demonstrated" chant which is not holding water if you look at the
> > above.
> 
> The numbers were earlier in the thread.

  Numbers, yes. But I really give a sh*t about numbers w/o a detailed
  explanation of the scenario which created those numbers. And if the
  numbers boil down to: we handle the untrusted app which does "while
  (1);" then they are absolutely useless.

> > The kernel history is full of examples where crappy solutions got
> > rejected and kept out of the kernel for a long time even if there was
> > a need for them in the application field and they got shipped in
> > quantities with out of tree patches (NOHZ, high resolution timers,
> > ...). At some point people stopped arguing for crappy solutions and
> > sat down and got it right. The problem of power management and
> > opportunistic suspend is not different in any way.
> 
> Yes, and I'd agree with this if anyone seemed to have any idea how to do 
> it right. But despite all the heat and noise in this thread, all we've 
> got is an expression that it should be handled by the scheduler (a 
> viewpoint I agree with) without any explanation of how to switch 
> policies in such a way that applications idle without losing wakeup 
> events.

Why in the world should they lose wakeup events ? If an app goes idle,
it goes idle because it is waiting for an event. There is no other
sane reason except for those apps which are untrusted and force
idled. And for those you agreed already the suspend blockers don't
solve anything as they are either not implemented or the app is not
trusted to use them.

So we are back to round one of the whole discussion:

   Is it worth to create an utter mess in the kernel just to handle a
   subset of crappy coded applications ?

And the answer stays the same: No, not at all.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > We were talking about PCs. Suspend-as-c-state is already implemented for 
> > > OMAP.
> >  
> > Ah, now we talk about PCs. And all of a sudden the problem of the
> > unability of determining wakeup sources is not longer relevant ? So
> > how do you guarantee that we don't miss one if we cant figure out
> > which ones are kept alive in S3 ?
> 
> A wakeup event is defined as one that wakes the system - if a system 
> can't be woken by a specific event then it's impossible to lose it, 
> since it wasn't a wakeup event to begin with.

So where is the problem ?
 
> > > > So the only thing you are imposing to app writers is to use an
> > > > interface which solves nothing and does not save you any power at
> > > > all. 
> > > 
> > > It's already been demonstrated that the Android approach saves power.
> > 
> > Demonstrated ? Care to explain me how it makes a difference:
> > 
> > while (1) {
> >   block();
> >   read();
> >   process_event();
> >   unblock();
> > 		---> suspend
> > 		<--- resume
> >   do_crap();	1000000 cycles
> > }
> > 
> > vs.
> > 
> > while (1) {
> >   read();
> > 		---> suspend
> > 		<--- resume
> >   process_event();
> >   do_crap();	1000000 cycles
> > }
> > 
> > You spend the damned 10000000 cycles in any case just at a different
> > point in time. So if you are so convinced and have fully understood
> > all the implications, please enlighten me why do_crap() costs less
> > power with the blockers approach.
> 
> Consider the case where the read() is non-blocking.

Which I consider in the same range as the application which does:

      while (1);

> > 1) The kernel blocker does not guarantee that the lousy app has
> >    processed the event. It just guarantees that the lousy app has
> >    emptied the input queue. So what's the point of the kernel blocker
> >    in that case ?
> 
> Yes, I think you're right here. You need the userspace component as well 
> for this to work correctly.
>
> > 2) What's the difference on setting that app to QoS(NONE) and let the
> >    kernel happily ignore it.
> 
> What sets that flag, and how does it interact with an application that 
> never makes a blocking system call?

  QoS(NONE) would be default policy for untrusted apps in the same way
  as you'd refuse the usage of supsend blockers for untrusted apps.
  
  while (1); is definitely not an application which should be granted
  trusted rights, right ?

  block_suspend(); while(1);
  
  is the same as:

  QoS(minimal latency); while(1);

  So if you really go to trust an "while (1);" application you better
  make sure that this app has the appropriate QoS(NONE) or QoS(10s)
  call in it before letting it lose.
 
> > Come up with real explanations and numbers and not just the "it has
> > been demonstrated" chant which is not holding water if you look at the
> > above.
> 
> The numbers were earlier in the thread.

  Numbers, yes. But I really give a sh*t about numbers w/o a detailed
  explanation of the scenario which created those numbers. And if the
  numbers boil down to: we handle the untrusted app which does "while
  (1);" then they are absolutely useless.

> > The kernel history is full of examples where crappy solutions got
> > rejected and kept out of the kernel for a long time even if there was
> > a need for them in the application field and they got shipped in
> > quantities with out of tree patches (NOHZ, high resolution timers,
> > ...). At some point people stopped arguing for crappy solutions and
> > sat down and got it right. The problem of power management and
> > opportunistic suspend is not different in any way.
> 
> Yes, and I'd agree with this if anyone seemed to have any idea how to do 
> it right. But despite all the heat and noise in this thread, all we've 
> got is an expression that it should be handled by the scheduler (a 
> viewpoint I agree with) without any explanation of how to switch 
> policies in such a way that applications idle without losing wakeup 
> events.

Why in the world should they lose wakeup events ? If an app goes idle,
it goes idle because it is waiting for an event. There is no other
sane reason except for those apps which are untrusted and force
idled. And for those you agreed already the suspend blockers don't
solve anything as they are either not implemented or the app is not
trusted to use them.

So we are back to round one of the whole discussion:

   Is it worth to create an utter mess in the kernel just to handle a
   subset of crappy coded applications ?

And the answer stays the same: No, not at all.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > A wakeup event is defined as one that wakes the system - if a system 
> > can't be woken by a specific event then it's impossible to lose it, 
> > since it wasn't a wakeup event to begin with.
> 
> So where is the problem ?

The problem is that, right now, if a wakeup event is received between 
the point where userspace decides to start a suspend and userspace 
actually starts a suspend, that event may not abort the suspend.

> > Consider the case where the read() is non-blocking.
> 
> Which I consider in the same range as the application which does:
> 
>       while (1);

Not at all. Depending on what it reads, it may follow some other path 
where it sleeps. But, as I keep saying, if you don't want to support 
that kind of code then all of this is massively easier.

> > What sets that flag, and how does it interact with an application that 
> > never makes a blocking system call?
> 
>   QoS(NONE) would be default policy for untrusted apps in the same way
>   as you'd refuse the usage of supsend blockers for untrusted apps.
>
>   while (1); is definitely not an application which should be granted
>   trusted rights, right ?

No, but if that while (1) is draw_cows() then the user may want this to 
run while their session is active and stop running while their session 
is idle. So you only want it to be QoS(NONE) in the idle session case. 
How do you change that state?
 
> > The numbers were earlier in the thread.
> 
>   Numbers, yes. But I really give a sh*t about numbers w/o a detailed
>   explanation of the scenario which created those numbers. And if the
>   numbers boil down to: we handle the untrusted app which does "while
>   (1);" then they are absolutely useless.

The tested case was a stock Android install with opportunistic suspend 
enabled and one that just used runtime idle. The lowest power state 
entered was the same on both.

> > Yes, and I'd agree with this if anyone seemed to have any idea how to do 
> > it right. But despite all the heat and noise in this thread, all we've 
> > got is an expression that it should be handled by the scheduler (a 
> > viewpoint I agree with) without any explanation of how to switch 
> > policies in such a way that applications idle without losing wakeup 
> > events.
> 
> Why in the world should they lose wakeup events ? If an app goes idle,
> it goes idle because it is waiting for an event. There is no other
> sane reason except for those apps which are untrusted and force
> idled. And for those you agreed already the suspend blockers don't
> solve anything as they are either not implemented or the app is not
> trusted to use them.
>
> So we are back to round one of the whole discussion:
> 
>    Is it worth to create an utter mess in the kernel just to handle a
>    subset of crappy coded applications ?
> 
> And the answer stays the same: No, not at all.

You need suspend blockers to avoid losing wakeups in the explicit 
suspend case even if you don't want to implement opportunistic suspend.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > A wakeup event is defined as one that wakes the system - if a system 
> > can't be woken by a specific event then it's impossible to lose it, 
> > since it wasn't a wakeup event to begin with.
> 
> So where is the problem ?

The problem is that, right now, if a wakeup event is received between 
the point where userspace decides to start a suspend and userspace 
actually starts a suspend, that event may not abort the suspend.

> > Consider the case where the read() is non-blocking.
> 
> Which I consider in the same range as the application which does:
> 
>       while (1);

Not at all. Depending on what it reads, it may follow some other path 
where it sleeps. But, as I keep saying, if you don't want to support 
that kind of code then all of this is massively easier.

> > What sets that flag, and how does it interact with an application that 
> > never makes a blocking system call?
> 
>   QoS(NONE) would be default policy for untrusted apps in the same way
>   as you'd refuse the usage of supsend blockers for untrusted apps.
>
>   while (1); is definitely not an application which should be granted
>   trusted rights, right ?

No, but if that while (1) is draw_cows() then the user may want this to 
run while their session is active and stop running while their session 
is idle. So you only want it to be QoS(NONE) in the idle session case. 
How do you change that state?
 
> > The numbers were earlier in the thread.
> 
>   Numbers, yes. But I really give a sh*t about numbers w/o a detailed
>   explanation of the scenario which created those numbers. And if the
>   numbers boil down to: we handle the untrusted app which does "while
>   (1);" then they are absolutely useless.

The tested case was a stock Android install with opportunistic suspend 
enabled and one that just used runtime idle. The lowest power state 
entered was the same on both.

> > Yes, and I'd agree with this if anyone seemed to have any idea how to do 
> > it right. But despite all the heat and noise in this thread, all we've 
> > got is an expression that it should be handled by the scheduler (a 
> > viewpoint I agree with) without any explanation of how to switch 
> > policies in such a way that applications idle without losing wakeup 
> > events.
> 
> Why in the world should they lose wakeup events ? If an app goes idle,
> it goes idle because it is waiting for an event. There is no other
> sane reason except for those apps which are untrusted and force
> idled. And for those you agreed already the suspend blockers don't
> solve anything as they are either not implemented or the app is not
> trusted to use them.
>
> So we are back to round one of the whole discussion:
> 
>    Is it worth to create an utter mess in the kernel just to handle a
>    subset of crappy coded applications ?
> 
> And the answer stays the same: No, not at all.

You need suspend blockers to avoid losing wakeups in the explicit 
suspend case even if you don't want to implement opportunistic suspend.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > The event was not lost.
> 
> Not lost, but not delivered. So you need your policy agent to send 

it will be delivered next time the process wakes. It's not lost.

> SIGCONT when you receive any wakeup event, which either means proxying 
> all your network traffic through your policy agent or having some 
> mechanism for alerting the policy agent whenever you leave the deep idle 
> state.

You didn't mention that requirement last time.

> > > also the race of an application being in the middle of handling a wakeup 
> > > event when you send it the signal.
> > 
> > sigmask()
> 
> Doesn't help - I may be hit by the signal between the poll() unblocking 
> and me having the opportunity to call sigmask().

ppoll(). This is all existing solved stuff.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > The event was not lost.
> 
> Not lost, but not delivered. So you need your policy agent to send 

it will be delivered next time the process wakes. It's not lost.

> SIGCONT when you receive any wakeup event, which either means proxying 
> all your network traffic through your policy agent or having some 
> mechanism for alerting the policy agent whenever you leave the deep idle 
> state.

You didn't mention that requirement last time.

> > > also the race of an application being in the middle of handling a wakeup 
> > > event when you send it the signal.
> > 
> > sigmask()
> 
> Doesn't help - I may be hit by the signal between the poll() unblocking 
> and me having the opportunity to call sigmask().

ppoll(). This is all existing solved stuff.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > On Thu, 27 May 2010, Peter Zijlstra wrote:
> > 
> > > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > > > On Thu, 27 May 2010 17:09:16 +0200
> > > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > > 
> > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > > > 
> > > > > >         Opportunistic suspends are okay.
> > > > > > 
> > > > > >         The proposed userspace API is too Android-specific.
> > > > > 
> > > > > I would argue opportunistic suspends are not ok, and therefore the
> > > > > proposed API is utterly irrelevant.
> > > > 
> > > > Assuming you are happy that opportunistically entering C6 and the like is
> > > > ok via ACPI can you explain why you have a problem with opportunistic
> > > > suspend and why it is different to a very deep sleep CPU state such as we
> > > > have now (and which on many embedded platforms we deal with *is* sleeping
> > > > external devices too)
> > > 
> > > Agreed, but I understood the opportunistic suspend line from Alan Stern
> > > to mean the echo opportunistic > /sys/power/foo thing.
> > 
> > Yes, that's what I meant.  Why do you think it is any worse than "echo 
> > mem >/sys/power/state"?  The only difference is that it will block 
> > until all in-kernel suspend blockers are disabled.
> > 
> > Or do you also think that "echo mem >/sys/power/state" is evil and 
> > should be removed from the kernel as soon as possible?
> > 
> > And to answer Thomas's question: The whole reason for having in-kernel 
> > suspend blockers is so that userspace can tell the system to suspend 
> > without losing wakeup events.
> > 
> > Suppose a key is pressed just as a user program writes "mem" to
> > /sys/power/state.  The keyboard driver handles the keystroke and queues
> > an input event.  Then the system suspends and doesn't wake up until
> > some other event occurs -- even though the keypress was an important
> > one and it should have prevented the system from suspending.
> > 
> > With in-kernel suspend blockers and opportunistic suspend, this 
> > scenario is prevented.  That is their raison-d'etre.
> 
> I tend to disagree. You are still looking at suspend as some extra
> esoteric mechanism. We should stop doing this and look at suspend (to
> RAM) as an additional deep idle state, which is well defined in terms
> of power savings and wakeup latency.

Well, the ACPI spec doesn't agree with you. :-)

> That's what I think opportunistic suspend is all about. Now if you look at
> our current idle states in x86 the incoming keystroke is never lost. 
> 
> So when suspend does lose the wakeup event then we need to fix that,

With ACPI, we can't, because we have to switch our wakeup sources from
the "runtime" mode to the "system wakeup" mode in a racy fashion.

> but why do we need suspend blockers for this ? Let's take your example:
> 
> > The keyboard driver handles the keystroke and queues an input
> > event. Then the system goes into suspend ....
> 
> Why do we go into suspend at all?

The decision to go to suspend may be made in parallel to the keystroke in
such a way that we may not be able to detect it (that doesn't apply to the
hardware Android currently runs on, though).

> If there is an event queued then something is woken up and got running,
> which is reason enough _not_ to enter suspend. If that's broken in the
> current implementation then we need to fix it,

That's not a matter of implementation (which I admit can be improved).

> but not with a big hammer by adding another
> interface. We have that information already and obviously we do not
> use it, so lets figure out why before adding suspend blockers just
> because they paper over the underlying problem.

I'm not really sure what information you're referring to.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > On Thu, 27 May 2010, Peter Zijlstra wrote:
> > 
> > > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > > > On Thu, 27 May 2010 17:09:16 +0200
> > > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > > 
> > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > > > 
> > > > > >         Opportunistic suspends are okay.
> > > > > > 
> > > > > >         The proposed userspace API is too Android-specific.
> > > > > 
> > > > > I would argue opportunistic suspends are not ok, and therefore the
> > > > > proposed API is utterly irrelevant.
> > > > 
> > > > Assuming you are happy that opportunistically entering C6 and the like is
> > > > ok via ACPI can you explain why you have a problem with opportunistic
> > > > suspend and why it is different to a very deep sleep CPU state such as we
> > > > have now (and which on many embedded platforms we deal with *is* sleeping
> > > > external devices too)
> > > 
> > > Agreed, but I understood the opportunistic suspend line from Alan Stern
> > > to mean the echo opportunistic > /sys/power/foo thing.
> > 
> > Yes, that's what I meant.  Why do you think it is any worse than "echo 
> > mem >/sys/power/state"?  The only difference is that it will block 
> > until all in-kernel suspend blockers are disabled.
> > 
> > Or do you also think that "echo mem >/sys/power/state" is evil and 
> > should be removed from the kernel as soon as possible?
> > 
> > And to answer Thomas's question: The whole reason for having in-kernel 
> > suspend blockers is so that userspace can tell the system to suspend 
> > without losing wakeup events.
> > 
> > Suppose a key is pressed just as a user program writes "mem" to
> > /sys/power/state.  The keyboard driver handles the keystroke and queues
> > an input event.  Then the system suspends and doesn't wake up until
> > some other event occurs -- even though the keypress was an important
> > one and it should have prevented the system from suspending.
> > 
> > With in-kernel suspend blockers and opportunistic suspend, this 
> > scenario is prevented.  That is their raison-d'etre.
> 
> I tend to disagree. You are still looking at suspend as some extra
> esoteric mechanism. We should stop doing this and look at suspend (to
> RAM) as an additional deep idle state, which is well defined in terms
> of power savings and wakeup latency.

Well, the ACPI spec doesn't agree with you. :-)

> That's what I think opportunistic suspend is all about. Now if you look at
> our current idle states in x86 the incoming keystroke is never lost. 
> 
> So when suspend does lose the wakeup event then we need to fix that,

With ACPI, we can't, because we have to switch our wakeup sources from
the "runtime" mode to the "system wakeup" mode in a racy fashion.

> but why do we need suspend blockers for this ? Let's take your example:
> 
> > The keyboard driver handles the keystroke and queues an input
> > event. Then the system goes into suspend ....
> 
> Why do we go into suspend at all?

The decision to go to suspend may be made in parallel to the keystroke in
such a way that we may not be able to detect it (that doesn't apply to the
hardware Android currently runs on, though).

> If there is an event queued then something is woken up and got running,
> which is reason enough _not_ to enter suspend. If that's broken in the
> current implementation then we need to fix it,

That's not a matter of implementation (which I admit can be improved).

> but not with a big hammer by adding another
> interface. We have that information already and obviously we do not
> use it, so lets figure out why before adding suspend blockers just
> because they paper over the underlying problem.

I'm not really sure what information you're referring to.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > 
> > > If that's what you're aiming for then you don't need to block 
> > > applications on hardware access because they should all already have 
> > > idled themselves.
> > 
> > Correct, a well behaved app would have. I thought we all agreed that
> > well behaved apps weren't the problem?
> 
> Ok. So the existing badly-behaved application ignores your request and 
> then gets blocked. And now it no longer responds to wakeup events. So 
> you penalise well-behaved applications without providing any benefits to 
> badly-behaved ones.

I don't see how you put the first two sentences together and get the
final one.

When you beat up badly behaved apps that doesn't penalise well behaved
ones.

Forcing "well behaved apps" to make hundreds of extra calls to a complex
blocker interface that also requires tons of kernel code and requires the
application know platform policy and be recompiled if it changes - now
that is punishing well behaved apps.

A well behaved app should just work using standard existing APIs because
that is how all the standard current well behaved apps are written [1].

Alan
--
[1] I'm dying to see the suspend blocker patch for evolution ;)

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > 
> > > If that's what you're aiming for then you don't need to block 
> > > applications on hardware access because they should all already have 
> > > idled themselves.
> > 
> > Correct, a well behaved app would have. I thought we all agreed that
> > well behaved apps weren't the problem?
> 
> Ok. So the existing badly-behaved application ignores your request and 
> then gets blocked. And now it no longer responds to wakeup events. So 
> you penalise well-behaved applications without providing any benefits to 
> badly-behaved ones.

I don't see how you put the first two sentences together and get the
final one.

When you beat up badly behaved apps that doesn't penalise well behaved
ones.

Forcing "well behaved apps" to make hundreds of extra calls to a complex
blocker interface that also requires tons of kernel code and requires the
application know platform policy and be recompiled if it changes - now
that is punishing well behaved apps.

A well behaved app should just work using standard existing APIs because
that is how all the standard current well behaved apps are written [1].

Alan
--
[1] I'm dying to see the suspend blocker patch for evolution ;)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:03:14PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 18:59:20 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Ok. So the existing badly-behaved application ignores your request and 
> > then gets blocked. And now it no longer responds to wakeup events. So 
> > you penalise well-behaved applications without providing any benefits to 
> > badly-behaved ones.
> 
> I don't see how you put the first two sentences together and get the
> final one.
> 
> When you beat up badly behaved apps that doesn't penalise well behaved
> ones.

If you're going to block an app on drawing then you either need to 
reenable drawing on wakeup or you need to have an interface for alerting 
the app to the fact that drawing is about to block and it should get 
back to its event loop. The first is suboptimal, the second penalises 
well behaved apps.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:03:14PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 18:59:20 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Ok. So the existing badly-behaved application ignores your request and 
> > then gets blocked. And now it no longer responds to wakeup events. So 
> > you penalise well-behaved applications without providing any benefits to 
> > badly-behaved ones.
> 
> I don't see how you put the first two sentences together and get the
> final one.
> 
> When you beat up badly behaved apps that doesn't penalise well behaved
> ones.

If you're going to block an app on drawing then you either need to 
reenable drawing on wakeup or you need to have an interface for alerting 
the app to the fact that drawing is about to block and it should get 
back to its event loop. The first is suboptimal, the second penalises 
well behaved apps.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote:
> > Not lost, but not delivered. So you need your policy agent to send 
> 
> it will be delivered next time the process wakes. It's not lost.
> 
> > SIGCONT when you receive any wakeup event, which either means proxying 
> > all your network traffic through your policy agent or having some 
> > mechanism for alerting the policy agent whenever you leave the deep idle 
> > state.
> 
> You didn't mention that requirement last time.

I thought it was pretty obvious that wakeup events had to actually be 
delivered to the applications that are listening for them.

> > > > also the race of an application being in the middle of handling a wakeup 
> > > > event when you send it the signal.
> > > 
> > > sigmask()
> > 
> > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > and me having the opportunity to call sigmask().
> 
> ppoll(). This is all existing solved stuff.

Isn't that the inverse of what we want? The application should default 
to being SIGSTOPpable except in the case of it being in the process of 
having a specific event delivered.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote:
> > Not lost, but not delivered. So you need your policy agent to send 
> 
> it will be delivered next time the process wakes. It's not lost.
> 
> > SIGCONT when you receive any wakeup event, which either means proxying 
> > all your network traffic through your policy agent or having some 
> > mechanism for alerting the policy agent whenever you leave the deep idle 
> > state.
> 
> You didn't mention that requirement last time.

I thought it was pretty obvious that wakeup events had to actually be 
delivered to the applications that are listening for them.

> > > > also the race of an application being in the middle of handling a wakeup 
> > > > event when you send it the signal.
> > > 
> > > sigmask()
> > 
> > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > and me having the opportunity to call sigmask().
> 
> ppoll(). This is all existing solved stuff.

Isn't that the inverse of what we want? The application should default 
to being SIGSTOPpable except in the case of it being in the process of 
having a specific event delivered.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
> > 
> > They may be different conceptually.  Nevertheless, Android uses forced 
> > suspend as a form of power saving.  Until better mechanisms are in 
> > place, it makes sense. 
> 
> So let them, doesn't mean we have to merge it. Or will you saw your foot
> off too if google were to promotes it?

Do you have to be offensive to people who disagree with you?

Alan simply wants to understand the _technical_ objections that people have
to this patchset and you're not helping.  So, could you please explain what
exactly is your technical objection to it?

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
> > 
> > They may be different conceptually.  Nevertheless, Android uses forced 
> > suspend as a form of power saving.  Until better mechanisms are in 
> > place, it makes sense. 
> 
> So let them, doesn't mean we have to merge it. Or will you saw your foot
> off too if google were to promotes it?

Do you have to be offensive to people who disagree with you?

Alan simply wants to understand the _technical_ objections that people have
to this patchset and you're not helping.  So, could you please explain what
exactly is your technical objection to it?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> 
> > On Thu, 27 May 2010, Felipe Balbi wrote:
> > 
> > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > >If people don't mind, here is a greatly simplified summary of the
> > > >comments and objections I have seen so far on this thread:
> > > >
> > > >	The in-kernel suspend blocker implementation is okay, even
> > > >	beneficial.
> > > 
> > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > the kernel decide which power state is better as long as I can say I 
> > > need 100us IRQ latency or 100ms wakeup latency.
> > 
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> 
> mem should be replaced by an idle suspend to ram mechanism

Well, what about when I want the machine to suspend _regardless_ of whether
or not it's idle at the moment?  That actually happens quite often to me. :-)

> > attention to latencies or other requirements.
> 
> s2disk is a totally different beast as it shuts down the box into the
> complete power off state.

I don't see much difference between that and ACPI S3 other than the memory
contents are preserved in S3.  It also is complete power off state - except for
memory refresh and wakeup sources (which also may be active in S4).

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> 
> > On Thu, 27 May 2010, Felipe Balbi wrote:
> > 
> > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > >If people don't mind, here is a greatly simplified summary of the
> > > >comments and objections I have seen so far on this thread:
> > > >
> > > >	The in-kernel suspend blocker implementation is okay, even
> > > >	beneficial.
> > > 
> > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > the kernel decide which power state is better as long as I can say I 
> > > need 100us IRQ latency or 100ms wakeup latency.
> > 
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> 
> mem should be replaced by an idle suspend to ram mechanism

Well, what about when I want the machine to suspend _regardless_ of whether
or not it's idle at the moment?  That actually happens quite often to me. :-)

> > attention to latencies or other requirements.
> 
> s2disk is a totally different beast as it shuts down the box into the
> complete power off state.

I don't see much difference between that and ACPI S3 other than the memory
contents are preserved in S3.  It also is complete power off state - except for
memory refresh and wakeup sources (which also may be active in S4).

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > > Heck, for all I care, simply SIGKILL the thing and report it once the
> > > user starts looking at his screen again.
> > 
> > Provide incentive for Joe Clicker to improve his app, instead of cope
> > with the shit he created.
> 
> That isn't helpful. But if you feel like that I suggest you run with your
> memory management protection disabled, it's really on there to deal with
> crap code and its giving the wrong incentives. Come to think of it
> you might want to remove your seatbelts and any safety catches or airbags
> - it only encourages carelessness.
> 
> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')
> 
> Arguing that you don't need to do this isn't useful. Android has
> demonstrated a need to do this. RT has a need to do some of this.
> Virtualisation wants elements of this etc.
> 
> The question is how you do it right.

I violently agree, thanks Alan!

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > > Heck, for all I care, simply SIGKILL the thing and report it once the
> > > user starts looking at his screen again.
> > 
> > Provide incentive for Joe Clicker to improve his app, instead of cope
> > with the shit he created.
> 
> That isn't helpful. But if you feel like that I suggest you run with your
> memory management protection disabled, it's really on there to deal with
> crap code and its giving the wrong incentives. Come to think of it
> you might want to remove your seatbelts and any safety catches or airbags
> - it only encourages carelessness.
> 
> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')
> 
> Arguing that you don't need to do this isn't useful. Android has
> demonstrated a need to do this. RT has a need to do some of this.
> Virtualisation wants elements of this etc.
> 
> The question is how you do it right.

I violently agree, thanks Alan!

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> > > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > > and me having the opportunity to call sigmask().
> > 
> > ppoll(). This is all existing solved stuff.
> 
> Isn't that the inverse of what we want? The application should default 
> to being SIGSTOPpable except in the case of it being in the process of 
> having a specific event delivered.

Would it help to divide the application into two processes, one of 
which receives events and the other does the drawing?

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> > > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > > and me having the opportunity to call sigmask().
> > 
> > ppoll(). This is all existing solved stuff.
> 
> Isn't that the inverse of what we want? The application should default 
> to being SIGSTOPpable except in the case of it being in the process of 
> having a specific event delivered.

Would it help to divide the application into two processes, one of 
which receives events and the other does the drawing?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> > > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > > and me having the opportunity to call sigmask().
> > 
> > ppoll(). This is all existing solved stuff.
> 
> Isn't that the inverse of what we want? The application should default 
> to being SIGSTOPpable except in the case of it being in the process of 
> having a specific event delivered.

Would it help to divide the application into two processes, one of 
which receives events and the other does the drawing?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> That's the point -- suspend does not evaluate the system state 
> correctly because it doesn't have the necessary information.  Suspend 

The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.

> blockers are a way of providing it that information.  They don't paper 
> over the problem; they solve it.

I'm still unconvinced (see Thomas examples as a starter) and even if they
did, the cure would be far worse than the disease.

The hardware world also shows how you handle suspend/resume event races
cleanly and in turn how we can handle right from user to hardware.

If you are dealing with a well behaved UI app then its event loop will
just do

	if (message == UI_OFF) {
		stop_background_stuff();
		event_mask &= stuff;
		send_reply(NIGHT_NIGHT);
		continue;
		/* Back to poll() */
	}

and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up. If the event
gets in after pm decides to idle via suspend then it'll bounce through
the kernel back to a kernel resume, or potentially through a full
hardware/software suspend/resume bounce. You have one person who needs to
track the sequence - that's however is the guy sending UI_ON/UI_OFF
information and making the screen light up.

If you are dealing with a badly behaved app then you can't win because it
may not have the magic 'suspend blockers' or will do it wrong. You
can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a
bit, or via nice or other QoS policy) but you can't assume it'll
magically managge itself. It is "badly behaved" so by that very
definition you can't assume it has correct magic goo in it. (Side note:
the extra magic goo and complexity of such blockers makes it more likely
the app will be buggy and thus 'badly behaved' !)

You can pick up which tasks are stopping the suspend fairly easily at the
moment via the ktrace interfaces. Maybe there is a case for making that
tidier but powertop and the like already demonstrate you can track this.

A cpu policy can obviously expose offenders itself directly to user
space. That (and indeed people not responding to UI_OFF) then lets your
phone do

	<boop>
	X is misbehaving
	[Close it] [Allow this time] [Disable]

and also to provide stats for each wakeup a policy manager can spot
offenders (even those who are perhaps hard to see because they wake up a
little bit every so often but just enough to mess up pm). In the x86
world Arjan found a *lot* of that sort of stuff.

Your policy manager can also act on it. The current policy manager is
to fix app bugs and shows people up at conferences. I would imagine a
google policy would be to collate misbehaving app reports at google.com
and use them both to assist in 'educating' authors and in scoring app
store stuff.

As it is <boop> X is misbehaving is a powerful economic lever in a
pretty dynamic and functioning software market.

Google seem to be pretty good at statistical data, I can't believe
battery advice for apps on the app stores and indeed a 'where did my
battery go' pie chart are beyond their wit, or beyond the end user to
figure out.

There are a considerable number of people shipping power constrained
Linux devices without suddenely desperately needing extra magic potions.
Are they really all just that much smarter than Google ?

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> That's the point -- suspend does not evaluate the system state 
> correctly because it doesn't have the necessary information.  Suspend 

The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.

> blockers are a way of providing it that information.  They don't paper 
> over the problem; they solve it.

I'm still unconvinced (see Thomas examples as a starter) and even if they
did, the cure would be far worse than the disease.

The hardware world also shows how you handle suspend/resume event races
cleanly and in turn how we can handle right from user to hardware.

If you are dealing with a well behaved UI app then its event loop will
just do

	if (message == UI_OFF) {
		stop_background_stuff();
		event_mask &= stuff;
		send_reply(NIGHT_NIGHT);
		continue;
		/* Back to poll() */
	}

and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up. If the event
gets in after pm decides to idle via suspend then it'll bounce through
the kernel back to a kernel resume, or potentially through a full
hardware/software suspend/resume bounce. You have one person who needs to
track the sequence - that's however is the guy sending UI_ON/UI_OFF
information and making the screen light up.

If you are dealing with a badly behaved app then you can't win because it
may not have the magic 'suspend blockers' or will do it wrong. You
can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a
bit, or via nice or other QoS policy) but you can't assume it'll
magically managge itself. It is "badly behaved" so by that very
definition you can't assume it has correct magic goo in it. (Side note:
the extra magic goo and complexity of such blockers makes it more likely
the app will be buggy and thus 'badly behaved' !)

You can pick up which tasks are stopping the suspend fairly easily at the
moment via the ktrace interfaces. Maybe there is a case for making that
tidier but powertop and the like already demonstrate you can track this.

A cpu policy can obviously expose offenders itself directly to user
space. That (and indeed people not responding to UI_OFF) then lets your
phone do

	<boop>
	X is misbehaving
	[Close it] [Allow this time] [Disable]

and also to provide stats for each wakeup a policy manager can spot
offenders (even those who are perhaps hard to see because they wake up a
little bit every so often but just enough to mess up pm). In the x86
world Arjan found a *lot* of that sort of stuff.

Your policy manager can also act on it. The current policy manager is
to fix app bugs and shows people up at conferences. I would imagine a
google policy would be to collate misbehaving app reports at google.com
and use them both to assist in 'educating' authors and in scoring app
store stuff.

As it is <boop> X is misbehaving is a powerful economic lever in a
pretty dynamic and functioning software market.

Google seem to be pretty good at statistical data, I can't believe
battery advice for apps on the app stores and indeed a 'where did my
battery go' pie chart are beyond their wit, or beyond the end user to
figure out.

There are a considerable number of people shipping power constrained
Linux devices without suddenely desperately needing extra magic potions.
Are they really all just that much smarter than Google ?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> That's the point -- suspend does not evaluate the system state 
> correctly because it doesn't have the necessary information.  Suspend 

The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.

> blockers are a way of providing it that information.  They don't paper 
> over the problem; they solve it.

I'm still unconvinced (see Thomas examples as a starter) and even if they
did, the cure would be far worse than the disease.

The hardware world also shows how you handle suspend/resume event races
cleanly and in turn how we can handle right from user to hardware.

If you are dealing with a well behaved UI app then its event loop will
just do

	if (message == UI_OFF) {
		stop_background_stuff();
		event_mask &= stuff;
		send_reply(NIGHT_NIGHT);
		continue;
		/* Back to poll() */
	}

and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up. If the event
gets in after pm decides to idle via suspend then it'll bounce through
the kernel back to a kernel resume, or potentially through a full
hardware/software suspend/resume bounce. You have one person who needs to
track the sequence - that's however is the guy sending UI_ON/UI_OFF
information and making the screen light up.

If you are dealing with a badly behaved app then you can't win because it
may not have the magic 'suspend blockers' or will do it wrong. You
can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a
bit, or via nice or other QoS policy) but you can't assume it'll
magically managge itself. It is "badly behaved" so by that very
definition you can't assume it has correct magic goo in it. (Side note:
the extra magic goo and complexity of such blockers makes it more likely
the app will be buggy and thus 'badly behaved' !)

You can pick up which tasks are stopping the suspend fairly easily at the
moment via the ktrace interfaces. Maybe there is a case for making that
tidier but powertop and the like already demonstrate you can track this.

A cpu policy can obviously expose offenders itself directly to user
space. That (and indeed people not responding to UI_OFF) then lets your
phone do

	<boop>
	X is misbehaving
	[Close it] [Allow this time] [Disable]

and also to provide stats for each wakeup a policy manager can spot
offenders (even those who are perhaps hard to see because they wake up a
little bit every so often but just enough to mess up pm). In the x86
world Arjan found a *lot* of that sort of stuff.

Your policy manager can also act on it. The current policy manager is
to fix app bugs and shows people up at conferences. I would imagine a
google policy would be to collate misbehaving app reports at google.com
and use them both to assist in 'educating' authors and in scoring app
store stuff.

As it is <boop> X is misbehaving is a powerful economic lever in a
pretty dynamic and functioning software market.

Google seem to be pretty good at statistical data, I can't believe
battery advice for apps on the app stores and indeed a 'where did my
battery go' pie chart are beyond their wit, or beyond the end user to
figure out.

There are a considerable number of people shipping power constrained
Linux devices without suddenely desperately needing extra magic potions.
Are they really all just that much smarter than Google ?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > A wakeup event is defined as one that wakes the system - if a system 
> > > can't be woken by a specific event then it's impossible to lose it, 
> > > since it wasn't a wakeup event to begin with.
> > 
> > So where is the problem ?
> 
> The problem is that, right now, if a wakeup event is received between 
> the point where userspace decides to start a suspend and userspace 
> actually starts a suspend, that event may not abort the suspend.

The two of you are talking at cross purposes.  Thomas is referring to 
idle-based suspend and Matthew is talking about forced suspend.

Or at least, that's how it appears to me.  No wonder you can't agree on 
anything.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > A wakeup event is defined as one that wakes the system - if a system 
> > > can't be woken by a specific event then it's impossible to lose it, 
> > > since it wasn't a wakeup event to begin with.
> > 
> > So where is the problem ?
> 
> The problem is that, right now, if a wakeup event is received between 
> the point where userspace decides to start a suspend and userspace 
> actually starts a suspend, that event may not abort the suspend.

The two of you are talking at cross purposes.  Thomas is referring to 
idle-based suspend and Matthew is talking about forced suspend.

Or at least, that's how it appears to me.  No wonder you can't agree on 
anything.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > A wakeup event is defined as one that wakes the system - if a system 
> > > can't be woken by a specific event then it's impossible to lose it, 
> > > since it wasn't a wakeup event to begin with.
> > 
> > So where is the problem ?
> 
> The problem is that, right now, if a wakeup event is received between 
> the point where userspace decides to start a suspend and userspace 
> actually starts a suspend, that event may not abort the suspend.

The two of you are talking at cross purposes.  Thomas is referring to 
idle-based suspend and Matthew is talking about forced suspend.

Or at least, that's how it appears to me.  No wonder you can't agree on 
anything.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote:

> Would it help to divide the application into two processes, one of 
> which receives events and the other does the drawing?

At the point where you're rewriting the application you can just make it 
adhere to our current behavioural standards anyway.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote:

> Would it help to divide the application into two processes, one of 
> which receives events and the other does the drawing?

At the point where you're rewriting the application you can just make it 
adhere to our current behavioural standards anyway.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Well, what about when I want the machine to suspend _regardless_ of whether
> or not it's idle at the moment?  That actually happens quite often to me. :-)

I don't think it helps to combine them for this discussion ?

> I don't see much difference between that and ACPI S3 other than the memory
> contents are preserved in S3.  It also is complete power off state - except for
> memory refresh and wakeup sources (which also may be active in S4).

Agreed although I am pushed to think of many real world cases where it
might matter. VM's maybe?

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Well, what about when I want the machine to suspend _regardless_ of whether
> or not it's idle at the moment?  That actually happens quite often to me. :-)

I don't think it helps to combine them for this discussion ?

> I don't see much difference between that and ACPI S3 other than the memory
> contents are preserved in S3.  It also is complete power off state - except for
> memory refresh and wakeup sources (which also may be active in S4).

Agreed although I am pushed to think of many real world cases where it
might matter. VM's maybe?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Matthew Garrett wrote:
> 
> > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > > A wakeup event is defined as one that wakes the system - if a system 
> > > > can't be woken by a specific event then it's impossible to lose it, 
> > > > since it wasn't a wakeup event to begin with.
> > > 
> > > So where is the problem ?
> > 
> > The problem is that, right now, if a wakeup event is received between 
> > the point where userspace decides to start a suspend and userspace 
> > actually starts a suspend, that event may not abort the suspend.
> 
> The two of you are talking at cross purposes.  Thomas is referring to 
> idle-based suspend and Matthew is talking about forced suspend.

Yes, and forced suspend to disk is the same as force suspend to disk,
which has both nothing to do with sensible resource management.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Matthew Garrett wrote:
> 
> > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > > A wakeup event is defined as one that wakes the system - if a system 
> > > > can't be woken by a specific event then it's impossible to lose it, 
> > > > since it wasn't a wakeup event to begin with.
> > > 
> > > So where is the problem ?
> > 
> > The problem is that, right now, if a wakeup event is received between 
> > the point where userspace decides to start a suspend and userspace 
> > actually starts a suspend, that event may not abort the suspend.
> 
> The two of you are talking at cross purposes.  Thomas is referring to 
> idle-based suspend and Matthew is talking about forced suspend.

Yes, and forced suspend to disk is the same as force suspend to disk,
which has both nothing to do with sensible resource management.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 13:29:18 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> > > 
> > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > attention to latencies or other requirements. 
> > 
> > Those are a whole different beast, those are basically a quick-off
> > button like thing. Forced suspend is conceptually a very different beast
> > from power-saving a running system.
> 
> They may be different conceptually.  Nevertheless, Android uses forced 
> suspend as a form of power saving.  Until better mechanisms are in 
> place, it makes sense.

For them, not for Linux.

Several vendors have exciting kernel drivers that do things like binary
patch other modules. Until better mechanisms are in place it does *NOT*
make sense to merge such stuff.

I don't care what they do in their own tree (consenting adults in their
own home and all that) but what they do in the public tree is another
matter.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 13:29:18 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> > > 
> > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > attention to latencies or other requirements. 
> > 
> > Those are a whole different beast, those are basically a quick-off
> > button like thing. Forced suspend is conceptually a very different beast
> > from power-saving a running system.
> 
> They may be different conceptually.  Nevertheless, Android uses forced 
> suspend as a form of power saving.  Until better mechanisms are in 
> place, it makes sense.

For them, not for Linux.

Several vendors have exciting kernel drivers that do things like binary
patch other modules. Until better mechanisms are in place it does *NOT*
make sense to merge such stuff.

I don't care what they do in their own tree (consenting adults in their
own home and all that) but what they do in the public tree is another
matter.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> 
> > On some platforms (like those with ACPI), deeper power-savings are
> > available by using forced suspend than by using idle. 
> 
> Sounds like something that's fixable, doesn't it?

The fix would probably have to involve rewriting the ACPI spec.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> 
> > On some platforms (like those with ACPI), deeper power-savings are
> > available by using forced suspend than by using idle. 
> 
> Sounds like something that's fixable, doesn't it?

The fix would probably have to involve rewriting the ACPI spec.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 18:25:10 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > one) turn the screen back on?
> 
> Well on my laptop today it works like this
> 
> A WoL packet arrives
> The CPU resumes
> Depp process, chipset and laptop BIOS magic happens
> The kernel gets called
> The kernel lets interested people know a resume occurred

No it doesn't. The kernel continues executing anything that was on the 
runqueue before the scheduler stopped. If you're using idle-based 
suspend then there's nothing on the runqueue - the application that 
should be scheduled because of the event is blocked on writing to the 
screen.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 18:25:10 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > one) turn the screen back on?
> 
> Well on my laptop today it works like this
> 
> A WoL packet arrives
> The CPU resumes
> Depp process, chipset and laptop BIOS magic happens
> The kernel gets called
> The kernel lets interested people know a resume occurred

No it doesn't. The kernel continues executing anything that was on the 
runqueue before the scheduler stopped. If you're using idle-based 
suspend then there's nothing on the runqueue - the application that 
should be scheduled because of the event is blocked on writing to the 
screen.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
> 
> > Suppose X (or whatever windowing system) will block all clients that try
> > to draw when you switch off your screen.
> > 
> > How would we not wake them when we do turn the screen back on and start
> > servicing the pending requests again?
> 
> How (and why) does the WoL (which may be *any* packet, not just a magic 
> one) turn the screen back on?

Well on my laptop today it works like this

A WoL packet arrives
The CPU resumes
Depp process, chipset and laptop BIOS magic happens
The kernel gets called
The kernel lets interested people know a resume occurred
The X server sees this
X reconfigures the display
X redraws the display (either by sending everyone expose events or by
keeping the bits, not sure how it works this week as it has changed over
time)

My desktop re-appears


Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
> 
> > Suppose X (or whatever windowing system) will block all clients that try
> > to draw when you switch off your screen.
> > 
> > How would we not wake them when we do turn the screen back on and start
> > servicing the pending requests again?
> 
> How (and why) does the WoL (which may be *any* packet, not just a magic 
> one) turn the screen back on?

Well on my laptop today it works like this

A WoL packet arrives
The CPU resumes
Depp process, chipset and laptop BIOS magic happens
The kernel gets called
The kernel lets interested people know a resume occurred
The X server sees this
X reconfigures the display
X redraws the display (either by sending everyone expose events or by
keeping the bits, not sure how it works this week as it has changed over
time)

My desktop re-appears


Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> 
> The power management layer knows if the machine is idle, it has insight
> into when the next wakeups will occur.

But not the kind of insight we need.  See below.

> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> I'm still unconvinced (see Thomas examples as a starter) and even if they
> did, the cure would be far worse than the disease.

Perhaps.

> The hardware world also shows how you handle suspend/resume event races
> cleanly and in turn how we can handle right from user to hardware.
> 
> If you are dealing with a well behaved UI app then its event loop will
> just do
> 
> 	if (message == UI_OFF) {
> 		stop_background_stuff();
> 		event_mask &= stuff;
> 		send_reply(NIGHT_NIGHT);
> 		continue;
> 		/* Back to poll() */
> 	}
> 
> and power management does the rest. If an event wakes up the process
> before we get to suspend in kernel we will wake it back up.

Okay, and the kernel never suspends.  We _are_ talking about a kind of
forced suspend, right?

>  If the event
> gets in after pm decides to idle via suspend then it'll bounce through
> the kernel back to a kernel resume,

No, it won't.  That's the problem suspend blockers were meant to solve.  
The event winds up sitting in a kernel queue, the PM core doesn't know
about it (that's what I meant above -- the PM core doesn't know as much
as you seem to think it does), and the suspend takes place regardless.

> or potentially through a full
> hardware/software suspend/resume bounce.

It would be okay if that happened.  But once the event gets into the
kernel and the hardware IRQ source has turned off, there's nothing to
cause the resume.

> You have one person who needs to
> track the sequence - that's however is the guy sending UI_ON/UI_OFF
> information and making the screen light up.
> 
> If you are dealing with a badly behaved app then you can't win because it
> may not have the magic 'suspend blockers' or will do it wrong.

Agreed.  Badly behaved apps must not be allowed to block suspends.  As 
far as I'm concerned, we can ignore them.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> 
> The power management layer knows if the machine is idle, it has insight
> into when the next wakeups will occur.

But not the kind of insight we need.  See below.

> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> I'm still unconvinced (see Thomas examples as a starter) and even if they
> did, the cure would be far worse than the disease.

Perhaps.

> The hardware world also shows how you handle suspend/resume event races
> cleanly and in turn how we can handle right from user to hardware.
> 
> If you are dealing with a well behaved UI app then its event loop will
> just do
> 
> 	if (message == UI_OFF) {
> 		stop_background_stuff();
> 		event_mask &= stuff;
> 		send_reply(NIGHT_NIGHT);
> 		continue;
> 		/* Back to poll() */
> 	}
> 
> and power management does the rest. If an event wakes up the process
> before we get to suspend in kernel we will wake it back up.

Okay, and the kernel never suspends.  We _are_ talking about a kind of
forced suspend, right?

>  If the event
> gets in after pm decides to idle via suspend then it'll bounce through
> the kernel back to a kernel resume,

No, it won't.  That's the problem suspend blockers were meant to solve.  
The event winds up sitting in a kernel queue, the PM core doesn't know
about it (that's what I meant above -- the PM core doesn't know as much
as you seem to think it does), and the suspend takes place regardless.

> or potentially through a full
> hardware/software suspend/resume bounce.

It would be okay if that happened.  But once the event gets into the
kernel and the hardware IRQ source has turned off, there's nothing to
cause the resume.

> You have one person who needs to
> track the sequence - that's however is the guy sending UI_ON/UI_OFF
> information and making the screen light up.
> 
> If you are dealing with a badly behaved app then you can't win because it
> may not have the magic 'suspend blockers' or will do it wrong.

Agreed.  Badly behaved apps must not be allowed to block suspends.  As 
far as I'm concerned, we can ignore them.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Alan Cox wrote:

> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> 
> The power management layer knows if the machine is idle, it has insight
> into when the next wakeups will occur.

But not the kind of insight we need.  See below.

> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> I'm still unconvinced (see Thomas examples as a starter) and even if they
> did, the cure would be far worse than the disease.

Perhaps.

> The hardware world also shows how you handle suspend/resume event races
> cleanly and in turn how we can handle right from user to hardware.
> 
> If you are dealing with a well behaved UI app then its event loop will
> just do
> 
> 	if (message == UI_OFF) {
> 		stop_background_stuff();
> 		event_mask &= stuff;
> 		send_reply(NIGHT_NIGHT);
> 		continue;
> 		/* Back to poll() */
> 	}
> 
> and power management does the rest. If an event wakes up the process
> before we get to suspend in kernel we will wake it back up.

Okay, and the kernel never suspends.  We _are_ talking about a kind of
forced suspend, right?

>  If the event
> gets in after pm decides to idle via suspend then it'll bounce through
> the kernel back to a kernel resume,

No, it won't.  That's the problem suspend blockers were meant to solve.  
The event winds up sitting in a kernel queue, the PM core doesn't know
about it (that's what I meant above -- the PM core doesn't know as much
as you seem to think it does), and the suspend takes place regardless.

> or potentially through a full
> hardware/software suspend/resume bounce.

It would be okay if that happened.  But once the event gets into the
kernel and the hardware IRQ source has turned off, there's nothing to
cause the resume.

> You have one person who needs to
> track the sequence - that's however is the guy sending UI_ON/UI_OFF
> information and making the screen light up.
> 
> If you are dealing with a badly behaved app then you can't win because it
> may not have the magic 'suspend blockers' or will do it wrong.

Agreed.  Badly behaved apps must not be allowed to block suspends.  As 
far as I'm concerned, we can ignore them.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:33:32PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

It doesn't matter. Current forced suspend to RAM is racy with respect to 
wakeup events and should be fixed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:33:32PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

It doesn't matter. Current forced suspend to RAM is racy with respect to 
wakeup events and should be fixed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Rafael J. Wysocki wrote:

> On Thursday 27 May 2010, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Alan Stern wrote:
> > 
> > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > 
> > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > >If people don't mind, here is a greatly simplified summary of the
> > > > >comments and objections I have seen so far on this thread:
> > > > >
> > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > >	beneficial.
> > > > 
> > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > the kernel decide which power state is better as long as I can say I 
> > > > need 100us IRQ latency or 100ms wakeup latency.
> > > 
> > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > 
> > mem should be replaced by an idle suspend to ram mechanism
> 
> Well, what about when I want the machine to suspend _regardless_ of whether
> or not it's idle at the moment?  That actually happens quite often to me. :-)

Fair enough. Let's agree on a non ambigous terminology then:

     forced:

	     suspend which you enforce via user interaction, which
     	     also implies that you risk losing wakeups depending on
     	     the hardware properties

     opportunistic:

	     suspend driven from the idle context, which guarantees to
	     not lose wakeups. Provided only when the hardware does
	     provide the necessary capabilities.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Rafael J. Wysocki wrote:

> On Thursday 27 May 2010, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Alan Stern wrote:
> > 
> > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > 
> > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > >If people don't mind, here is a greatly simplified summary of the
> > > > >comments and objections I have seen so far on this thread:
> > > > >
> > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > >	beneficial.
> > > > 
> > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > the kernel decide which power state is better as long as I can say I 
> > > > need 100us IRQ latency or 100ms wakeup latency.
> > > 
> > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > 
> > mem should be replaced by an idle suspend to ram mechanism
> 
> Well, what about when I want the machine to suspend _regardless_ of whether
> or not it's idle at the moment?  That actually happens quite often to me. :-)

Fair enough. Let's agree on a non ambigous terminology then:

     forced:

	     suspend which you enforce via user interaction, which
     	     also implies that you risk losing wakeups depending on
     	     the hardware properties

     opportunistic:

	     suspend driven from the idle context, which guarantees to
	     not lose wakeups. Provided only when the hardware does
	     provide the necessary capabilities.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:36:26 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Thursday 27 May 2010, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> > 
> > > On some platforms (like those with ACPI), deeper power-savings are
> > > available by using forced suspend than by using idle. 
> > 
> > Sounds like something that's fixable, doesn't it?
> 
> The fix would probably have to involve rewriting the ACPI spec.

We are on about the fourth version of ACPI already. ACPI evolves and
improves and extends. It's not an impossibility to sort that out if
everyone in the x86 OS world starts thinking 'How come their ARM platform
can do this'

We are also on at least the second suspend/resume model in Linux. The
first was 'isn't this APM stuff neat', the second is heavily oriented
around ACPI ideas. And we already have SoC people moving into the third
model and making it work on non-x6 ('suspend is not special').

I've not poked at the current desktop stuff enough to see if the
gnome-power-manager and friends handle pushing the suspend button with
dbus notifiers to apps. I guess it does.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:36:26 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Thursday 27 May 2010, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> > 
> > > On some platforms (like those with ACPI), deeper power-savings are
> > > available by using forced suspend than by using idle. 
> > 
> > Sounds like something that's fixable, doesn't it?
> 
> The fix would probably have to involve rewriting the ACPI spec.

We are on about the fourth version of ACPI already. ACPI evolves and
improves and extends. It's not an impossibility to sort that out if
everyone in the x86 OS world starts thinking 'How come their ARM platform
can do this'

We are also on at least the second suspend/resume model in Linux. The
first was 'isn't this APM stuff neat', the second is heavily oriented
around ACPI ideas. And we already have SoC people moving into the third
model and making it work on non-x6 ('suspend is not special').

I've not poked at the current desktop stuff enough to see if the
gnome-power-manager and friends handle pushing the suspend button with
dbus notifiers to apps. I guess it does.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

If I understand correctly, you are saying that all the untrusted 
applications should run with QoS(NONE).  Then they could do whatever 
they wanted without causing any interference.

And with idle-based power management (rather than forced suspend), 
there would be no issue with wakeup events getting unduly delayed.

Unless one of those events was meant for an untrusted application.  Is 
that the source of the difficulty?

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

If I understand correctly, you are saying that all the untrusted 
applications should run with QoS(NONE).  Then they could do whatever 
they wanted without causing any interference.

And with idle-based power management (rather than forced suspend), 
there would be no issue with wakeup events getting unduly delayed.

Unless one of those events was meant for an untrusted application.  Is 
that the source of the difficulty?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

If I understand correctly, you are saying that all the untrusted 
applications should run with QoS(NONE).  Then they could do whatever 
they wanted without causing any interference.

And with idle-based power management (rather than forced suspend), 
there would be no issue with wakeup events getting unduly delayed.

Unless one of those events was meant for an untrusted application.  Is 
that the source of the difficulty?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > > If one works so does the other.
> > 
> > Not at all. The entire point of opportunistic suspend is that I don't 
> > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > in 100msec - based on policy (through not having any held suspend 
> > blockers), I'll go to sleep. That's easily possible on PCs.
> 
> Yes I appreciate what suspend blockers are trying to do. Now how does
> that connect with my first sentence ?

I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
a very deep CPU idle state, because of the way wakeup sources are set up
for it, while you could use it for aggressive power management with suspend
blockers as proposed by Arve.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > > If one works so does the other.
> > 
> > Not at all. The entire point of opportunistic suspend is that I don't 
> > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > in 100msec - based on policy (through not having any held suspend 
> > blockers), I'll go to sleep. That's easily possible on PCs.
> 
> Yes I appreciate what suspend blockers are trying to do. Now how does
> that connect with my first sentence ?

I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
a very deep CPU idle state, because of the way wakeup sources are set up
for it, while you could use it for aggressive power management with suspend
blockers as proposed by Arve.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 22:36:35 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 18:25:10 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > > one) turn the screen back on?
> > 
> > Well on my laptop today it works like this
> > 
> > A WoL packet arrives
> > The CPU resumes
> > Depp process, chipset and laptop BIOS magic happens
> > The kernel gets called
> > The kernel lets interested people know a resume occurred
> 
> No it doesn't. The kernel continues executing anything that was on the 

Would you like to come and watch my laptop resume ? With printk's if you
want. You appear at this point to be arguing that bumble bees can't
fly, while watching one.

> runqueue before the scheduler stopped. If you're using idle-based 
> suspend then there's nothing on the runqueue - the application that 
> should be scheduled because of the event is blocked on writing to the 
> screen.

IFF its your bogus example
IFF you don't have any task waiting for resume notifications (ie its not
X)

So take the PC desktop case and for simplicity sake lets assume the X
application in question has either filled the socket (unlikely) or is mid
query request so blocked on the socket.

The important line then is

'The kernel lets interested people know a resume occurred'

Interesting people includes X
X therefore ends up on the runqueue
X gets the display back in order
X completes processing the outstanding X request and replies
The application continues

If I was blocked on say serial output then the resume is going to wake
the serial driver, which will transmit the queue, which will wake the app.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 22:36:35 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 18:25:10 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > How (and why) does the WoL (which may be *any* packet, not just a magic 
> > > one) turn the screen back on?
> > 
> > Well on my laptop today it works like this
> > 
> > A WoL packet arrives
> > The CPU resumes
> > Depp process, chipset and laptop BIOS magic happens
> > The kernel gets called
> > The kernel lets interested people know a resume occurred
> 
> No it doesn't. The kernel continues executing anything that was on the 

Would you like to come and watch my laptop resume ? With printk's if you
want. You appear at this point to be arguing that bumble bees can't
fly, while watching one.

> runqueue before the scheduler stopped. If you're using idle-based 
> suspend then there's nothing on the runqueue - the application that 
> should be scheduled because of the event is blocked on writing to the 
> screen.

IFF its your bogus example
IFF you don't have any task waiting for resume notifications (ie its not
X)

So take the PC desktop case and for simplicity sake lets assume the X
application in question has either filled the socket (unlikely) or is mid
query request so blocked on the socket.

The important line then is

'The kernel lets interested people know a resume occurred'

Interesting people includes X
X therefore ends up on the runqueue
X gets the display back in order
X completes processing the outstanding X request and replies
The application continues

If I was blocked on say serial output then the resume is going to wake
the serial driver, which will transmit the queue, which will wake the app.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> 
> > On Thu, 27 May 2010, Thomas Gleixner wrote:
> > 
> > > Crap. Stop beating on those lost wakeup events. If we lose them then
> > > the drivers are broken and do not handle the switch over correctly. Or
> > > the suspend mechanism is broken as it does not evaluate the system
> > > state correctly. Blockers are just papering over that w/o tackling the
> > > real problem.
> > 
> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> Nonsense. The system state is well defined when a event is pending and
> we just have to say good bye to the idea that forced suspend is a good
> solution. It's not as it does not guarantee the event processing in
> badly written apps and it does move the power consumption to a later
> point in time for those apps which acquire/drop the blockers.

Well, now you have stated that Android actually doesn't work. :-)

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> 
> > On Thu, 27 May 2010, Thomas Gleixner wrote:
> > 
> > > Crap. Stop beating on those lost wakeup events. If we lose them then
> > > the drivers are broken and do not handle the switch over correctly. Or
> > > the suspend mechanism is broken as it does not evaluate the system
> > > state correctly. Blockers are just papering over that w/o tackling the
> > > real problem.
> > 
> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> Nonsense. The system state is well defined when a event is pending and
> we just have to say good bye to the idea that forced suspend is a good
> solution. It's not as it does not guarantee the event processing in
> badly written apps and it does move the power consumption to a later
> point in time for those apps which acquire/drop the blockers.

Well, now you have stated that Android actually doesn't work. :-)

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > and power management does the rest. If an event wakes up the process
> > before we get to suspend in kernel we will wake it back up.
> 
> Okay, and the kernel never suspends.  We _are_ talking about a kind of
> forced suspend, right?

No ? We are talking about just letting power management solve the whole
problem for us.

> >  If the event
> > gets in after pm decides to idle via suspend then it'll bounce through
> > the kernel back to a kernel resume,
> 
> No, it won't.  That's the problem suspend blockers were meant to solve.  
> The event winds up sitting in a kernel queue, the PM core doesn't know
> about it (that's what I meant above -- the PM core doesn't know as much
> as you seem to think it does), and the suspend takes place regardless.

No - because we are not forcing the suspend. The app must go idle. If you
force the suspend of running processes then yes the entire thing goes
castors up - which is why it's a bad idea to do so.

> > or potentially through a full
> > hardware/software suspend/resume bounce.
> 
> It would be okay if that happened.  But once the event gets into the
> kernel and the hardware IRQ source has turned off, there's nothing to
> cause the resume.

Read the discussion about how the race is avoided at the hardware level.
That race is I think not there and furthermore most drivers get it right
already.

There are several cases

1.	IRQ during app layer (ie policy in user space) asking
		applications to go passive

	- The event occurs, we undo the app layer policy, easy
	  (or app wakes process and we let it fall through)

2.	IRQ after the app layer quiesces its clients

	- The task wakes, the app layer won't see it - the app layer
	  allows suspend as an idle mode. Not a problem - the app is
	  running the cpu policy manager will see this and not suspend
	  until the app has been asleep for a bit. The app may well of
	  course tell the UI layer 'hey I want you back on' and it take
	  you back to the full on case.

3.	IRQ after kernel suspend begins

	- The driver will refuse the suspend, we don't suspend, we unwind
	  the resume so far, the app wakes, we propogate stuff back up to
	  user space whose policy manager unwinds its position

4.	IRQ after driver has done its final checks

	- Wake up lines are set
	- We suspend
	- We immediately get resumed
	- We follow the full resume path

This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > and power management does the rest. If an event wakes up the process
> > before we get to suspend in kernel we will wake it back up.
> 
> Okay, and the kernel never suspends.  We _are_ talking about a kind of
> forced suspend, right?

No ? We are talking about just letting power management solve the whole
problem for us.

> >  If the event
> > gets in after pm decides to idle via suspend then it'll bounce through
> > the kernel back to a kernel resume,
> 
> No, it won't.  That's the problem suspend blockers were meant to solve.  
> The event winds up sitting in a kernel queue, the PM core doesn't know
> about it (that's what I meant above -- the PM core doesn't know as much
> as you seem to think it does), and the suspend takes place regardless.

No - because we are not forcing the suspend. The app must go idle. If you
force the suspend of running processes then yes the entire thing goes
castors up - which is why it's a bad idea to do so.

> > or potentially through a full
> > hardware/software suspend/resume bounce.
> 
> It would be okay if that happened.  But once the event gets into the
> kernel and the hardware IRQ source has turned off, there's nothing to
> cause the resume.

Read the discussion about how the race is avoided at the hardware level.
That race is I think not there and furthermore most drivers get it right
already.

There are several cases

1.	IRQ during app layer (ie policy in user space) asking
		applications to go passive

	- The event occurs, we undo the app layer policy, easy
	  (or app wakes process and we let it fall through)

2.	IRQ after the app layer quiesces its clients

	- The task wakes, the app layer won't see it - the app layer
	  allows suspend as an idle mode. Not a problem - the app is
	  running the cpu policy manager will see this and not suspend
	  until the app has been asleep for a bit. The app may well of
	  course tell the UI layer 'hey I want you back on' and it take
	  you back to the full on case.

3.	IRQ after kernel suspend begins

	- The driver will refuse the suspend, we don't suspend, we unwind
	  the resume so far, the app wakes, we propogate stuff back up to
	  user space whose policy manager unwinds its position

4.	IRQ after driver has done its final checks

	- Wake up lines are set
	- We suspend
	- We immediately get resumed
	- We follow the full resume path

This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > and power management does the rest. If an event wakes up the process
> > before we get to suspend in kernel we will wake it back up.
> 
> Okay, and the kernel never suspends.  We _are_ talking about a kind of
> forced suspend, right?

No ? We are talking about just letting power management solve the whole
problem for us.

> >  If the event
> > gets in after pm decides to idle via suspend then it'll bounce through
> > the kernel back to a kernel resume,
> 
> No, it won't.  That's the problem suspend blockers were meant to solve.  
> The event winds up sitting in a kernel queue, the PM core doesn't know
> about it (that's what I meant above -- the PM core doesn't know as much
> as you seem to think it does), and the suspend takes place regardless.

No - because we are not forcing the suspend. The app must go idle. If you
force the suspend of running processes then yes the entire thing goes
castors up - which is why it's a bad idea to do so.

> > or potentially through a full
> > hardware/software suspend/resume bounce.
> 
> It would be okay if that happened.  But once the event gets into the
> kernel and the hardware IRQ source has turned off, there's nothing to
> cause the resume.

Read the discussion about how the race is avoided at the hardware level.
That race is I think not there and furthermore most drivers get it right
already.

There are several cases

1.	IRQ during app layer (ie policy in user space) asking
		applications to go passive

	- The event occurs, we undo the app layer policy, easy
	  (or app wakes process and we let it fall through)

2.	IRQ after the app layer quiesces its clients

	- The task wakes, the app layer won't see it - the app layer
	  allows suspend as an idle mode. Not a problem - the app is
	  running the cpu policy manager will see this and not suspend
	  until the app has been asleep for a bit. The app may well of
	  course tell the UI layer 'hey I want you back on' and it take
	  you back to the full on case.

3.	IRQ after kernel suspend begins

	- The driver will refuse the suspend, we don't suspend, we unwind
	  the resume so far, the app wakes, we propogate stuff back up to
	  user space whose policy manager unwinds its position

4.	IRQ after driver has done its final checks

	- Wake up lines are set
	- We suspend
	- We immediately get resumed
	- We follow the full resume path

This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 22:36:35 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > No it doesn't. The kernel continues executing anything that was on the 
> 
> Would you like to come and watch my laptop resume ? With printk's if you
> want. You appear at this point to be arguing that bumble bees can't
> fly, while watching one.

The kernel performs no explicit notification to userspace. With legacy 
graphics setups you'll get a VT switch, but X is entirely unaware that 
that's due to suspend and that's going away in any case. On a typical 
setup it's not even the kernel that does the VT switch to and from X - 
that's handled by a script that happens to be on the runqueue. So yeah, 
things kind of work as you suggest right now - but only by accident, not 
design. What you're describing requires a new interface to inform 
interested bits of userspace whenever you transition from your deep idle 
state into a less deep one.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 22:36:35 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > No it doesn't. The kernel continues executing anything that was on the 
> 
> Would you like to come and watch my laptop resume ? With printk's if you
> want. You appear at this point to be arguing that bumble bees can't
> fly, while watching one.

The kernel performs no explicit notification to userspace. With legacy 
graphics setups you'll get a VT switch, but X is entirely unaware that 
that's due to suspend and that's going away in any case. On a typical 
setup it's not even the kernel that does the VT switch to and from X - 
that's handled by a script that happens to be on the runqueue. So yeah, 
things kind of work as you suggest right now - but only by accident, not 
design. What you're describing requires a new interface to inform 
interested bits of userspace whenever you transition from your deep idle 
state into a less deep one.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:

> This is I believe robust (and has been implemented on some non x86
> boxes). It depends on not forcing running tasks into suspend. That is the
> key.

We've already established that ACPI systems require us to force running 
tasks into suspend. How do we avoid the race in that situation?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:

> This is I believe robust (and has been implemented on some non x86
> boxes). It depends on not forcing running tasks into suspend. That is the
> key.

We've already established that ACPI systems require us to force running 
tasks into suspend. How do we avoid the race in that situation?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:55:13 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Thursday 27 May 2010, Alan Cox wrote:
> > > > If one works so does the other.
> > > 
> > > Not at all. The entire point of opportunistic suspend is that I don't 
> > > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > > in 100msec - based on policy (through not having any held suspend 
> > > blockers), I'll go to sleep. That's easily possible on PCs.
> > 
> > Yes I appreciate what suspend blockers are trying to do. Now how does
> > that connect with my first sentence ?
> 
> I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
> a very deep CPU idle state, because of the way wakeup sources are set up
> for it, while you could use it for aggressive power management with suspend
> blockers as proposed by Arve.

Which is a nonsense. Because the entire Gnome desktop and KDE, and
OpenOffice and Firefox and friends would need fitting out with
suspend blockers.

x86 hardware is moving to fix these problems (at least on handheld
devices initially). Look up the C6 power idle, and S0i1 and S0i3
standby states. I reckon the laptop folks can probably get the hardware
fixed well before anyone can convert the entire PC desktop to include
blockers.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:55:13 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Thursday 27 May 2010, Alan Cox wrote:
> > > > If one works so does the other.
> > > 
> > > Not at all. The entire point of opportunistic suspend is that I don't 
> > > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > > in 100msec - based on policy (through not having any held suspend 
> > > blockers), I'll go to sleep. That's easily possible on PCs.
> > 
> > Yes I appreciate what suspend blockers are trying to do. Now how does
> > that connect with my first sentence ?
> 
> I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
> a very deep CPU idle state, because of the way wakeup sources are set up
> for it, while you could use it for aggressive power management with suspend
> blockers as proposed by Arve.

Which is a nonsense. Because the entire Gnome desktop and KDE, and
OpenOffice and Firefox and friends would need fitting out with
suspend blockers.

x86 hardware is moving to fix these problems (at least on handheld
devices initially). Look up the C6 power idle, and S0i1 and S0i3
standby states. I reckon the laptop folks can probably get the hardware
fixed well before anyone can convert the entire PC desktop to include
blockers.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> 
> > This is I believe robust (and has been implemented on some non x86
> > boxes). It depends on not forcing running tasks into suspend. That is the
> > key.
> 
> We've already established that ACPI systems require us to force running 
> tasks into suspend. How do we avoid the race in that situation?

Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
x86 devices do not have ACPI.

I would imagine the existing laptops will handle power management limited
by the functionality they have available. Just like any other piece of
hardware.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> 
> > This is I believe robust (and has been implemented on some non x86
> > boxes). It depends on not forcing running tasks into suspend. That is the
> > key.
> 
> We've already established that ACPI systems require us to force running 
> tasks into suspend. How do we avoid the race in that situation?

Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
x86 devices do not have ACPI.

I would imagine the existing laptops will handle power management limited
by the functionality they have available. Just like any other piece of
hardware.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The kernel performs no explicit notification to userspace. With legacy 

For a PC ACPI using type device /proc/acpi/events which wakes acpid which
wakes gnome-power-manager which wakes half the universe

Do we need a better more generic version of the events files - maybe but
thats a rather different kettle of fish to suspend blockers.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The kernel performs no explicit notification to userspace. With legacy 

For a PC ACPI using type device /proc/acpi/events which wakes acpid which
wakes gnome-power-manager which wakes half the universe

Do we need a better more generic version of the events files - maybe but
thats a rather different kettle of fish to suspend blockers.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:32:47PM +0100, Alan Cox wrote:
> > The kernel performs no explicit notification to userspace. With legacy 
> 
> For a PC ACPI using type device /proc/acpi/events which wakes acpid which
> wakes gnome-power-manager which wakes half the universe

No, there's no explicit /proc/acpi/event notification on resume.

> Do we need a better more generic version of the events files - maybe but
> thats a rather different kettle of fish to suspend blockers.

It's a requirement for any reasonable alternative approach.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:32:47PM +0100, Alan Cox wrote:
> > The kernel performs no explicit notification to userspace. With legacy 
> 
> For a PC ACPI using type device /proc/acpi/events which wakes acpid which
> wakes gnome-power-manager which wakes half the universe

No, there's no explicit /proc/acpi/event notification on resume.

> Do we need a better more generic version of the events files - maybe but
> thats a rather different kettle of fish to suspend blockers.

It's a requirement for any reasonable alternative approach.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 23:09:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> > 
> > > This is I believe robust (and has been implemented on some non x86
> > > boxes). It depends on not forcing running tasks into suspend. That is the
> > > key.
> > 
> > We've already established that ACPI systems require us to force running 
> > tasks into suspend. How do we avoid the race in that situation?
> 
> Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> x86 devices do not have ACPI.

It doesn't matter. Right now there's a race condition in terms of 
wakeup events on ACPI systems. What's your proposal for fixing that?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 23:09:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> > 
> > > This is I believe robust (and has been implemented on some non x86
> > > boxes). It depends on not forcing running tasks into suspend. That is the
> > > key.
> > 
> > We've already established that ACPI systems require us to force running 
> > tasks into suspend. How do we avoid the race in that situation?
> 
> Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> x86 devices do not have ACPI.

It doesn't matter. Right now there's a race condition in terms of 
wakeup events on ACPI systems. What's your proposal for fixing that?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > > 
> > > _WHY_!?
> > 
> > Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> > key, I need to go to sleep. Blocking processes on driver access isn't 
> > sufficient.
> 
> But that's a whole different issue. I agree that a forced suspend for
> things like that make sense, just not for power managing a running
> system. PC style hardware like that doesn't wake up from suspend for
> funny things like a keypress either (good thing too).

In fact one of my PC test boxes does that. :-)

> Anyway all that already works (more or less), so I don't see the
> problem.

The whole idea behind the patchset is not to power manage a _running_ system.
It is based on the observation that for a good deal of time one doesn't need
the system to be running at all, which is quite pragmatic to me.  Given that,
the point is to figure out when the system doesn't need to run and effectively
shut it down at that point (memory is refreshed in that state so that the
system can go back to the working state relatively quickly).  From there, the
system can only be woken up by specific events (like pressing a power button).
However, it would be wasteful to shut it down knowing that the condition used
to make the decision to shut it down didn't hold any more.

The current mainline relies on the user to make that decision (and write
something to /sys/power/state), but in principle I don't see why it cannot be
made by software (either the kernel or the user space, or both in combination).
The question is how to "teach" the software to make that decision in a way
that's acceptable to the user and the Arve's approach is an attempt to give
an answer to it.

Of course, you may not like it, but the truth is it works in practice
reasonably well.  That may not be an argument for merging it, but then we
should at least tell the Android people what's fundamentally wrong with it
and how to do it in a different way so that their own requirements are met.

As long as we don't do that, we're rejecting it just because we don't like it.

Yes, Alan Cox said why he thought the approach was fundamentally wrong from
the technical standpoint and I appreciate that.  I don't think, though, that we
can give Google a serious advice how to achieve their goal (which is battery
life comparable to what they get with suspend blockers) in any different way.

The approach with user space power manager suggested by Dmitry and Alan Stern
may work, but it still assumes some kind of suspend blockers to be present in
the kernel.  If we reject that too, I wonder what approach Google is supposed
to use and still get the same battery life they get with suspend blockers.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > > 
> > > _WHY_!?
> > 
> > Because if I'm running a kernel build in a tmpfs and I hit the sleep 
> > key, I need to go to sleep. Blocking processes on driver access isn't 
> > sufficient.
> 
> But that's a whole different issue. I agree that a forced suspend for
> things like that make sense, just not for power managing a running
> system. PC style hardware like that doesn't wake up from suspend for
> funny things like a keypress either (good thing too).

In fact one of my PC test boxes does that. :-)

> Anyway all that already works (more or less), so I don't see the
> problem.

The whole idea behind the patchset is not to power manage a _running_ system.
It is based on the observation that for a good deal of time one doesn't need
the system to be running at all, which is quite pragmatic to me.  Given that,
the point is to figure out when the system doesn't need to run and effectively
shut it down at that point (memory is refreshed in that state so that the
system can go back to the working state relatively quickly).  From there, the
system can only be woken up by specific events (like pressing a power button).
However, it would be wasteful to shut it down knowing that the condition used
to make the decision to shut it down didn't hold any more.

The current mainline relies on the user to make that decision (and write
something to /sys/power/state), but in principle I don't see why it cannot be
made by software (either the kernel or the user space, or both in combination).
The question is how to "teach" the software to make that decision in a way
that's acceptable to the user and the Arve's approach is an attempt to give
an answer to it.

Of course, you may not like it, but the truth is it works in practice
reasonably well.  That may not be an argument for merging it, but then we
should at least tell the Android people what's fundamentally wrong with it
and how to do it in a different way so that their own requirements are met.

As long as we don't do that, we're rejecting it just because we don't like it.

Yes, Alan Cox said why he thought the approach was fundamentally wrong from
the technical standpoint and I appreciate that.  I don't think, though, that we
can give Google a serious advice how to achieve their goal (which is battery
life comparable to what they get with suspend blockers) in any different way.

The approach with user space power manager suggested by Dmitry and Alan Stern
may work, but it still assumes some kind of suspend blockers to be present in
the kernel.  If we reject that too, I wonder what approach Google is supposed
to use and still get the same battery life they get with suspend blockers.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
> 
> > I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> > the current operator ordered suspend behaviour I believe ?
> 
> No. The current mechanism can lose wakeup events.

As long as the operator agrees to lose wakeup events occasionally, which is
the case at least 99% of the time, there's nothing wrong with that IMO.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
> 
> > I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> > the current operator ordered suspend behaviour I believe ?
> 
> No. The current mechanism can lose wakeup events.

As long as the operator agrees to lose wakeup events occasionally, which is
the case at least 99% of the time, there's nothing wrong with that IMO.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:36:05 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > 
> > > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> > > 
> > > > This is I believe robust (and has been implemented on some non x86
> > > > boxes). It depends on not forcing running tasks into suspend. That is the
> > > > key.
> > > 
> > > We've already established that ACPI systems require us to force running 
> > > tasks into suspend. How do we avoid the race in that situation?
> > 
> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> > x86 devices do not have ACPI.
> 
> It doesn't matter. Right now there's a race condition in terms of 
> wakeup events on ACPI systems. What's your proposal for fixing that?

I see it as a different problem  - and one that seems to be minimally
pressing to most users jduging by the amount of noise it hasn't caused in
the past seven odd years.

This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.

I am interested right now in finding a general solution to the Android
case and the fact it looks very similar to the VM, hard RT, gamer and
other related problems although we seem to have diverged from that logic.

I dont think it particularly useful to go off on a mostly unrelated wild
goose chase into ACPI land, especially one based on a premise of changing
all the apps when the hardware will end up fixed faster.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Thu, 27 May 2010 23:36:05 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > 
> > > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> > > 
> > > > This is I believe robust (and has been implemented on some non x86
> > > > boxes). It depends on not forcing running tasks into suspend. That is the
> > > > key.
> > > 
> > > We've already established that ACPI systems require us to force running 
> > > tasks into suspend. How do we avoid the race in that situation?
> > 
> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> > x86 devices do not have ACPI.
> 
> It doesn't matter. Right now there's a race condition in terms of 
> wakeup events on ACPI systems. What's your proposal for fixing that?

I see it as a different problem  - and one that seems to be minimally
pressing to most users jduging by the amount of noise it hasn't caused in
the past seven odd years.

This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.

I am interested right now in finding a general solution to the Android
case and the fact it looks very similar to the VM, hard RT, gamer and
other related problems although we seem to have diverged from that logic.

I dont think it particularly useful to go off on a mostly unrelated wild
goose chase into ACPI land, especially one based on a premise of changing
all the apps when the hardware will end up fixed faster.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

Matthew:

Remind me why the idle/QOS power management approach won't work here.

If the difficulty is untrusted apps preventing the system from being
idle, why not assign them to QoS(NONE) as Thomas suggested?

If the difficulty is that some untrusted apps need to receive wakeup 
events, why not just decree that this is not allowed?  It seems 
reasonable that if you can't trust a program then you shouldn't allow 
it to wake up the system.

If the difficulty is that some trusted apps need to do CPU-burning
things like drawing bouncing cows in the background, why not break
these apps into two processes or threads?  One can be trusted and
receive all the wakeup events, and the other can be untrusted and draw
all the cows it likes.  We're only talking about trusted apps, most of
which would be controlled by Google, so the conversion shouldn't be too
hard.

If the difficulty is that ACPI-based systems can't use idle/QOS PM
effectively...  well, so be it.  We don't have to solve every problem
in the world right away, and just now we're mainly concerned about
helping the Android people.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

Matthew:

Remind me why the idle/QOS power management approach won't work here.

If the difficulty is untrusted apps preventing the system from being
idle, why not assign them to QoS(NONE) as Thomas suggested?

If the difficulty is that some untrusted apps need to receive wakeup 
events, why not just decree that this is not allowed?  It seems 
reasonable that if you can't trust a program then you shouldn't allow 
it to wake up the system.

If the difficulty is that some trusted apps need to do CPU-burning
things like drawing bouncing cows in the background, why not break
these apps into two processes or threads?  One can be trusted and
receive all the wakeup events, and the other can be untrusted and draw
all the cows it likes.  We're only talking about trusted apps, most of
which would be controlled by Google, so the conversion shouldn't be too
hard.

If the difficulty is that ACPI-based systems can't use idle/QOS PM
effectively...  well, so be it.  We don't have to solve every problem
in the world right away, and just now we're mainly concerned about
helping the Android people.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

Matthew:

Remind me why the idle/QOS power management approach won't work here.

If the difficulty is untrusted apps preventing the system from being
idle, why not assign them to QoS(NONE) as Thomas suggested?

If the difficulty is that some untrusted apps need to receive wakeup 
events, why not just decree that this is not allowed?  It seems 
reasonable that if you can't trust a program then you shouldn't allow 
it to wake up the system.

If the difficulty is that some trusted apps need to do CPU-burning
things like drawing bouncing cows in the background, why not break
these apps into two processes or threads?  One can be trusted and
receive all the wakeup events, and the other can be untrusted and draw
all the cows it likes.  We're only talking about trusted apps, most of
which would be controlled by Google, so the conversion shouldn't be too
hard.

If the difficulty is that ACPI-based systems can't use idle/QOS PM
effectively...  well, so be it.  We don't have to solve every problem
in the world right away, and just now we're mainly concerned about
helping the Android people.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
> 
> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).
> 
> So your position would seem to be "we have a race but can debate how big
> is permissible"
> 
> The usual model is
> 
> "At no point should we be in a position when entering a suspend style
>  deep sleep where we neither abort the suspend, nor commit to a
>  suspend/resume sequence if the events we care about occur"
> 
> and that is why the hardware model is
> 
> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

That's correct, but to me the Arve's goal is simply to maximize battery life
and he found experimentally that the longest battery life is achieved if
system suspend is used whenever the system doesn't need to be active (from its
user's perspective).  This actually is different from "when the system is
idle", because the system isn't idle, for example, when updatedb is running.
However, from the user's perspective the updatedb process doesn't really need
to run at this particular time, it can very well do it's job in parallel with
the user typing or reading news.  So, the system may very well be suspended
when updatedb is running.

Now, "when the system doesn't need to be active" is not a very precise
statement, so the Android people attempted to develop a mechanism allowing
them to specify what that means more precisely.  It works for them, it need not
work for everyone, though.  Of course, we can dismiss it as "crap", "broken
design", whatever, but then we need to give them a clear advice what to do
to achieve the same goal (maximum battery life) in a different way that would
be more acceptable to us.

Since I think we've now rejected the feature, do we have a clear picture about
what the Android people should do _instead_ and yet keep the battery life they
want?  Because I don't think telling "let them do what they want, who cares"
is right.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it 
> 
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
> 
> > may also be in response to a 30 minute timeout expiring. If I get a WoL 
> > packet in the 0.5 of a second between userspace deciding to suspend and 
> > actually doing so, the system shouldn't suspend.
> 
> I don't think that argument holds water in the form you have it
> 
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).
> 
> So your position would seem to be "we have a race but can debate how big
> is permissible"
> 
> The usual model is
> 
> "At no point should we be in a position when entering a suspend style
>  deep sleep where we neither abort the suspend, nor commit to a
>  suspend/resume sequence if the events we care about occur"
> 
> and that is why the hardware model is
> 
> 	Set wake flags
> 	Check if idle
> 	If idle
> 		Suspend
> 	else
> 		Clear wake flags
> 		Unwind
> 
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

That's correct, but to me the Arve's goal is simply to maximize battery life
and he found experimentally that the longest battery life is achieved if
system suspend is used whenever the system doesn't need to be active (from its
user's perspective).  This actually is different from "when the system is
idle", because the system isn't idle, for example, when updatedb is running.
However, from the user's perspective the updatedb process doesn't really need
to run at this particular time, it can very well do it's job in parallel with
the user typing or reading news.  So, the system may very well be suspended
when updatedb is running.

Now, "when the system doesn't need to be active" is not a very precise
statement, so the Android people attempted to develop a mechanism allowing
them to specify what that means more precisely.  It works for them, it need not
work for everyone, though.  Of course, we can dismiss it as "crap", "broken
design", whatever, but then we need to give them a clear advice what to do
to achieve the same goal (maximum battery life) in a different way that would
be more acceptable to us.

Since I think we've now rejected the feature, do we have a clear picture about
what the Android people should do _instead_ and yet keep the battery life they
want?  Because I don't think telling "let them do what they want, who cares"
is right.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The approach with user space power manager suggested by Dmitry and Alan Stern
> may work, but it still assumes some kind of suspend blockers to be present in
> the kernel.  If we reject that too, I wonder what approach Google is supposed
> to use and still get the same battery life they get with suspend blockers.

I'm getting less convinced it needs suspend blockers at all for this case,
assuming that you are willing to have a policy that is based on

- assuming apps play nicely
- having the information to user space you need (who woke us, who blocked
  us, events)
- dealing with offenders primarily from user space using that information

I'm fairly happy about the following so far

- we should have a common interface for seeing some pm events (like
  duh ?) but it does need careful thought so the watcher doesn't change
  the behaviour and break it. (Message "We are suspending", gosh someone
  is running to receive the message, resume being the obvious case)

- Suspend is (for many platforms) just a cotinuation down the power
  chain. Demonstrated and implemented on ARM. Very much the direction of
  S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
  made to work, and by reading the Moorestown PR.

- Given a non forced (that is 'idle down') transition to a suspend level
  we can implement a 'suspend as idle' on many embedded platforms in a
  manner which is not racy at kernel level. Apparently implemented
  already on ARM

- Given a non forced transition to such a suspend level and the reporting
  of certain events we can do a full user space managed graphical UI type
  environment policy in a race free fashion

- With notification of who caused a resume and maybe a bit of other
  general stat gathering it is possible to identify and handle abuses of
  power resource. Proved by the fact we can do this with powertop but
  more elegance in the interfaces would be nice.

I am not sure if a pm event is what is needed for this or a sum 'hardware
triggered wake up' event.

I accept that current ACPI based laptops probably couldn't make use of
such a feature but I don't think this is important at the moment.

A resource constraint model might help further in the ACPI case. It's
useful for other stuff but it might well be a distraction and
implementation detail in terms of the basic question about what is needed
for something like Android.

At this point the input of the Android team and the Nokia people would
be rather more useful to me.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The approach with user space power manager suggested by Dmitry and Alan Stern
> may work, but it still assumes some kind of suspend blockers to be present in
> the kernel.  If we reject that too, I wonder what approach Google is supposed
> to use and still get the same battery life they get with suspend blockers.

I'm getting less convinced it needs suspend blockers at all for this case,
assuming that you are willing to have a policy that is based on

- assuming apps play nicely
- having the information to user space you need (who woke us, who blocked
  us, events)
- dealing with offenders primarily from user space using that information

I'm fairly happy about the following so far

- we should have a common interface for seeing some pm events (like
  duh ?) but it does need careful thought so the watcher doesn't change
  the behaviour and break it. (Message "We are suspending", gosh someone
  is running to receive the message, resume being the obvious case)

- Suspend is (for many platforms) just a cotinuation down the power
  chain. Demonstrated and implemented on ARM. Very much the direction of
  S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
  made to work, and by reading the Moorestown PR.

- Given a non forced (that is 'idle down') transition to a suspend level
  we can implement a 'suspend as idle' on many embedded platforms in a
  manner which is not racy at kernel level. Apparently implemented
  already on ARM

- Given a non forced transition to such a suspend level and the reporting
  of certain events we can do a full user space managed graphical UI type
  environment policy in a race free fashion

- With notification of who caused a resume and maybe a bit of other
  general stat gathering it is possible to identify and handle abuses of
  power resource. Proved by the fact we can do this with powertop but
  more elegance in the interfaces would be nice.

I am not sure if a pm event is what is needed for this or a sum 'hardware
triggered wake up' event.

I accept that current ACPI based laptops probably couldn't make use of
such a feature but I don't think this is important at the moment.

A resource constraint model might help further in the ACPI case. It's
useful for other stuff but it might well be a distraction and
implementation detail in terms of the basic question about what is needed
for something like Android.

At this point the input of the Android team and the Nokia people would
be rather more useful to me.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Alan Cox wrote:
> 
> > > Rather than continue going around in circles, let's agree that what the 
> > > Android people want is a new version of forced suspend -- not a 
> > 
> > I don't think this is true. I think that is the root of the problem.
> 
> Of course it's true.  Just ask Arve -- he wants opportunistic suspend 
> and it _is_ a variant of forced suspend.  Ergo he wants a new type of 
> forced suspend.

Well, as I just wrote in a different message, what he _really_ wants is to
get maximum possible battery life and he found experimentally that this is
achieved by suspending the whole system as often as reasonably possible.

Of course, the "reasonably possible" part needs clarification.

> Maybe that's not what he _ought_ to want.  Nevertheless, there are 
> valid reasons for wanting it.
> 
> > I don't disagree with the user experience they are trying to create or
> > the fact something is needed to make it possible (if it turns out we
> > can't already do it).
> > 
> > Forced suspend is sticking stuff in running state into suspend
> > 
> > Power management models (such as Thomas ARM box) which we know work are
> > 'when nothing is running' into suspend.
> > 
> > So for me the real question on that side of this specific case is 'how
> > do you make sure those tasks are idle when you need them to be'
> > 
> > QoS ?
> > Spanking them from user space ?
> > Drivers enforcing policy elements by blocking tasks ?
> 
> Currently we use the freezer.  But it is a blunt tool -- it freezes 
> every user process.  Also, it doesn't actually make processes 
> unrunnable; it just arranges things so that when they do run, they 
> immediately put themselves back to sleep.
> 
> And the forced-suspend design relies on the fact that processes remain 
> frozen throughout.  If we leave some processes unfrozen and one of them 
> somehow becomes runnable, that means we have to abort the forced 
> suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to
answer.  First off, how a driver is supposed to know when to block the task
using it and when to do its power management transparently for the task?
Second, how to intercept and block all possible interfaces that user space
can use to talk to drivers (how to intercept a task using mmapped device, for
example)?

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Alan Cox wrote:
> 
> > > Rather than continue going around in circles, let's agree that what the 
> > > Android people want is a new version of forced suspend -- not a 
> > 
> > I don't think this is true. I think that is the root of the problem.
> 
> Of course it's true.  Just ask Arve -- he wants opportunistic suspend 
> and it _is_ a variant of forced suspend.  Ergo he wants a new type of 
> forced suspend.

Well, as I just wrote in a different message, what he _really_ wants is to
get maximum possible battery life and he found experimentally that this is
achieved by suspending the whole system as often as reasonably possible.

Of course, the "reasonably possible" part needs clarification.

> Maybe that's not what he _ought_ to want.  Nevertheless, there are 
> valid reasons for wanting it.
> 
> > I don't disagree with the user experience they are trying to create or
> > the fact something is needed to make it possible (if it turns out we
> > can't already do it).
> > 
> > Forced suspend is sticking stuff in running state into suspend
> > 
> > Power management models (such as Thomas ARM box) which we know work are
> > 'when nothing is running' into suspend.
> > 
> > So for me the real question on that side of this specific case is 'how
> > do you make sure those tasks are idle when you need them to be'
> > 
> > QoS ?
> > Spanking them from user space ?
> > Drivers enforcing policy elements by blocking tasks ?
> 
> Currently we use the freezer.  But it is a blunt tool -- it freezes 
> every user process.  Also, it doesn't actually make processes 
> unrunnable; it just arranges things so that when they do run, they 
> immediately put themselves back to sleep.
> 
> And the forced-suspend design relies on the fact that processes remain 
> frozen throughout.  If we leave some processes unfrozen and one of them 
> somehow becomes runnable, that means we have to abort the forced 
> suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to
answer.  First off, how a driver is supposed to know when to block the task
using it and when to do its power management transparently for the task?
Second, how to intercept and block all possible interfaces that user space
can use to talk to drivers (how to intercept a task using mmapped device, for
example)?

Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
>> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> >> > opportunistic suspend, and a wakeup event occurs but no suspend
>> >> > blockers get enabled by the handler, what causes the system to go back
>> >> > into suspend after the event is handled?  Isn't that a loop of some
>> >> > sort?
>> >> >
>> >>
>> >> Yes it is a loop. I think what you are missing is that it only loops
>> >> repeatedly if the driver that aborts suspend does not use a suspend
>> >> blocker.
>> >
>> > You mean "the driver that handles the wakeup event".  I was asking what
>> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
>> > a suspend blocker is used then its release causes another suspend
>> > attempt, with no looping.
>> >
>> >> > And even if it isn't, so what?  What's wrong with looping behavior?
>> >>
>> >> It is a significant power drain.
>> >
>> > Not in the situation I was discussing.
>> >
>>
>> If you meant it spend most of the time suspended, then I agree. It
>> only wastes power when a driver blocks suspend by returning an error
>> from its suspend hook and we are forced to loop doing no useful work.
>>
>
> If driver refuses to suspend that means there are events that need
> processing. I fail to see why it would be called "looping doing no
> useful work".

Because the useful work is done in another thread. All the loop does
is check if the useful work has completed which most likely will slow
down the useful work. Blocking suspend with a suspend blocker until
the useful work is done is more efficient.

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
>> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> >> > opportunistic suspend, and a wakeup event occurs but no suspend
>> >> > blockers get enabled by the handler, what causes the system to go back
>> >> > into suspend after the event is handled?  Isn't that a loop of some
>> >> > sort?
>> >> >
>> >>
>> >> Yes it is a loop. I think what you are missing is that it only loops
>> >> repeatedly if the driver that aborts suspend does not use a suspend
>> >> blocker.
>> >
>> > You mean "the driver that handles the wakeup event".  I was asking what
>> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
>> > a suspend blocker is used then its release causes another suspend
>> > attempt, with no looping.
>> >
>> >> > And even if it isn't, so what?  What's wrong with looping behavior?
>> >>
>> >> It is a significant power drain.
>> >
>> > Not in the situation I was discussing.
>> >
>>
>> If you meant it spend most of the time suspended, then I agree. It
>> only wastes power when a driver blocks suspend by returning an error
>> from its suspend hook and we are forced to loop doing no useful work.
>>
>
> If driver refuses to suspend that means there are events that need
> processing. I fail to see why it would be called "looping doing no
> useful work".

Because the useful work is done in another thread. All the loop does
is check if the useful work has completed which most likely will slow
down the useful work. Blocking suspend with a suspend blocker until
the useful work is done is more efficient.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> - Given a non forced (that is 'idle down') transition to a suspend level
>   we can implement a 'suspend as idle' on many embedded platforms in a
>   manner which is not racy at kernel level. Apparently implemented
>   already on ARM

Just to confirm, yes, it is already implemeted on ARM, and in mainline
for the TI OMAP3 (ARM Cortex-A8) and in commercial products (Nokia
N900, Moto Droid, Palm Pre, Archos, etc.)  For the OMAP the deepest
C-state is actually a fully powered-down ARM core.

While the Droid uses 'suspend as idle' in addition to opportunistic
suspend, the N900 *never* suspends in the traditional sense, it is
entirely idle based.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> - Given a non forced (that is 'idle down') transition to a suspend level
>   we can implement a 'suspend as idle' on many embedded platforms in a
>   manner which is not racy at kernel level. Apparently implemented
>   already on ARM

Just to confirm, yes, it is already implemeted on ARM, and in mainline
for the TI OMAP3 (ARM Cortex-A8) and in commercial products (Nokia
N900, Moto Droid, Palm Pre, Archos, etc.)  For the OMAP the deepest
C-state is actually a fully powered-down ARM core.

While the Droid uses 'suspend as idle' in addition to opportunistic
suspend, the N900 *never* suspends in the traditional sense, it is
entirely idle based.

Kevin

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> 
> > On Thursday 27 May 2010, Thomas Gleixner wrote:
> > > On Thu, 27 May 2010, Alan Stern wrote:
> > > 
> > > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > > 
> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > > >If people don't mind, here is a greatly simplified summary of the
> > > > > >comments and objections I have seen so far on this thread:
> > > > > >
> > > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > > >	beneficial.
> > > > > 
> > > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > > the kernel decide which power state is better as long as I can say I 
> > > > > need 100us IRQ latency or 100ms wakeup latency.
> > > > 
> > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > 
> > > mem should be replaced by an idle suspend to ram mechanism
> > 
> > Well, what about when I want the machine to suspend _regardless_ of whether
> > or not it's idle at the moment?  That actually happens quite often to me. :-)
> 
> Fair enough. Let's agree on a non ambigous terminology then:
> 
>      forced:
> 
> 	     suspend which you enforce via user interaction, which
>      	     also implies that you risk losing wakeups depending on
>      	     the hardware properties

OK

>      opportunistic:
> 
> 	     suspend driven from the idle context, which guarantees to
> 	     not lose wakeups. Provided only when the hardware does
> 	     provide the necessary capabilities.

I can accept that definition, but this is not what "opportunistic" means in the
Arve's changelogs.  What it means there is that he wants the system to suspend
even when it is not technically idle (like in the updatedb example I gave in a
previous message).  Suspend blockers are supposed to be a mechanism by which
the kernel and user space together may determine when to suspend (and it's
somewhat orthogonal to idle).

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Thursday 27 May 2010, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> 
> > On Thursday 27 May 2010, Thomas Gleixner wrote:
> > > On Thu, 27 May 2010, Alan Stern wrote:
> > > 
> > > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > > 
> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > > >If people don't mind, here is a greatly simplified summary of the
> > > > > >comments and objections I have seen so far on this thread:
> > > > > >
> > > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > > >	beneficial.
> > > > > 
> > > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > > the kernel decide which power state is better as long as I can say I 
> > > > > need 100us IRQ latency or 100ms wakeup latency.
> > > > 
> > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > 
> > > mem should be replaced by an idle suspend to ram mechanism
> > 
> > Well, what about when I want the machine to suspend _regardless_ of whether
> > or not it's idle at the moment?  That actually happens quite often to me. :-)
> 
> Fair enough. Let's agree on a non ambigous terminology then:
> 
>      forced:
> 
> 	     suspend which you enforce via user interaction, which
>      	     also implies that you risk losing wakeups depending on
>      	     the hardware properties

OK

>      opportunistic:
> 
> 	     suspend driven from the idle context, which guarantees to
> 	     not lose wakeups. Provided only when the hardware does
> 	     provide the necessary capabilities.

I can accept that definition, but this is not what "opportunistic" means in the
Arve's changelogs.  What it means there is that he wants the system to suspend
even when it is not technically idle (like in the updatedb example I gave in a
previous message).  Suspend blockers are supposed to be a mechanism by which
the kernel and user space together may determine when to suspend (and it's
somewhat orthogonal to idle).

Thanks,
Rafael

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hjønnevåg wrote:
> 2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> >> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> >> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> >> >
> >> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend
> >> >> > blockers get enabled by the handler, what causes the system to go back
> >> >> > into suspend after the event is handled?  Isn't that a loop of some
> >> >> > sort?
> >> >> >
> >> >>
> >> >> Yes it is a loop. I think what you are missing is that it only loops
> >> >> repeatedly if the driver that aborts suspend does not use a suspend
> >> >> blocker.
> >> >
> >> > You mean "the driver that handles the wakeup event".  I was asking what
> >> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> >> > a suspend blocker is used then its release causes another suspend
> >> > attempt, with no looping.
> >> >
> >> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >> >>
> >> >> It is a significant power drain.
> >> >
> >> > Not in the situation I was discussing.
> >> >
> >>
> >> If you meant it spend most of the time suspended, then I agree. It
> >> only wastes power when a driver blocks suspend by returning an error
> >> from its suspend hook and we are forced to loop doing no useful work.
> >>
> >
> > If driver refuses to suspend that means there are events that need
> > processing. I fail to see why it would be called "looping doing no
> > useful work".
> 
> Because the useful work is done in another thread. All the loop does
> is check if the useful work has completed which most likely will slow
> down the useful work.

Or useful work could signal when it is done processing critical section.

> Blocking suspend with a suspend blocker until
> the useful work is done is more efficient.
> 

-- 
Dmitry

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Dmitry Torokhov]

On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hjønnevåg wrote:
> 2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
> >> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
> >> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> >> >
> >> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend
> >> >> > blockers get enabled by the handler, what causes the system to go back
> >> >> > into suspend after the event is handled?  Isn't that a loop of some
> >> >> > sort?
> >> >> >
> >> >>
> >> >> Yes it is a loop. I think what you are missing is that it only loops
> >> >> repeatedly if the driver that aborts suspend does not use a suspend
> >> >> blocker.
> >> >
> >> > You mean "the driver that handles the wakeup event".  I was asking what
> >> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
> >> > a suspend blocker is used then its release causes another suspend
> >> > attempt, with no looping.
> >> >
> >> >> > And even if it isn't, so what?  What's wrong with looping behavior?
> >> >>
> >> >> It is a significant power drain.
> >> >
> >> > Not in the situation I was discussing.
> >> >
> >>
> >> If you meant it spend most of the time suspended, then I agree. It
> >> only wastes power when a driver blocks suspend by returning an error
> >> from its suspend hook and we are forced to loop doing no useful work.
> >>
> >
> > If driver refuses to suspend that means there are events that need
> > processing. I fail to see why it would be called "looping doing no
> > useful work".
> 
> Because the useful work is done in another thread. All the loop does
> is check if the useful work has completed which most likely will slow
> down the useful work.

Or useful work could signal when it is done processing critical section.

> Blocking suspend with a suspend blocker until
> the useful work is done is more efficient.
> 

-- 
Dmitry

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> On Thu, 27 May 2010 23:55:13 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Thursday 27 May 2010, Alan Cox wrote:
> > > > > If one works so does the other.
> > > > 
> > > > Not at all. The entire point of opportunistic suspend is that I don't 
> > > > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > > > in 100msec - based on policy (through not having any held suspend 
> > > > blockers), I'll go to sleep. That's easily possible on PCs.
> > > 
> > > Yes I appreciate what suspend blockers are trying to do. Now how does
> > > that connect with my first sentence ?
> > 
> > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
> > a very deep CPU idle state, because of the way wakeup sources are set up
> > for it, while you could use it for aggressive power management with suspend
> > blockers as proposed by Arve.
> 
> Which is a nonsense. Because the entire Gnome desktop and KDE, and
> OpenOffice and Firefox and friends would need fitting out with
> suspend blockers.
> 
> x86 hardware is moving to fix these problems (at least on handheld
> devices initially). Look up the C6 power idle, and S0i1 and S0i3
> standby states. I reckon the laptop folks can probably get the hardware
> fixed well before anyone can convert the entire PC desktop to include
> blockers.

To clarify, I'm not suggesting to spread suspend blockers all over the
universe.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> On Thu, 27 May 2010 23:55:13 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Thursday 27 May 2010, Alan Cox wrote:
> > > > > If one works so does the other.
> > > > 
> > > > Not at all. The entire point of opportunistic suspend is that I don't 
> > > > care is currently in TASK_RUNNABLE or has a timer that's due to expire 
> > > > in 100msec - based on policy (through not having any held suspend 
> > > > blockers), I'll go to sleep. That's easily possible on PCs.
> > > 
> > > Yes I appreciate what suspend blockers are trying to do. Now how does
> > > that connect with my first sentence ?
> > 
> > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as
> > a very deep CPU idle state, because of the way wakeup sources are set up
> > for it, while you could use it for aggressive power management with suspend
> > blockers as proposed by Arve.
> 
> Which is a nonsense. Because the entire Gnome desktop and KDE, and
> OpenOffice and Firefox and friends would need fitting out with
> suspend blockers.
> 
> x86 hardware is moving to fix these problems (at least on handheld
> devices initially). Look up the C6 power idle, and S0i1 and S0i3
> standby states. I reckon the laptop folks can probably get the hardware
> fixed well before anyone can convert the entire PC desktop to include
> blockers.

To clarify, I'm not suggesting to spread suspend blockers all over the
universe.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday 27 May 2010, Thomas Gleixner wrote:
>> On Thu, 27 May 2010, Rafael J. Wysocki wrote:
>>
>> > On Thursday 27 May 2010, Thomas Gleixner wrote:
>> > > On Thu, 27 May 2010, Alan Stern wrote:
>> > >
>> > > > On Thu, 27 May 2010, Felipe Balbi wrote:
>> > > >
>> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>> > > > > >If people don't mind, here is a greatly simplified summary of the
>> > > > > >comments and objections I have seen so far on this thread:
>> > > > > >
>> > > > > >     The in-kernel suspend blocker implementation is okay, even
>> > > > > >     beneficial.
>> > > > >
>> > > > > I disagree here. I believe expressing that as QoS is much better. Let
>> > > > > the kernel decide which power state is better as long as I can say I
>> > > > > need 100us IRQ latency or 100ms wakeup latency.
>> > > >
>> > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
>> > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
>> > >
>> > > mem should be replaced by an idle suspend to ram mechanism
>> >
>> > Well, what about when I want the machine to suspend _regardless_ of whether
>> > or not it's idle at the moment?  That actually happens quite often to me. :-)
>>
>> Fair enough. Let's agree on a non ambigous terminology then:
>>
>>      forced:
>>
>>            suspend which you enforce via user interaction, which
>>            also implies that you risk losing wakeups depending on
>>            the hardware properties
>
> OK
>
>>      opportunistic:
>>
>>            suspend driven from the idle context, which guarantees to
>>            not lose wakeups. Provided only when the hardware does
>>            provide the necessary capabilities.
>
> I can accept that definition, but this is not what "opportunistic" means in the

Is there a difference between this new definition of opportunistic and
idle? I assume suspend here means low a low power sleep state since it
is impossible to initiate and abort Linux suspend from idle since
initiating suspend will cause the system to become not idle.

> Arve's changelogs.  What it means there is that he wants the system to suspend
> even when it is not technically idle (like in the updatedb example I gave in a
> previous message).  Suspend blockers are supposed to be a mechanism by which
> the kernel and user space together may determine when to suspend (and it's
> somewhat orthogonal to idle).
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday 27 May 2010, Thomas Gleixner wrote:
>> On Thu, 27 May 2010, Rafael J. Wysocki wrote:
>>
>> > On Thursday 27 May 2010, Thomas Gleixner wrote:
>> > > On Thu, 27 May 2010, Alan Stern wrote:
>> > >
>> > > > On Thu, 27 May 2010, Felipe Balbi wrote:
>> > > >
>> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>> > > > > >If people don't mind, here is a greatly simplified summary of the
>> > > > > >comments and objections I have seen so far on this thread:
>> > > > > >
>> > > > > >     The in-kernel suspend blocker implementation is okay, even
>> > > > > >     beneficial.
>> > > > >
>> > > > > I disagree here. I believe expressing that as QoS is much better. Let
>> > > > > the kernel decide which power state is better as long as I can say I
>> > > > > need 100us IRQ latency or 100ms wakeup latency.
>> > > >
>> > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
>> > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
>> > >
>> > > mem should be replaced by an idle suspend to ram mechanism
>> >
>> > Well, what about when I want the machine to suspend _regardless_ of whether
>> > or not it's idle at the moment?  That actually happens quite often to me. :-)
>>
>> Fair enough. Let's agree on a non ambigous terminology then:
>>
>>      forced:
>>
>>            suspend which you enforce via user interaction, which
>>            also implies that you risk losing wakeups depending on
>>            the hardware properties
>
> OK
>
>>      opportunistic:
>>
>>            suspend driven from the idle context, which guarantees to
>>            not lose wakeups. Provided only when the hardware does
>>            provide the necessary capabilities.
>
> I can accept that definition, but this is not what "opportunistic" means in the

Is there a difference between this new definition of opportunistic and
idle? I assume suspend here means low a low power sleep state since it
is impossible to initiate and abort Linux suspend from idle since
initiating suspend will cause the system to become not idle.

> Arve's changelogs.  What it means there is that he wants the system to suspend
> even when it is not technically idle (like in the updatedb example I gave in a
> previous message).  Suspend blockers are supposed to be a mechanism by which
> the kernel and user space together may determine when to suspend (and it's
> somewhat orthogonal to idle).
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> That's correct, but to me the Arve's goal is simply to maximize battery life
> and he found experimentally that the longest battery life is achieved if
> system suspend is used whenever the system doesn't need to be active (from its
> user's perspective).  This actually is different from "when the system is
> idle", because the system isn't idle, for example, when updatedb is running.
> However, from the user's perspective the updatedb process doesn't really need
> to run at this particular time, it can very well do it's job in parallel with
> the user typing or reading news.  So, the system may very well be suspended
> when updatedb is running.

This is where the original questions around QoS came in

> Since I think we've now rejected the feature, do we have a clear picture about
> what the Android people should do _instead_ and yet keep the battery life they
> want?  Because I don't think telling "let them do what they want, who cares"
> is right.

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running"
what would need to answer ?

- How do we define who matters: QoS ?

- Can you describe "idle" in terms of QoS without then breaking the
  reliable wakeup for an event (and do you need to ?)

	Could this for example look like

	Set QoS of 'user apps' to QS_NONE
	Button pushed
	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND

	That would I think solve the reliable wakeup case although
	drivers raising a QoS parameter is a bit unusual in the kernel.
	That would at least however be specific to a few Android drivers
	and maybe a tiny amount of shared driver stuff so probably not
	unacceptable. (wake_up_pri(&queue, priority); isn't going to
	kill anyone is it - especially if it usually ignores the
	priority argument)

	I am curious Thomas how that would tie in with PI in the RT
	world, it's effectively inheriting priority from the users finger.

- Would a model where the UI side behaviour looked like

	Timeout
	Screen Off
	Set QoS of 'user apps' to QS_NONE

	Event
	[Some chain of activity]
	Screen On
	Set QoS of 'user apps' to QS_ABOVESUSPEND

  do the job combined with the ability to see who is stopping us dropping
  to suspend so user space can take action. This could be a data table
  from the Android cpu manager provided to Android specific policy in
  whoever owns the display.


If so how do we fix the UI policy code doing

	Screen Off
					Button Press
					task to QS_ABOVESUSPEND
	task to QS_NONE

without touching the app userspace code


Perhaps

	count2 = tasks to QS_NONE | QS_NOTCHANGED
	Screen off
					Button Press
					task to QS_ABOVESUSPEND
	count = tasks that are QS_NOTCHANGED to QS_NONE

	if (count != count2) {
		Stuff happened ... rethink
	}

That is still a bit weird and wonderful but all the logic is in the right
places. The special magic remains in the Android policy code and in the
kernel specifics for Android.

Thoughts ?

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> That's correct, but to me the Arve's goal is simply to maximize battery life
> and he found experimentally that the longest battery life is achieved if
> system suspend is used whenever the system doesn't need to be active (from its
> user's perspective).  This actually is different from "when the system is
> idle", because the system isn't idle, for example, when updatedb is running.
> However, from the user's perspective the updatedb process doesn't really need
> to run at this particular time, it can very well do it's job in parallel with
> the user typing or reading news.  So, the system may very well be suspended
> when updatedb is running.

This is where the original questions around QoS came in

> Since I think we've now rejected the feature, do we have a clear picture about
> what the Android people should do _instead_ and yet keep the battery life they
> want?  Because I don't think telling "let them do what they want, who cares"
> is right.

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running"
what would need to answer ?

- How do we define who matters: QoS ?

- Can you describe "idle" in terms of QoS without then breaking the
  reliable wakeup for an event (and do you need to ?)

	Could this for example look like

	Set QoS of 'user apps' to QS_NONE
	Button pushed
	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND

	That would I think solve the reliable wakeup case although
	drivers raising a QoS parameter is a bit unusual in the kernel.
	That would at least however be specific to a few Android drivers
	and maybe a tiny amount of shared driver stuff so probably not
	unacceptable. (wake_up_pri(&queue, priority); isn't going to
	kill anyone is it - especially if it usually ignores the
	priority argument)

	I am curious Thomas how that would tie in with PI in the RT
	world, it's effectively inheriting priority from the users finger.

- Would a model where the UI side behaviour looked like

	Timeout
	Screen Off
	Set QoS of 'user apps' to QS_NONE

	Event
	[Some chain of activity]
	Screen On
	Set QoS of 'user apps' to QS_ABOVESUSPEND

  do the job combined with the ability to see who is stopping us dropping
  to suspend so user space can take action. This could be a data table
  from the Android cpu manager provided to Android specific policy in
  whoever owns the display.


If so how do we fix the UI policy code doing

	Screen Off
					Button Press
					task to QS_ABOVESUSPEND
	task to QS_NONE

without touching the app userspace code


Perhaps

	count2 = tasks to QS_NONE | QS_NOTCHANGED
	Screen off
					Button Press
					task to QS_ABOVESUSPEND
	count = tasks that are QS_NOTCHANGED to QS_NONE

	if (count != count2) {
		Stuff happened ... rethink
	}

That is still a bit weird and wonderful but all the logic is in the right
places. The special magic remains in the Android policy code and in the
kernel specifics for Android.

Thoughts ?

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
>> >> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>> >> >
>> >> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend
>> >> >> > blockers get enabled by the handler, what causes the system to go back
>> >> >> > into suspend after the event is handled?  Isn't that a loop of some
>> >> >> > sort?
>> >> >> >
>> >> >>
>> >> >> Yes it is a loop. I think what you are missing is that it only loops
>> >> >> repeatedly if the driver that aborts suspend does not use a suspend
>> >> >> blocker.
>> >> >
>> >> > You mean "the driver that handles the wakeup event".  I was asking what
>> >> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
>> >> > a suspend blocker is used then its release causes another suspend
>> >> > attempt, with no looping.
>> >> >
>> >> >> > And even if it isn't, so what?  What's wrong with looping behavior?
>> >> >>
>> >> >> It is a significant power drain.
>> >> >
>> >> > Not in the situation I was discussing.
>> >> >
>> >>
>> >> If you meant it spend most of the time suspended, then I agree. It
>> >> only wastes power when a driver blocks suspend by returning an error
>> >> from its suspend hook and we are forced to loop doing no useful work.
>> >>
>> >
>> > If driver refuses to suspend that means there are events that need
>> > processing. I fail to see why it would be called "looping doing no
>> > useful work".
>>
>> Because the useful work is done in another thread. All the loop does
>> is check if the useful work has completed which most likely will slow
>> down the useful work.
>
> Or useful work could signal when it is done processing critical section.
>

That is what suspend_unblock does.

>> Blocking suspend with a suspend blocker until
>> the useful work is done is more efficient.
>>
>
> --
> Dmitry
>



-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hjønnevåg wrote:
>> 2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>:
>> >> > On Wed, 26 May 2010, Arve Hjønnevåg wrote:
>> >> >
>> >> >> > I must be missing something.  In Arve's patch 1/8, if the system is in
>> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend
>> >> >> > blockers get enabled by the handler, what causes the system to go back
>> >> >> > into suspend after the event is handled?  Isn't that a loop of some
>> >> >> > sort?
>> >> >> >
>> >> >>
>> >> >> Yes it is a loop. I think what you are missing is that it only loops
>> >> >> repeatedly if the driver that aborts suspend does not use a suspend
>> >> >> blocker.
>> >> >
>> >> > You mean "the driver that handles the wakeup event".  I was asking what
>> >> > happened if suspend succeeded and then a wakeup occurred.  But yes, if
>> >> > a suspend blocker is used then its release causes another suspend
>> >> > attempt, with no looping.
>> >> >
>> >> >> > And even if it isn't, so what?  What's wrong with looping behavior?
>> >> >>
>> >> >> It is a significant power drain.
>> >> >
>> >> > Not in the situation I was discussing.
>> >> >
>> >>
>> >> If you meant it spend most of the time suspended, then I agree. It
>> >> only wastes power when a driver blocks suspend by returning an error
>> >> from its suspend hook and we are forced to loop doing no useful work.
>> >>
>> >
>> > If driver refuses to suspend that means there are events that need
>> > processing. I fail to see why it would be called "looping doing no
>> > useful work".
>>
>> Because the useful work is done in another thread. All the loop does
>> is check if the useful work has completed which most likely will slow
>> down the useful work.
>
> Or useful work could signal when it is done processing critical section.
>

That is what suspend_unblock does.

>> Blocking suspend with a suspend blocker until
>> the useful work is done is more efficient.
>>
>
> --
> Dmitry
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> > The approach with user space power manager suggested by Dmitry and Alan Stern
> > may work, but it still assumes some kind of suspend blockers to be present in
> > the kernel.  If we reject that too, I wonder what approach Google is supposed
> > to use and still get the same battery life they get with suspend blockers.
> 
> I'm getting less convinced it needs suspend blockers at all for this case,
> assuming that you are willing to have a policy that is based on
> 
> - assuming apps play nicely
> - having the information to user space you need (who woke us, who blocked
>   us, events)
> - dealing with offenders primarily from user space using that information
> 
> I'm fairly happy about the following so far
> 
> - we should have a common interface for seeing some pm events (like
>   duh ?) but it does need careful thought so the watcher doesn't change
>   the behaviour and break it. (Message "We are suspending", gosh someone
>   is running to receive the message, resume being the obvious case)
> 
> - Suspend is (for many platforms) just a cotinuation down the power
>   chain. Demonstrated and implemented on ARM. Very much the direction of
>   S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
>   made to work, and by reading the Moorestown PR.
> 
> - Given a non forced (that is 'idle down') transition to a suspend level
>   we can implement a 'suspend as idle' on many embedded platforms in a
>   manner which is not racy at kernel level. Apparently implemented
>   already on ARM
> 
> - Given a non forced transition to such a suspend level and the reporting
>   of certain events we can do a full user space managed graphical UI type
>   environment policy in a race free fashion
> 
> - With notification of who caused a resume and maybe a bit of other
>   general stat gathering it is possible to identify and handle abuses of
>   power resource. Proved by the fact we can do this with powertop but
>   more elegance in the interfaces would be nice.
> 
> I am not sure if a pm event is what is needed for this or a sum 'hardware
> triggered wake up' event.
> 
> I accept that current ACPI based laptops probably couldn't make use of
> such a feature but I don't think this is important at the moment.

No, it's not.

> A resource constraint model might help further in the ACPI case. It's
> useful for other stuff but it might well be a distraction and
> implementation detail in terms of the basic question about what is needed
> for something like Android.
> 
> At this point the input of the Android team and the Nokia people would
> be rather more useful to me.

OK, I added Arve and Brian to the CC list.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> > The approach with user space power manager suggested by Dmitry and Alan Stern
> > may work, but it still assumes some kind of suspend blockers to be present in
> > the kernel.  If we reject that too, I wonder what approach Google is supposed
> > to use and still get the same battery life they get with suspend blockers.
> 
> I'm getting less convinced it needs suspend blockers at all for this case,
> assuming that you are willing to have a policy that is based on
> 
> - assuming apps play nicely
> - having the information to user space you need (who woke us, who blocked
>   us, events)
> - dealing with offenders primarily from user space using that information
> 
> I'm fairly happy about the following so far
> 
> - we should have a common interface for seeing some pm events (like
>   duh ?) but it does need careful thought so the watcher doesn't change
>   the behaviour and break it. (Message "We are suspending", gosh someone
>   is running to receive the message, resume being the obvious case)
> 
> - Suspend is (for many platforms) just a cotinuation down the power
>   chain. Demonstrated and implemented on ARM. Very much the direction of
>   S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
>   made to work, and by reading the Moorestown PR.
> 
> - Given a non forced (that is 'idle down') transition to a suspend level
>   we can implement a 'suspend as idle' on many embedded platforms in a
>   manner which is not racy at kernel level. Apparently implemented
>   already on ARM
> 
> - Given a non forced transition to such a suspend level and the reporting
>   of certain events we can do a full user space managed graphical UI type
>   environment policy in a race free fashion
> 
> - With notification of who caused a resume and maybe a bit of other
>   general stat gathering it is possible to identify and handle abuses of
>   power resource. Proved by the fact we can do this with powertop but
>   more elegance in the interfaces would be nice.
> 
> I am not sure if a pm event is what is needed for this or a sum 'hardware
> triggered wake up' event.
> 
> I accept that current ACPI based laptops probably couldn't make use of
> such a feature but I don't think this is important at the moment.

No, it's not.

> A resource constraint model might help further in the ACPI case. It's
> useful for other stuff but it might well be a distraction and
> implementation detail in terms of the basic question about what is needed
> for something like Android.
> 
> At this point the input of the Android team and the Nokia people would
> be rather more useful to me.

OK, I added Arve and Brian to the CC list.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Dmitry Torokhov]

On Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote:
> > That's correct, but to me the Arve's goal is simply to maximize battery life
> > and he found experimentally that the longest battery life is achieved if
> > system suspend is used whenever the system doesn't need to be active (from its
> > user's perspective).  This actually is different from "when the system is
> > idle", because the system isn't idle, for example, when updatedb is running.
> > However, from the user's perspective the updatedb process doesn't really need
> > to run at this particular time, it can very well do it's job in parallel with
> > the user typing or reading news.  So, the system may very well be suspended
> > when updatedb is running.
> 
> This is where the original questions around QoS came in
> 
> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?
> 
> - Can you describe "idle" in terms of QoS without then breaking the
>   reliable wakeup for an event (and do you need to ?)
> 
> 	Could this for example look like
> 
> 	Set QoS of 'user apps' to QS_NONE
> 	Button pushed
> 	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> 
> 	That would I think solve the reliable wakeup case although
> 	drivers raising a QoS parameter is a bit unusual in the kernel.
> 	That would at least however be specific to a few Android drivers
> 	and maybe a tiny amount of shared driver stuff so probably not
> 	unacceptable. (wake_up_pri(&queue, priority); isn't going to
> 	kill anyone is it - especially if it usually ignores the
> 	priority argument)

That should probably go into higher levels, not in individual drivers,
so we should be able to limit spreading of wake_up_pri() or whatever
throughout the tree.  This particular case should be probably handled by
evdev raising QoS of the user that is opened particular
/dev/input/eventX.

-- 
Dmitry

Re: [PATCH 0/8] Suspend block api (version 8)

[Dmitry Torokhov]

On Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote:
> > That's correct, but to me the Arve's goal is simply to maximize battery life
> > and he found experimentally that the longest battery life is achieved if
> > system suspend is used whenever the system doesn't need to be active (from its
> > user's perspective).  This actually is different from "when the system is
> > idle", because the system isn't idle, for example, when updatedb is running.
> > However, from the user's perspective the updatedb process doesn't really need
> > to run at this particular time, it can very well do it's job in parallel with
> > the user typing or reading news.  So, the system may very well be suspended
> > when updatedb is running.
> 
> This is where the original questions around QoS came in
> 
> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?
> 
> - Can you describe "idle" in terms of QoS without then breaking the
>   reliable wakeup for an event (and do you need to ?)
> 
> 	Could this for example look like
> 
> 	Set QoS of 'user apps' to QS_NONE
> 	Button pushed
> 	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> 
> 	That would I think solve the reliable wakeup case although
> 	drivers raising a QoS parameter is a bit unusual in the kernel.
> 	That would at least however be specific to a few Android drivers
> 	and maybe a tiny amount of shared driver stuff so probably not
> 	unacceptable. (wake_up_pri(&queue, priority); isn't going to
> 	kill anyone is it - especially if it usually ignores the
> 	priority argument)

That should probably go into higher levels, not in individual drivers,
so we should be able to limit spreading of wake_up_pri() or whatever
throughout the tree.  This particular case should be probably handled by
evdev raising QoS of the user that is opened particular
/dev/input/eventX.

-- 
Dmitry

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> > That's correct, but to me the Arve's goal is simply to maximize battery life
> > and he found experimentally that the longest battery life is achieved if
> > system suspend is used whenever the system doesn't need to be active (from its
> > user's perspective).  This actually is different from "when the system is
> > idle", because the system isn't idle, for example, when updatedb is running.
> > However, from the user's perspective the updatedb process doesn't really need
> > to run at this particular time, it can very well do it's job in parallel with
> > the user typing or reading news.  So, the system may very well be suspended
> > when updatedb is running.
> 
> This is where the original questions around QoS came in
> 
> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?

That's reasonable IMO.

> - Can you describe "idle" in terms of QoS without then breaking the
>   reliable wakeup for an event (and do you need to ?)
> 
> 	Could this for example look like
> 
> 	Set QoS of 'user apps' to QS_NONE
> 	Button pushed
> 	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> 
> 	That would I think solve the reliable wakeup case although
> 	drivers raising a QoS parameter is a bit unusual in the kernel.
> 	That would at least however be specific to a few Android drivers
> 	and maybe a tiny amount of shared driver stuff so probably not
> 	unacceptable. (wake_up_pri(&queue, priority); isn't going to
> 	kill anyone is it - especially if it usually ignores the
> 	priority argument)
> 
> 	I am curious Thomas how that would tie in with PI in the RT
> 	world, it's effectively inheriting priority from the users finger.
> 
> - Would a model where the UI side behaviour looked like
> 
> 	Timeout
> 	Screen Off
> 	Set QoS of 'user apps' to QS_NONE
> 
> 	Event
> 	[Some chain of activity]
> 	Screen On
> 	Set QoS of 'user apps' to QS_ABOVESUSPEND
> 
>   do the job combined with the ability to see who is stopping us dropping
>   to suspend so user space can take action. This could be a data table
>   from the Android cpu manager provided to Android specific policy in
>   whoever owns the display.
> 
> 
> If so how do we fix the UI policy code doing
> 
> 	Screen Off
> 					Button Press
> 					task to QS_ABOVESUSPEND
> 	task to QS_NONE
> 
> without touching the app userspace code
> 
> 
> Perhaps
> 
> 	count2 = tasks to QS_NONE | QS_NOTCHANGED
> 	Screen off
> 					Button Press
> 					task to QS_ABOVESUSPEND
> 	count = tasks that are QS_NOTCHANGED to QS_NONE
> 
> 	if (count != count2) {
> 		Stuff happened ... rethink
> 	}
> 
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
> 
> Thoughts ?

Hmm.  How do we prevent the "non-relevant" tasks from being scheduled
once we've decided to go for power saving?

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Alan Cox wrote:
> > That's correct, but to me the Arve's goal is simply to maximize battery life
> > and he found experimentally that the longest battery life is achieved if
> > system suspend is used whenever the system doesn't need to be active (from its
> > user's perspective).  This actually is different from "when the system is
> > idle", because the system isn't idle, for example, when updatedb is running.
> > However, from the user's perspective the updatedb process doesn't really need
> > to run at this particular time, it can very well do it's job in parallel with
> > the user typing or reading news.  So, the system may very well be suspended
> > when updatedb is running.
> 
> This is where the original questions around QoS came in
> 
> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?

That's reasonable IMO.

> - Can you describe "idle" in terms of QoS without then breaking the
>   reliable wakeup for an event (and do you need to ?)
> 
> 	Could this for example look like
> 
> 	Set QoS of 'user apps' to QS_NONE
> 	Button pushed
> 	Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> 
> 	That would I think solve the reliable wakeup case although
> 	drivers raising a QoS parameter is a bit unusual in the kernel.
> 	That would at least however be specific to a few Android drivers
> 	and maybe a tiny amount of shared driver stuff so probably not
> 	unacceptable. (wake_up_pri(&queue, priority); isn't going to
> 	kill anyone is it - especially if it usually ignores the
> 	priority argument)
> 
> 	I am curious Thomas how that would tie in with PI in the RT
> 	world, it's effectively inheriting priority from the users finger.
> 
> - Would a model where the UI side behaviour looked like
> 
> 	Timeout
> 	Screen Off
> 	Set QoS of 'user apps' to QS_NONE
> 
> 	Event
> 	[Some chain of activity]
> 	Screen On
> 	Set QoS of 'user apps' to QS_ABOVESUSPEND
> 
>   do the job combined with the ability to see who is stopping us dropping
>   to suspend so user space can take action. This could be a data table
>   from the Android cpu manager provided to Android specific policy in
>   whoever owns the display.
> 
> 
> If so how do we fix the UI policy code doing
> 
> 	Screen Off
> 					Button Press
> 					task to QS_ABOVESUSPEND
> 	task to QS_NONE
> 
> without touching the app userspace code
> 
> 
> Perhaps
> 
> 	count2 = tasks to QS_NONE | QS_NOTCHANGED
> 	Screen off
> 					Button Press
> 					task to QS_ABOVESUSPEND
> 	count = tasks that are QS_NOTCHANGED to QS_NONE
> 
> 	if (count != count2) {
> 		Stuff happened ... rethink
> 	}
> 
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
> 
> Thoughts ?

Hmm.  How do we prevent the "non-relevant" tasks from being scheduled
once we've decided to go for power saving?

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 4:50 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> That's correct, but to me the Arve's goal is simply to maximize battery life
>> and he found experimentally that the longest battery life is achieved if
>> system suspend is used whenever the system doesn't need to be active (from its
>> user's perspective).  This actually is different from "when the system is
>> idle", because the system isn't idle, for example, when updatedb is running.
>> However, from the user's perspective the updatedb process doesn't really need
>> to run at this particular time, it can very well do it's job in parallel with
>> the user typing or reading news.  So, the system may very well be suspended
>> when updatedb is running.
>
> This is where the original questions around QoS came in
>
>> Since I think we've now rejected the feature, do we have a clear picture about
>> what the Android people should do _instead_ and yet keep the battery life they
>> want?  Because I don't think telling "let them do what they want, who cares"
>> is right.
>
> Today "idle" means "no task running"
>
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
>
> - How do we define who matters: QoS ?
>

This is a much harder question to answer that what we need to use
opportunistic suspend. The question we ask is more like this: "Is all
important work complete?". In the simplest case these can be the same,
but on Android they are not. Some wakeup events require work to be
performed in many processes. A thread that needs to respond to a
wakeup event may currently be busy doing unimportant work. This could
possibly be solved by saying all important work must be above priority
N, but you would need full priority inheritance support and we are not
there today.

> - Can you describe "idle" in terms of QoS without then breaking the
>  reliable wakeup for an event (and do you need to ?)
>
>        Could this for example look like
>
>        Set QoS of 'user apps' to QS_NONE
>        Button pushed
>        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>

What happens if the user presses the button right before you set QoS
of 'user apps' to  QS_NONE?
To me it looks like this solution would result in this sequence which
may ignore the button press:
        Button pushed
        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
        Set QoS of 'user apps' to QS_NONE


>        That would I think solve the reliable wakeup case although
>        drivers raising a QoS parameter is a bit unusual in the kernel.
>        That would at least however be specific to a few Android drivers
>        and maybe a tiny amount of shared driver stuff so probably not
>        unacceptable. (wake_up_pri(&queue, priority); isn't going to
>        kill anyone is it - especially if it usually ignores the
>        priority argument)

Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

>
>        I am curious Thomas how that would tie in with PI in the RT
>        world, it's effectively inheriting priority from the users finger.
>
> - Would a model where the UI side behaviour looked like
>
>        Timeout
>        Screen Off
>        Set QoS of 'user apps' to QS_NONE
>
>        Event
>        [Some chain of activity]
>        Screen On
>        Set QoS of 'user apps' to QS_ABOVESUSPEND
>
>  do the job combined with the ability to see who is stopping us dropping
>  to suspend so user space can take action. This could be a data table
>  from the Android cpu manager provided to Android specific policy in
>  whoever owns the display.
>
>
> If so how do we fix the UI policy code doing
>
>        Screen Off
>                                        Button Press
>                                        task to QS_ABOVESUSPEND
>        task to QS_NONE
>
> without touching the app userspace code
>
>
> Perhaps
>

What happens if the button press happend before this line:
>        count2 = tasks to QS_NONE | QS_NOTCHANGED
>        Screen off
>                                        Button Press
>                                        task to QS_ABOVESUSPEND
>        count = tasks that are QS_NOTCHANGED to QS_NONE
>
>        if (count != count2) {
>                Stuff happened ... rethink
>        }
>
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
>
> Thoughts ?

I don't think it works. Also, it does not seem much less invasive than
suspend blockers.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 4:50 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> That's correct, but to me the Arve's goal is simply to maximize battery life
>> and he found experimentally that the longest battery life is achieved if
>> system suspend is used whenever the system doesn't need to be active (from its
>> user's perspective).  This actually is different from "when the system is
>> idle", because the system isn't idle, for example, when updatedb is running.
>> However, from the user's perspective the updatedb process doesn't really need
>> to run at this particular time, it can very well do it's job in parallel with
>> the user typing or reading news.  So, the system may very well be suspended
>> when updatedb is running.
>
> This is where the original questions around QoS came in
>
>> Since I think we've now rejected the feature, do we have a clear picture about
>> what the Android people should do _instead_ and yet keep the battery life they
>> want?  Because I don't think telling "let them do what they want, who cares"
>> is right.
>
> Today "idle" means "no task running"
>
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
>
> - How do we define who matters: QoS ?
>

This is a much harder question to answer that what we need to use
opportunistic suspend. The question we ask is more like this: "Is all
important work complete?". In the simplest case these can be the same,
but on Android they are not. Some wakeup events require work to be
performed in many processes. A thread that needs to respond to a
wakeup event may currently be busy doing unimportant work. This could
possibly be solved by saying all important work must be above priority
N, but you would need full priority inheritance support and we are not
there today.

> - Can you describe "idle" in terms of QoS without then breaking the
>  reliable wakeup for an event (and do you need to ?)
>
>        Could this for example look like
>
>        Set QoS of 'user apps' to QS_NONE
>        Button pushed
>        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>

What happens if the user presses the button right before you set QoS
of 'user apps' to  QS_NONE?
To me it looks like this solution would result in this sequence which
may ignore the button press:
        Button pushed
        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
        Set QoS of 'user apps' to QS_NONE


>        That would I think solve the reliable wakeup case although
>        drivers raising a QoS parameter is a bit unusual in the kernel.
>        That would at least however be specific to a few Android drivers
>        and maybe a tiny amount of shared driver stuff so probably not
>        unacceptable. (wake_up_pri(&queue, priority); isn't going to
>        kill anyone is it - especially if it usually ignores the
>        priority argument)

Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

>
>        I am curious Thomas how that would tie in with PI in the RT
>        world, it's effectively inheriting priority from the users finger.
>
> - Would a model where the UI side behaviour looked like
>
>        Timeout
>        Screen Off
>        Set QoS of 'user apps' to QS_NONE
>
>        Event
>        [Some chain of activity]
>        Screen On
>        Set QoS of 'user apps' to QS_ABOVESUSPEND
>
>  do the job combined with the ability to see who is stopping us dropping
>  to suspend so user space can take action. This could be a data table
>  from the Android cpu manager provided to Android specific policy in
>  whoever owns the display.
>
>
> If so how do we fix the UI policy code doing
>
>        Screen Off
>                                        Button Press
>                                        task to QS_ABOVESUSPEND
>        task to QS_NONE
>
> without touching the app userspace code
>
>
> Perhaps
>

What happens if the button press happend before this line:
>        count2 = tasks to QS_NONE | QS_NOTCHANGED
>        Screen off
>                                        Button Press
>                                        task to QS_ABOVESUSPEND
>        count = tasks that are QS_NOTCHANGED to QS_NONE
>
>        if (count != count2) {
>                Stuff happened ... rethink
>        }
>
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
>
> Thoughts ?

I don't think it works. Also, it does not seem much less invasive than
suspend blockers.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Mike Chan]

On Thu, May 27, 2010 at 5:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday 28 May 2010, Alan Cox wrote:
>> > The approach with user space power manager suggested by Dmitry and Alan Stern
>> > may work, but it still assumes some kind of suspend blockers to be present in
>> > the kernel.  If we reject that too, I wonder what approach Google is supposed
>> > to use and still get the same battery life they get with suspend blockers.
>>
>> I'm getting less convinced it needs suspend blockers at all for this case,
>> assuming that you are willing to have a policy that is based on
>>
>> - assuming apps play nicely
>> - having the information to user space you need (who woke us, who blocked
>>   us, events)
>> - dealing with offenders primarily from user space using that information
>>
>> I'm fairly happy about the following so far
>>
>> - we should have a common interface for seeing some pm events (like
>>   duh ?) but it does need careful thought so the watcher doesn't change
>>   the behaviour and break it. (Message "We are suspending", gosh someone
>>   is running to receive the message, resume being the obvious case)
>>
>> - Suspend is (for many platforms) just a cotinuation down the power
>>   chain. Demonstrated and implemented on ARM. Very much the direction of
>>   S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
>>   made to work, and by reading the Moorestown PR.
>>
>> - Given a non forced (that is 'idle down') transition to a suspend level
>>   we can implement a 'suspend as idle' on many embedded platforms in a
>>   manner which is not racy at kernel level. Apparently implemented
>>   already on ARM
>>
>> - Given a non forced transition to such a suspend level and the reporting
>>   of certain events we can do a full user space managed graphical UI type
>>   environment policy in a race free fashion
>>
>> - With notification of who caused a resume and maybe a bit of other
>>   general stat gathering it is possible to identify and handle abuses of
>>   power resource. Proved by the fact we can do this with powertop but
>>   more elegance in the interfaces would be nice.
>>
>> I am not sure if a pm event is what is needed for this or a sum 'hardware
>> triggered wake up' event.
>>
>> I accept that current ACPI based laptops probably couldn't make use of
>> such a feature but I don't think this is important at the moment.
>
> No, it's not.
>
>> A resource constraint model might help further in the ACPI case. It's
>> useful for other stuff but it might well be a distraction and
>> implementation detail in terms of the basic question about what is needed
>> for something like Android.
>>
>> At this point the input of the Android team and the Nokia people would
>> be rather more useful to me.
>
> OK, I added Arve and Brian to the CC list.
>

Even if we used the proposed QoS replacement, are there suggestions on
how to keep the cpu idle for longer than 2 seconds in Linux without
using suspend?

On a thread somewhere I had real world power numbers on a Motorola
Droid idling (screen off) with and without suspend blockers.

-- Mike

> Thanks,
> Rafael
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>

Re: [PATCH 0/8] Suspend block api (version 8)

[Mike Chan]

On Thu, May 27, 2010 at 5:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday 28 May 2010, Alan Cox wrote:
>> > The approach with user space power manager suggested by Dmitry and Alan Stern
>> > may work, but it still assumes some kind of suspend blockers to be present in
>> > the kernel.  If we reject that too, I wonder what approach Google is supposed
>> > to use and still get the same battery life they get with suspend blockers.
>>
>> I'm getting less convinced it needs suspend blockers at all for this case,
>> assuming that you are willing to have a policy that is based on
>>
>> - assuming apps play nicely
>> - having the information to user space you need (who woke us, who blocked
>>   us, events)
>> - dealing with offenders primarily from user space using that information
>>
>> I'm fairly happy about the following so far
>>
>> - we should have a common interface for seeing some pm events (like
>>   duh ?) but it does need careful thought so the watcher doesn't change
>>   the behaviour and break it. (Message "We are suspending", gosh someone
>>   is running to receive the message, resume being the obvious case)
>>
>> - Suspend is (for many platforms) just a cotinuation down the power
>>   chain. Demonstrated and implemented on ARM. Very much the direction of
>>   S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
>>   made to work, and by reading the Moorestown PR.
>>
>> - Given a non forced (that is 'idle down') transition to a suspend level
>>   we can implement a 'suspend as idle' on many embedded platforms in a
>>   manner which is not racy at kernel level. Apparently implemented
>>   already on ARM
>>
>> - Given a non forced transition to such a suspend level and the reporting
>>   of certain events we can do a full user space managed graphical UI type
>>   environment policy in a race free fashion
>>
>> - With notification of who caused a resume and maybe a bit of other
>>   general stat gathering it is possible to identify and handle abuses of
>>   power resource. Proved by the fact we can do this with powertop but
>>   more elegance in the interfaces would be nice.
>>
>> I am not sure if a pm event is what is needed for this or a sum 'hardware
>> triggered wake up' event.
>>
>> I accept that current ACPI based laptops probably couldn't make use of
>> such a feature but I don't think this is important at the moment.
>
> No, it's not.
>
>> A resource constraint model might help further in the ACPI case. It's
>> useful for other stuff but it might well be a distraction and
>> implementation detail in terms of the basic question about what is needed
>> for something like Android.
>>
>> At this point the input of the Android team and the Nokia people would
>> be rather more useful to me.
>
> OK, I added Arve and Brian to the CC list.
>

Even if we used the proposed QoS replacement, are there suggestions on
how to keep the cpu idle for longer than 2 seconds in Linux without
using suspend?

On a thread somewhere I had real world power numbers on a Motorola
Droid idling (screen off) with and without suspend blockers.

-- Mike

> Thanks,
> Rafael
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Rafael J. Wysocki wrote:

> > And the forced-suspend design relies on the fact that processes remain 
> > frozen throughout.  If we leave some processes unfrozen and one of them 
> > somehow becomes runnable, that means we have to abort the forced 
> > suspend before the process is allowed to run.
> 
> We could avoid that if drivers could block tasks, but there are questions to
> answer.  First off, how a driver is supposed to know when to block the task
> using it and when to do its power management transparently for the task?
> Second, how to intercept and block all possible interfaces that user space
> can use to talk to drivers (how to intercept a task using mmapped device, for
> example)?

We talked about this a few years ago and decided it was not feasible.  
It would require substantial changes to every device driver.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Rafael J. Wysocki wrote:

> > And the forced-suspend design relies on the fact that processes remain 
> > frozen throughout.  If we leave some processes unfrozen and one of them 
> > somehow becomes runnable, that means we have to abort the forced 
> > suspend before the process is allowed to run.
> 
> We could avoid that if drivers could block tasks, but there are questions to
> answer.  First off, how a driver is supposed to know when to block the task
> using it and when to do its power management transparently for the task?
> Second, how to intercept and block all possible interfaces that user space
> can use to talk to drivers (how to intercept a task using mmapped device, for
> example)?

We talked about this a few years ago and decided it was not feasible.  
It would require substantial changes to every device driver.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Ben Gamari]

On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler <florian@mickler.org> wrote:
> Because he is using a robust kernel that provides suspend blockers and
> is preventing the vampire from sucking power? 
> 
Suspend blockers are only a flawed and indirect way to keep the vampire
from sucking.

> Most users don't even grasp the simple concept of different "programs".
> They just have a device and click here and there and are happy. 
> 
> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)

He's getting at the fact that there are much better ways to deal with
this problem. The issue here is that we seem to be expected to swallow
whatever Google throws at us, regardless of the quality of the
solution. It seems like the best argument we have for merging is "we
couldn't think of anything better and we need it yesterday." This might be
a good enough reason for shipping, but it certainly doesn't satisfy the
requirements for merging.

> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

It is absolutely not. If you want to keep power usage down, then
implement real resource management in the scheduler. Suspend blockers
are nothing but a clunky and ineffective means of resource allocation.
As has been pointed out in this thread, there are much better ways of
dealing with this problem.

- Ben

Re: [PATCH 0/8] Suspend block api (version 8)

[Ben Gamari]

On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler <florian@mickler.org> wrote:
> Because he is using a robust kernel that provides suspend blockers and
> is preventing the vampire from sucking power? 
> 
Suspend blockers are only a flawed and indirect way to keep the vampire
from sucking.

> Most users don't even grasp the simple concept of different "programs".
> They just have a device and click here and there and are happy. 
> 
> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)

He's getting at the fact that there are much better ways to deal with
this problem. The issue here is that we seem to be expected to swallow
whatever Google throws at us, regardless of the quality of the
solution. It seems like the best argument we have for merging is "we
couldn't think of anything better and we need it yesterday." This might be
a good enough reason for shipping, but it certainly doesn't satisfy the
requirements for merging.

> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

It is absolutely not. If you want to keep power usage down, then
implement real resource management in the scheduler. Suspend blockers
are nothing but a clunky and ineffective means of resource allocation.
As has been pointed out in this thread, there are much better ways of
dealing with this problem.

- Ben

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 27 May 2010 23:09:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
>> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
>>
>> > This is I believe robust (and has been implemented on some non x86
>> > boxes). It depends on not forcing running tasks into suspend. That is the
>> > key.
>>
>> We've already established that ACPI systems require us to force running
>> tasks into suspend. How do we avoid the race in that situation?
>
> Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> x86 devices do not have ACPI.
>

Android does not only run on phones. It is possible that no android
devices have ACPI, but I don't know that for a fact. What I do know is
that people want to run Android on x86 hardware and supporting suspend
could be very benficial.

> I would imagine the existing laptops will handle power management limited
> by the functionality they have available. Just like any other piece of
> hardware.

I think existing laptops (and desktops) can benefit from opportunistic
suspend support. If opportunistic suspend is used for auto-sleep after
inactivity instead of forced suspend, the user space suspend blocker
api will allow an application to delay this auto sleep until for
instance a download completes. This part could also be done with a
user-space IPC call, but having a standard kernel interface for it may
make it more common. A less common case, but more critical, is RTC
alarms. I know my desktops can wakeup at a specific time by
programming an RTC alarm, but without suspend blockers how do you
ensure that the system does not suspend right after the alarm
triggered? I have a system that wakes up at specific times requested
by my DVR application, but I cannot use this system for anything else
unless I manually turn off the DVR application's auto-sleep feature.
With suspend blockers and something like the android alarm driver, I
could use this system for more than one application that have
scheduled tasks and it would be more usable for interactive
applications.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 27 May 2010 23:09:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
>> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
>>
>> > This is I believe robust (and has been implemented on some non x86
>> > boxes). It depends on not forcing running tasks into suspend. That is the
>> > key.
>>
>> We've already established that ACPI systems require us to force running
>> tasks into suspend. How do we avoid the race in that situation?
>
> Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> x86 devices do not have ACPI.
>

Android does not only run on phones. It is possible that no android
devices have ACPI, but I don't know that for a fact. What I do know is
that people want to run Android on x86 hardware and supporting suspend
could be very benficial.

> I would imagine the existing laptops will handle power management limited
> by the functionality they have available. Just like any other piece of
> hardware.

I think existing laptops (and desktops) can benefit from opportunistic
suspend support. If opportunistic suspend is used for auto-sleep after
inactivity instead of forced suspend, the user space suspend blocker
api will allow an application to delay this auto sleep until for
instance a download completes. This part could also be done with a
user-space IPC call, but having a standard kernel interface for it may
make it more common. A less common case, but more critical, is RTC
alarms. I know my desktops can wakeup at a specific time by
programming an RTC alarm, but without suspend blockers how do you
ensure that the system does not suspend right after the alarm
triggered? I have a system that wakes up at specific times requested
by my DVR application, but I cannot use this system for anything else
unless I manually turn off the DVR application's auto-sleep feature.
With suspend blockers and something like the android alarm driver, I
could use this system for more than one application that have
scheduled tasks and it would be more usable for interactive
applications.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 27 May 2010 23:09:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
>> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
>>
>> > This is I believe robust (and has been implemented on some non x86
>> > boxes). It depends on not forcing running tasks into suspend. That is the
>> > key.
>>
>> We've already established that ACPI systems require us to force running
>> tasks into suspend. How do we avoid the race in that situation?
>
> Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
> x86 devices do not have ACPI.
>

Android does not only run on phones. It is possible that no android
devices have ACPI, but I don't know that for a fact. What I do know is
that people want to run Android on x86 hardware and supporting suspend
could be very benficial.

> I would imagine the existing laptops will handle power management limited
> by the functionality they have available. Just like any other piece of
> hardware.

I think existing laptops (and desktops) can benefit from opportunistic
suspend support. If opportunistic suspend is used for auto-sleep after
inactivity instead of forced suspend, the user space suspend blocker
api will allow an application to delay this auto sleep until for
instance a download completes. This part could also be done with a
user-space IPC call, but having a standard kernel interface for it may
make it more common. A less common case, but more critical, is RTC
alarms. I know my desktops can wakeup at a specific time by
programming an RTC alarm, but without suspend blockers how do you
ensure that the system does not suspend right after the alarm
triggered? I have a system that wakes up at specific times requested
by my DVR application, but I cannot use this system for anything else
unless I manually turn off the DVR application's auto-sleep feature.
With suspend blockers and something like the android alarm driver, I
could use this system for more than one application that have
scheduled tasks and it would be more usable for interactive
applications.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Thu, 27 May 2010 02:07:21 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> >
> >> of it into pm QoS stuff and if one day someone solves the rogue app
> >> problem, we can migrate over.
> >
> > If it's so important for Android and no one else, Android can carry it
> > out of tree.
> >
> 
> This is not only important for Android. If you use suspend on a
> current Linux system you run the risk of loosing wakeup events. If you
> have wakeup events that you cannot afford to lose your only option is
> to never suspend. On some hardware (e.g. x86) the cost of not
> suspending is always huge, on other hardware (many ARM SOCs) the cost
> is only huge if your apps behave poorly.
> 

So here is my suggestion.
Rather than trying to push a feature that is clearly meeting lots of
resistance, the Android devs should state the problem as a bug that needs
fixing.  As you have.
Upstream is a lot more receptive of fixing bugs than adding features.

In this case the bug is that you cannot suspend without the risk of losing
wakeup events.  This is a real bug that for your use case is a serious
bug.  I've toyed with several ways of fixing this but the one that seems most
promising is to note that in the kernel the suspend process is two-stage with
a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction
and so ends up with a race.

Maybe userspace should be able to say "prepare to suspend" with the meaning
that after a successful return, any event which would cause a wakeup sets a
flag so that the final suspend returns immediately (without actually going to
the lower power state).

Then your opportunistic suspend could be entirely in userspace where you
wouldn't have to fight with the kernel crowd :-)
The suspend-daemon would:
  Wait for all user-space suspend blocks to be dropped.
  Tell the kernel to "prepare to suspend".
  Tell all userspace programs which have registered for the message that they
    should prepare to suspend.  They have the opportunity at this point to
    take out a new suspend block if they notice an event that has
    just arrived
  Wait for all those programs to acknowledge
  If there are no new suspend blocks, tell the kernel to suspend
  else tell the kernel to abort the suspend.

This (I think) allows race-free opportunistic suspend in user-space where
you can do all the accounting you need.

I don't fully understand your requirements for accounting of devices drivers
rejecting or blocking a suspend, so I cannot say precisely how that would fit
in.  Maybe you just need to know - whenever the 'suspend request' completes -
what the wakeup events were.  It shouldn't be too hard to export that to
user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for
requesting a suspend, but I suspect it should expose each of
  suspend_prepare
  suspend_devices_and_enter
  suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to
"open-for-write", "write", "close", but I'm not sure that suspend_prepare
would be appropriate if the app was about to write "disk" - it is a pity that
both suspend and hibernate use the same sysfs file.

So just fix the bug, and everyone will be happy :-)

Thanks,
NeilBrown
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[tytso]

On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote:
> 
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
> 
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

Keep in mind, though, that a solution which is acceptable for Android
has to include making sure that crappy applications don't cause the
battery to get drained.  There seem to be some people who seem
adamently against this requirement.  From the Android folks'
perspective, this is part of what is required to have an open app
store, as opposed to one where each application has to be carefully
screened and approved ala the Apple iPhone App Store.

Maybe it would be acceptable if there were an easy way THAT A USER AND
NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad
application, but realistically, it's much better if the solution can
work well even in the face of crappy application.  Having interacted
with application programmers, I can assure you there are a lot of
crappy application programmers out there, and they vastly outnumber us
kernel developers.  (See as exhibit A all of the application programs
who refuse to use fsync, even though it's going to wipe them out on
all new modern file systems, including btrfs.)

We need to agree on the requirements up front, because otherwise this
is going to be a waste of everyone's time.

And if we can't get agreement on requirements, I'd suggest appealing
this whole thing to Linus.  Either he'll agree to the requirements
and/or the existing implementation, in which case we can move on with
our lives, or he'll say no, in which case it will be blately obvious
that it was Linux developer community who rejected the Android
approach, despite a fairly large amount of effort trying to get
something that satisfies *all* of the various LKML developers who have
commented on this patch, and we can continue with Android having
kernel which is different from mainline --- just as many other
embedded companies have patches which are utterly required by their
products, but which have been judged Too Ugly To Live In Mainline ---
and we can also move on and get on with our lives.

						- Ted

P.S.  Keep in mind how this looks from an outsider's perspective; an
embedded manufacturer spends a fairly large amount of time answering
one set of review comments, and a few weeks later, more people pop up,
and make a much deeper set of complaints, and request that the current
implementation be completely thrown out and that someone new be
designed from scratch --- and the new design isn't even going to meet
all of the requirements that the embedded manufacturer thought were
necessary.  Is it any wonder a number of embedded developers have
decided it's Just Too Hard to Work With the LKML?

Re: [PATCH 0/8] Suspend block api (version 8)

[tytso]

On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote:
> 
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
> 
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

Keep in mind, though, that a solution which is acceptable for Android
has to include making sure that crappy applications don't cause the
battery to get drained.  There seem to be some people who seem
adamently against this requirement.  From the Android folks'
perspective, this is part of what is required to have an open app
store, as opposed to one where each application has to be carefully
screened and approved ala the Apple iPhone App Store.

Maybe it would be acceptable if there were an easy way THAT A USER AND
NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad
application, but realistically, it's much better if the solution can
work well even in the face of crappy application.  Having interacted
with application programmers, I can assure you there are a lot of
crappy application programmers out there, and they vastly outnumber us
kernel developers.  (See as exhibit A all of the application programs
who refuse to use fsync, even though it's going to wipe them out on
all new modern file systems, including btrfs.)

We need to agree on the requirements up front, because otherwise this
is going to be a waste of everyone's time.

And if we can't get agreement on requirements, I'd suggest appealing
this whole thing to Linus.  Either he'll agree to the requirements
and/or the existing implementation, in which case we can move on with
our lives, or he'll say no, in which case it will be blately obvious
that it was Linux developer community who rejected the Android
approach, despite a fairly large amount of effort trying to get
something that satisfies *all* of the various LKML developers who have
commented on this patch, and we can continue with Android having
kernel which is different from mainline --- just as many other
embedded companies have patches which are utterly required by their
products, but which have been judged Too Ugly To Live In Mainline ---
and we can also move on and get on with our lives.

						- Ted

P.S.  Keep in mind how this looks from an outsider's perspective; an
embedded manufacturer spends a fairly large amount of time answering
one set of review comments, and a few weeks later, more people pop up,
and make a much deeper set of complaints, and request that the current
implementation be completely thrown out and that someone new be
designed from scratch --- and the new design isn't even going to meet
all of the requirements that the embedded manufacturer thought were
necessary.  Is it any wonder a number of embedded developers have
decided it's Just Too Hard to Work With the LKML?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
>
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

I think that the suspend block model can be viewed as a constraints
problem (similar to some of things things you've been sketching out in
these threads), but I think we (Google/Android) view it as more of a
state constraint (don't enter suspend) than a latency constraint.

We think there's a need for these constraints both from the driver
side and userspace side, and that these constraints are not tied to
processes (multiple entities in one process may have different
constraints at different times or multiple processes may be working
together to accomplish some goal under a single constraint -- at least
both cases exist in the Android system as it ships today).

The exact naming of the API is not terribly important to us.  The
first thing we spent a bunch of time discussing last summer when Arve
first looked into sending wakelocks upstream was changing the name
because many objected to "wakelock" for various reasons.

Being able to have userful statistics (which drivers/processes/etc
held which wakelock for how long, how many times, etc) is important to
us.  While we want to do the best we can in the face of poorly written
apps, we also want to educate users and developers about which apps
are contributing to their poor battery life -- so users can decide to
uninstall an app if its usefulness does not justify its impact on
battery life and application developers can be more aware of what the
cost of their app is to endusers.

As an example, http://frotz.net/misc/battery-stats-unplugged.txt
contains a dump from the "battery service" aggregating wakelock usage,
cpu usage, and sensor device usage of processes (#....: sections) on
my phone the other day for a ~3 hour period.  This data is presented
visually to the enduser in a "what's using my battery" feature of the
platform.  "realtime" refers to wall clock time here and "uptime"
refers to not-in-suspend execution time.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
>
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

I think that the suspend block model can be viewed as a constraints
problem (similar to some of things things you've been sketching out in
these threads), but I think we (Google/Android) view it as more of a
state constraint (don't enter suspend) than a latency constraint.

We think there's a need for these constraints both from the driver
side and userspace side, and that these constraints are not tied to
processes (multiple entities in one process may have different
constraints at different times or multiple processes may be working
together to accomplish some goal under a single constraint -- at least
both cases exist in the Android system as it ships today).

The exact naming of the API is not terribly important to us.  The
first thing we spent a bunch of time discussing last summer when Arve
first looked into sending wakelocks upstream was changing the name
because many objected to "wakelock" for various reasons.

Being able to have userful statistics (which drivers/processes/etc
held which wakelock for how long, how many times, etc) is important to
us.  While we want to do the best we can in the face of poorly written
apps, we also want to educate users and developers about which apps
are contributing to their poor battery life -- so users can decide to
uninstall an app if its usefulness does not justify its impact on
battery life and application developers can be more aware of what the
cost of their app is to endusers.

As an example, http://frotz.net/misc/battery-stats-unplugged.txt
contains a dump from the "battery service" aggregating wakelock usage,
cpu usage, and sensor device usage of processes (#....: sections) on
my phone the other day for a ~3 hour period.  This data is presented
visually to the enduser in a "what's using my battery" feature of the
platform.  "realtime" refers to wall clock time here and "uptime"
refers to not-in-suspend execution time.

Brian

Re: Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Neil Brown <neilb@suse.de>:
> On Thu, 27 May 2010 02:07:21 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> >
>> >> of it into pm QoS stuff and if one day someone solves the rogue app
>> >> problem, we can migrate over.
>> >
>> > If it's so important for Android and no one else, Android can carry it
>> > out of tree.
>> >
>>
>> This is not only important for Android. If you use suspend on a
>> current Linux system you run the risk of loosing wakeup events. If you
>> have wakeup events that you cannot afford to lose your only option is
>> to never suspend. On some hardware (e.g. x86) the cost of not
>> suspending is always huge, on other hardware (many ARM SOCs) the cost
>> is only huge if your apps behave poorly.
>>
>
> So here is my suggestion.
> Rather than trying to push a feature that is clearly meeting lots of
> resistance, the Android devs should state the problem as a bug that needs
> fixing.  As you have.
> Upstream is a lot more receptive of fixing bugs than adding features.
>
> In this case the bug is that you cannot suspend without the risk of losing
> wakeup events.  This is a real bug that for your use case is a serious
> bug.  I've toyed with several ways of fixing this but the one that seems most
> promising is to note that in the kernel the suspend process is two-stage with
> a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction
> and so ends up with a race.
>
> Maybe userspace should be able to say "prepare to suspend" with the meaning
> that after a successful return, any event which would cause a wakeup sets a
> flag so that the final suspend returns immediately (without actually going to
> the lower power state).
>
> Then your opportunistic suspend could be entirely in userspace where you
> wouldn't have to fight with the kernel crowd :-)
> The suspend-daemon would:
>  Wait for all user-space suspend blocks to be dropped.
>  Tell the kernel to "prepare to suspend".
>  Tell all userspace programs which have registered for the message that they
>    should prepare to suspend.  They have the opportunity at this point to
>    take out a new suspend block if they notice an event that has
>    just arrived
>  Wait for all those programs to acknowledge
>  If there are no new suspend blocks, tell the kernel to suspend
>  else tell the kernel to abort the suspend.
>
> This (I think) allows race-free opportunistic suspend in user-space where
> you can do all the accounting you need.
>

Perhaps, but it forces all user space programs that get events from
the kernel to also receive messages from the suspend-daemon, check for
other events again, then respond to the suspend-daemon. The current
suspend blocker interface is easier to use. I don't see how your
suggestion avoids races for events that pass trough several kernel
layers though. If a wakeup event happened before the "prepare to
suspend" call but has not yet been passed to user-space, the
user-space program that needs this event will not know that it needs
to block suspend when it gets the prepare-to-suspend message.

> I don't fully understand your requirements for accounting of devices drivers
> rejecting or blocking a suspend, so I cannot say precisely how that would fit
> in.  Maybe you just need to know - whenever the 'suspend request' completes -
> what the wakeup events were.  It shouldn't be too hard to export that to
> user-space via sysfs.
>
> I won't propose an exact enhancement to the user-space interface for
> requesting a suspend, but I suspect it should expose each of
>  suspend_prepare
>  suspend_devices_and_enter
>  suspend_finish
> (or close analogues there-of) to user-space.  It is tempting to map those to
> "open-for-write", "write", "close", but I'm not sure that suspend_prepare
> would be appropriate if the app was about to write "disk" - it is a pity that
> both suspend and hibernate use the same sysfs file.
>
> So just fix the bug, and everyone will be happy :-)
>

I already have, but everyone do not appear to be happy.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > I still don't see how blocking applications will cause missed wakeups in
> > anything but a buggy application at worst, and even those will
> > eventually get the event when they unblock.
> > 
> > What seems to be the confusion?
> 
> During forced suspend, applications are block because they are frozen.
> 
> When an event occurs, the application is notified somehow.  But it 
> can't respond because it is frozen.  Hence the event remains sitting in 
> a kernel queue and the system goes ahead and suspends anyway.  The 
> application doesn't get thawed until the system wakes up at some 
> indefinite time in the future.

If the kernel is awake to put things in queues, we're clearly not
suspended and userspace is running ?!

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
> On Thu, 27 May 2010, Peter Zijlstra wrote:
> 
> > I still don't see how blocking applications will cause missed wakeups in
> > anything but a buggy application at worst, and even those will
> > eventually get the event when they unblock.
> > 
> > What seems to be the confusion?
> 
> During forced suspend, applications are block because they are frozen.
> 
> When an event occurs, the application is notified somehow.  But it 
> can't respond because it is frozen.  Hence the event remains sitting in 
> a kernel queue and the system goes ahead and suspends anyway.  The 
> application doesn't get thawed until the system wakes up at some 
> indefinite time in the future.

If the kernel is awake to put things in queues, we're clearly not
suspended and userspace is running ?!

Re: Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Neil Brown]

On Thu, 27 May 2010 21:57:02 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/27 Neil Brown <neilb@suse.de>:
> > On Thu, 27 May 2010 02:07:21 -0700
> > Arve Hjønnevåg <arve@android.com> wrote:
> >
> >> >
> >> >> of it into pm QoS stuff and if one day someone solves the rogue app
> >> >> problem, we can migrate over.
> >> >
> >> > If it's so important for Android and no one else, Android can carry it
> >> > out of tree.
> >> >
> >>
> >> This is not only important for Android. If you use suspend on a
> >> current Linux system you run the risk of loosing wakeup events. If you
> >> have wakeup events that you cannot afford to lose your only option is
> >> to never suspend. On some hardware (e.g. x86) the cost of not
> >> suspending is always huge, on other hardware (many ARM SOCs) the cost
> >> is only huge if your apps behave poorly.
> >>
> >
> > So here is my suggestion.
> > Rather than trying to push a feature that is clearly meeting lots of
> > resistance, the Android devs should state the problem as a bug that needs
> > fixing.  As you have.
> > Upstream is a lot more receptive of fixing bugs than adding features.
> >
> > In this case the bug is that you cannot suspend without the risk of losing
> > wakeup events.  This is a real bug that for your use case is a serious
> > bug.  I've toyed with several ways of fixing this but the one that seems most
> > promising is to note that in the kernel the suspend process is two-stage with
> > a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction
> > and so ends up with a race.
> >
> > Maybe userspace should be able to say "prepare to suspend" with the meaning
> > that after a successful return, any event which would cause a wakeup sets a
> > flag so that the final suspend returns immediately (without actually going to
> > the lower power state).
> >
> > Then your opportunistic suspend could be entirely in userspace where you
> > wouldn't have to fight with the kernel crowd :-)
> > The suspend-daemon would:
> >  Wait for all user-space suspend blocks to be dropped.
> >  Tell the kernel to "prepare to suspend".
> >  Tell all userspace programs which have registered for the message that they
> >    should prepare to suspend.  They have the opportunity at this point to
> >    take out a new suspend block if they notice an event that has
> >    just arrived
> >  Wait for all those programs to acknowledge
> >  If there are no new suspend blocks, tell the kernel to suspend
> >  else tell the kernel to abort the suspend.
> >
> > This (I think) allows race-free opportunistic suspend in user-space where
> > you can do all the accounting you need.
> >
> 
> Perhaps, but it forces all user space programs that get events from
> the kernel to also receive messages from the suspend-daemon, check for
> other events again, then respond to the suspend-daemon. The current
> suspend blocker interface is easier to use.

Maybe so.  There are quite possibly better ways to fix the bug.  There are a
variety of different tradeoffs possible and I suspect we could have fun
arguing about those.  My main point though is that if we focus on a bug that
needs to be fixed, we should be able to keep the conversation more focussed.
Currently it seems to be branching all over the place which doesn't seem very
helpful.

>                                              I don't see how your
> suggestion avoids races for events that pass trough several kernel
> layers though. If a wakeup event happened before the "prepare to
> suspend" call but has not yet been passed to user-space, the
> user-space program that needs this event will not know that it needs
> to block suspend when it gets the prepare-to-suspend message.

Each layer must understand that the event is a wake-up event, and the
"prepare to suspend call" to each layer should drive all pending events
through to the next layer.  If the layers (drivers) are prepared in the
"right" order, this will force the event all the way to user-space.  If they
are called in exactly the "Wrong" order, this will require multiple
prepare/suspend/instant-resume cycles to get the event through, but I suspect
that this would very rarely result in truly pathological behaviour.

I'm guessing your current code (sorry, I haven't looked at all) already tracks
events up through multiple layers so they can interact with a pending
opporunistic-suspend request.  I suspect that aspect of the code isn't
particularly controversial.
Keep that, and use it precisely to implement a race-free "suspend" request
from user-space.

> 
> > I don't fully understand your requirements for accounting of devices drivers
> > rejecting or blocking a suspend, so I cannot say precisely how that would fit
> > in.  Maybe you just need to know - whenever the 'suspend request' completes -
> > what the wakeup events were.  It shouldn't be too hard to export that to
> > user-space via sysfs.
> >
> > I won't propose an exact enhancement to the user-space interface for
> > requesting a suspend, but I suspect it should expose each of
> >  suspend_prepare
> >  suspend_devices_and_enter
> >  suspend_finish
> > (or close analogues there-of) to user-space.  It is tempting to map those to
> > "open-for-write", "write", "close", but I'm not sure that suspend_prepare
> > would be appropriate if the app was about to write "disk" - it is a pity that
> > both suspend and hibernate use the same sysfs file.
> >
> > So just fix the bug, and everyone will be happy :-)
> >
> 
> I already have, but everyone do not appear to be happy.
> 

I don't think you have.  You have proposed a significant new feature: a
suspend-as-soon-as-you-can request which *user*space*can*block*.  People
don't like that because it seems like a poor second cousin to something that
would be really useful (user-space setting more general latency
requirements).

I am suggesting that you stick with the feature we have, which is that
user-space can request a suspend and the kernel/hardware can cause a
subsequent (possibly immediate) resume in response to a wake-up event.
Argue that the current definition of "wake-up event" is too weak and does not
allow the feature to be used safely.  Present an implementation (I suspect you
have most of it already) where a wake-up event is tracked all the way from
the hardware to user-space and is still a 'wake-up event' until userspace
actually consumes it.

Then user-space simply has to:
  poll for event to be ready
  request suspend-block in user-space
  consume event
  handle event
  release suspend-block
  loop

No change to API.  No new concepts.  Simply a bug and a direct fix.

You probably want the "suspend" request to block until there are no pending
events (and then immediately fail if there were) so that there is no risk of
the suspend-daemon spinning asking of a suspend which appears to resume
immediately (until some other process sees an event and blocks suspend.

NeilBrown
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 10:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
>> On Thu, 27 May 2010, Peter Zijlstra wrote:
>>
>> > I still don't see how blocking applications will cause missed wakeups in
>> > anything but a buggy application at worst, and even those will
>> > eventually get the event when they unblock.
>> >
>> > What seems to be the confusion?
>>
>> During forced suspend, applications are block because they are frozen.
>>
>> When an event occurs, the application is notified somehow.  But it
>> can't respond because it is frozen.  Hence the event remains sitting in
>> a kernel queue and the system goes ahead and suspends anyway.  The
>> application doesn't get thawed until the system wakes up at some
>> indefinite time in the future.
>
> If the kernel is awake to put things in queues, we're clearly not
> suspended and userspace is running ?!

Suspend is not an atomic operation. User space is frozen before
freezable kernel threads both of these happen before drivers are
suspended.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 10:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
>> On Thu, 27 May 2010, Peter Zijlstra wrote:
>>
>> > I still don't see how blocking applications will cause missed wakeups in
>> > anything but a buggy application at worst, and even those will
>> > eventually get the event when they unblock.
>> >
>> > What seems to be the confusion?
>>
>> During forced suspend, applications are block because they are frozen.
>>
>> When an event occurs, the application is notified somehow.  But it
>> can't respond because it is frozen.  Hence the event remains sitting in
>> a kernel queue and the system goes ahead and suspends anyway.  The
>> application doesn't get thawed until the system wakes up at some
>> indefinite time in the future.
>
> If the kernel is awake to put things in queues, we're clearly not
> suspended and userspace is running ?!

Suspend is not an atomic operation. User space is frozen before
freezable kernel threads both of these happen before drivers are
suspended.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Thu, May 27, 2010 at 10:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
>> On Thu, 27 May 2010, Peter Zijlstra wrote:
>>
>> > I still don't see how blocking applications will cause missed wakeups in
>> > anything but a buggy application at worst, and even those will
>> > eventually get the event when they unblock.
>> >
>> > What seems to be the confusion?
>>
>> During forced suspend, applications are block because they are frozen.
>>
>> When an event occurs, the application is notified somehow.  But it
>> can't respond because it is frozen.  Hence the event remains sitting in
>> a kernel queue and the system goes ahead and suspends anyway.  The
>> application doesn't get thawed until the system wakes up at some
>> indefinite time in the future.
>
> If the kernel is awake to put things in queues, we're clearly not
> suspended and userspace is running ?!

Suspend is not an atomic operation. User space is frozen before
freezable kernel threads both of these happen before drivers are
suspended.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

2010/5/27 Neil Brown <neilb@suse.de>:
> On Thu, 27 May 2010 21:57:02 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> 2010/5/27 Neil Brown <neilb@suse.de>:
>> > On Thu, 27 May 2010 02:07:21 -0700
>> > Arve Hjønnevåg <arve@android.com> wrote:
>> >
>> >> >
>> >> >> of it into pm QoS stuff and if one day someone solves the rogue app
>> >> >> problem, we can migrate over.
>> >> >
>> >> > If it's so important for Android and no one else, Android can carry it
>> >> > out of tree.
>> >> >
>> >>
>> >> This is not only important for Android. If you use suspend on a
>> >> current Linux system you run the risk of loosing wakeup events. If you
>> >> have wakeup events that you cannot afford to lose your only option is
>> >> to never suspend. On some hardware (e.g. x86) the cost of not
>> >> suspending is always huge, on other hardware (many ARM SOCs) the cost
>> >> is only huge if your apps behave poorly.
>> >>
>> >
>> > So here is my suggestion.
>> > Rather than trying to push a feature that is clearly meeting lots of
>> > resistance, the Android devs should state the problem as a bug that needs
>> > fixing.  As you have.
>> > Upstream is a lot more receptive of fixing bugs than adding features.
>> >
>> > In this case the bug is that you cannot suspend without the risk of losing
>> > wakeup events.  This is a real bug that for your use case is a serious
>> > bug.  I've toyed with several ways of fixing this but the one that seems most
>> > promising is to note that in the kernel the suspend process is two-stage with
>> > a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction
>> > and so ends up with a race.
>> >
>> > Maybe userspace should be able to say "prepare to suspend" with the meaning
>> > that after a successful return, any event which would cause a wakeup sets a
>> > flag so that the final suspend returns immediately (without actually going to
>> > the lower power state).
>> >
>> > Then your opportunistic suspend could be entirely in userspace where you
>> > wouldn't have to fight with the kernel crowd :-)
>> > The suspend-daemon would:
>> >  Wait for all user-space suspend blocks to be dropped.
>> >  Tell the kernel to "prepare to suspend".
>> >  Tell all userspace programs which have registered for the message that they
>> >    should prepare to suspend.  They have the opportunity at this point to
>> >    take out a new suspend block if they notice an event that has
>> >    just arrived
>> >  Wait for all those programs to acknowledge
>> >  If there are no new suspend blocks, tell the kernel to suspend
>> >  else tell the kernel to abort the suspend.
>> >
>> > This (I think) allows race-free opportunistic suspend in user-space where
>> > you can do all the accounting you need.
>> >
>>
>> Perhaps, but it forces all user space programs that get events from
>> the kernel to also receive messages from the suspend-daemon, check for
>> other events again, then respond to the suspend-daemon. The current
>> suspend blocker interface is easier to use.
>
> Maybe so.  There are quite possibly better ways to fix the bug.  There are a
> variety of different tradeoffs possible and I suspect we could have fun
> arguing about those.  My main point though is that if we focus on a bug that
> needs to be fixed, we should be able to keep the conversation more focussed.
> Currently it seems to be branching all over the place which doesn't seem very
> helpful.
>
>>                                              I don't see how your
>> suggestion avoids races for events that pass trough several kernel
>> layers though. If a wakeup event happened before the "prepare to
>> suspend" call but has not yet been passed to user-space, the
>> user-space program that needs this event will not know that it needs
>> to block suspend when it gets the prepare-to-suspend message.
>
> Each layer must understand that the event is a wake-up event, and the
> "prepare to suspend call" to each layer should drive all pending events
> through to the next layer.  If the layers (drivers) are prepared in the
> "right" order, this will force the event all the way to user-space.  If they
> are called in exactly the "Wrong" order, this will require multiple
> prepare/suspend/instant-resume cycles to get the event through, but I suspect
> that this would very rarely result in truly pathological behaviour.
>
> I'm guessing your current code (sorry, I haven't looked at all) already tracks
> events up through multiple layers so they can interact with a pending
> opporunistic-suspend request.  I suspect that aspect of the code isn't
> particularly controversial.
> Keep that, and use it precisely to implement a race-free "suspend" request
> from user-space.
>
>>
>> > I don't fully understand your requirements for accounting of devices drivers
>> > rejecting or blocking a suspend, so I cannot say precisely how that would fit
>> > in.  Maybe you just need to know - whenever the 'suspend request' completes -
>> > what the wakeup events were.  It shouldn't be too hard to export that to
>> > user-space via sysfs.
>> >
>> > I won't propose an exact enhancement to the user-space interface for
>> > requesting a suspend, but I suspect it should expose each of
>> >  suspend_prepare
>> >  suspend_devices_and_enter
>> >  suspend_finish
>> > (or close analogues there-of) to user-space.  It is tempting to map those to
>> > "open-for-write", "write", "close", but I'm not sure that suspend_prepare
>> > would be appropriate if the app was about to write "disk" - it is a pity that
>> > both suspend and hibernate use the same sysfs file.
>> >
>> > So just fix the bug, and everyone will be happy :-)
>> >
>>
>> I already have, but everyone do not appear to be happy.
>>
>
> I don't think you have.  You have proposed a significant new feature: a
> suspend-as-soon-as-you-can request which *user*space*can*block*.  People
> don't like that because it seems like a poor second cousin to something that
> would be really useful (user-space setting more general latency
> requirements).
>

The ability to block the suspend request is necessary to avoid races
with wakeup events.

> I am suggesting that you stick with the feature we have, which is that
> user-space can request a suspend and the kernel/hardware can cause a
> subsequent (possibly immediate) resume in response to a wake-up event.

Since not all wakeup events propagate to user-space it is very useful
to allow the kernel to reenter suspend when there are no active
suspend blockers remaining.

> Argue that the current definition of "wake-up event" is too weak and does not
> allow the feature to be used safely.  Present an implementation (I suspect you
> have most of it already) where a wake-up event is tracked all the way from
> the hardware to user-space and is still a 'wake-up event' until userspace
> actually consumes it.
>
> Then user-space simply has to:
>  poll for event to be ready
>  request suspend-block in user-space
>  consume event
>  handle event
>  release suspend-block
>  loop

This you copy this from the example in the documentation file added by
this patch? This is exactly what we do for input events, but for this
to work the kernel also has to block suspend while an event is ready
but not consumed.

>
> No change to API.  No new concepts.  Simply a bug and a direct fix.
>
I don't know how you got to that conclusion.

> You probably want the "suspend" request to block until there are no pending
> events (and then immediately fail if there were) so that there is no risk of
> the suspend-daemon spinning asking of a suspend which appears to resume
> immediately (until some other process sees an event and blocks suspend.
>
> NeilBrown
>

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 21:55:26 -0700
Brian Swetland <swetland@google.com> wrote:

> On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > This started because the Android people came to a meeting that was put
> > together of various folks to try and sort of the big blockage in getting
> > Android and Linux kernels back towards merging.
> >
> > I am interested right now in finding a general solution to the Android
> > case and the fact it looks very similar to the VM, hard RT, gamer and
> > other related problems although we seem to have diverged from that logic.
> 
> I think that the suspend block model can be viewed as a constraints
> problem (similar to some of things things you've been sketching out in
> these threads), but I think we (Google/Android) view it as more of a
> state constraint (don't enter suspend) than a latency constraint.
> 
> We think there's a need for these constraints both from the driver
> side and userspace side, and that these constraints are not tied to
> processes (multiple entities in one process may have different
> constraints at different times or multiple processes may be working
> together to accomplish some goal under a single constraint -- at least
> both cases exist in the Android system as it ships today).
> 
> The exact naming of the API is not terribly important to us.  The
> first thing we spent a bunch of time discussing last summer when Arve
> first looked into sending wakelocks upstream was changing the name
> because many objected to "wakelock" for various reasons.
> 
> Being able to have userful statistics (which drivers/processes/etc
> held which wakelock for how long, how many times, etc) is important to
> us.  While we want to do the best we can in the face of poorly written
> apps, we also want to educate users and developers about which apps
> are contributing to their poor battery life -- so users can decide to
> uninstall an app if its usefulness does not justify its impact on
> battery life and application developers can be more aware of what the
> cost of their app is to endusers.
> 
> As an example, http://frotz.net/misc/battery-stats-unplugged.txt
> contains a dump from the "battery service" aggregating wakelock usage,
> cpu usage, and sensor device usage of processes (#....: sections) on
> my phone the other day for a ~3 hour period.  This data is presented
> visually to the enduser in a "what's using my battery" feature of the
> platform.  "realtime" refers to wall clock time here and "uptime"
> refers to not-in-suspend execution time.
> 
> Brian


Hi!
Thinking about the issue a little more, this isn't really about trusted
apps and not trusted apps. Or crapplications. 

The point is, that as soon as an app takes a suspend-blocker it becomes
 what is here referred to as a "trusted app". But just because it is then visible as
consuming power in an official way. 

Android suspends (as in echo mem > /sys/power/state)
whenever possible. It's as if there were a spring on the laptop lid,
and if the user doesnt hold his grip on it, the thing closes. How does
he hold his grip? The application registers a suspend-blocker for him.

So, why not use something like idle/QOS with this? 

I can imagine to theoretically have a "latency requirement" where 0
means this application does not interact with the user. and != 0 means
this application interacts with the user.

("latency requirement" doesn't quite get it, but it works for now)

In android land, the default would be that every application has a
latency-requirement of 0. And then everything (userland) that takes a
suspend-blocker would be changed to take a "latency requirement != 0". 

Now, if the system interacts with the user
( i.e. there is a global
latency requirement > 0, where "global latency requirement" is
computed by the pm framework maxing over all the userland processes
and the kernel side)
everything has to run. So we also need to schedule things which specify 
a latency requirement == 0.

This last thing means, that it has to be independent of the scheduler, doesn't it?

I don't see how renaming suspend_blocker to set_pidle would not do
something equivalent to this, but the bit's are probably a bit scattered
throughout the kernel. 
(Which I don't think is introduced by that patch set, but by the fact that 
suspend is currently not an idle state.)

I can understand if there needs to be a good solution in the kernel
from day 1. 

So, what would compose to a good solution? 

Here should probably the more experienced people jump in, but let me express 
what i've gathered in this discussion (especially from Thomas and Alan Cox):

1. change suspend framework to be "just another idle state"
2. specify that "just another idle state" can only be entered if
"global latency requirement" == 0
3. probably add some cost-estimate-computation to the "just another
idle state"

(the trick here is, that this idle-state ignores all current measures of "idle", 
so the cost for this would only depend on the cost-estimate to enter it and 
the suspend-power-usage. which also means it is probably 'opportune' to enter it, whenever possible, 
except the machine is idle the old way already (because the cost to enter is bigger))

4. change the userspace suspend interface 
	i.e. echo mem > /sys/power/state to override the "global
	latency requirement" to be 0.

5. convert the drivers to relax their latency-requirement to be 0
whenever possible. (in android land, this is already done, probably just needs a 
s/suspend_block/set_pidle(1)/ )
6. enhance the cpufreq drivers to take global latency requirement into
view. (i.e. opportunistic suspend would be implemented in the proper place,
 don't know which that is, please chime in)

So, what specifically would have to be done to the suspend blockers patches?
And can it be done incrementally? (I guess the answer is no, we don't want this done 
in the kernel , we want it done right?)

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 21:55:26 -0700
Brian Swetland <swetland@google.com> wrote:

> On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > This started because the Android people came to a meeting that was put
> > together of various folks to try and sort of the big blockage in getting
> > Android and Linux kernels back towards merging.
> >
> > I am interested right now in finding a general solution to the Android
> > case and the fact it looks very similar to the VM, hard RT, gamer and
> > other related problems although we seem to have diverged from that logic.
> 
> I think that the suspend block model can be viewed as a constraints
> problem (similar to some of things things you've been sketching out in
> these threads), but I think we (Google/Android) view it as more of a
> state constraint (don't enter suspend) than a latency constraint.
> 
> We think there's a need for these constraints both from the driver
> side and userspace side, and that these constraints are not tied to
> processes (multiple entities in one process may have different
> constraints at different times or multiple processes may be working
> together to accomplish some goal under a single constraint -- at least
> both cases exist in the Android system as it ships today).
> 
> The exact naming of the API is not terribly important to us.  The
> first thing we spent a bunch of time discussing last summer when Arve
> first looked into sending wakelocks upstream was changing the name
> because many objected to "wakelock" for various reasons.
> 
> Being able to have userful statistics (which drivers/processes/etc
> held which wakelock for how long, how many times, etc) is important to
> us.  While we want to do the best we can in the face of poorly written
> apps, we also want to educate users and developers about which apps
> are contributing to their poor battery life -- so users can decide to
> uninstall an app if its usefulness does not justify its impact on
> battery life and application developers can be more aware of what the
> cost of their app is to endusers.
> 
> As an example, http://frotz.net/misc/battery-stats-unplugged.txt
> contains a dump from the "battery service" aggregating wakelock usage,
> cpu usage, and sensor device usage of processes (#....: sections) on
> my phone the other day for a ~3 hour period.  This data is presented
> visually to the enduser in a "what's using my battery" feature of the
> platform.  "realtime" refers to wall clock time here and "uptime"
> refers to not-in-suspend execution time.
> 
> Brian


Hi!
Thinking about the issue a little more, this isn't really about trusted
apps and not trusted apps. Or crapplications. 

The point is, that as soon as an app takes a suspend-blocker it becomes
 what is here referred to as a "trusted app". But just because it is then visible as
consuming power in an official way. 

Android suspends (as in echo mem > /sys/power/state)
whenever possible. It's as if there were a spring on the laptop lid,
and if the user doesnt hold his grip on it, the thing closes. How does
he hold his grip? The application registers a suspend-blocker for him.

So, why not use something like idle/QOS with this? 

I can imagine to theoretically have a "latency requirement" where 0
means this application does not interact with the user. and != 0 means
this application interacts with the user.

("latency requirement" doesn't quite get it, but it works for now)

In android land, the default would be that every application has a
latency-requirement of 0. And then everything (userland) that takes a
suspend-blocker would be changed to take a "latency requirement != 0". 

Now, if the system interacts with the user
( i.e. there is a global
latency requirement > 0, where "global latency requirement" is
computed by the pm framework maxing over all the userland processes
and the kernel side)
everything has to run. So we also need to schedule things which specify 
a latency requirement == 0.

This last thing means, that it has to be independent of the scheduler, doesn't it?

I don't see how renaming suspend_blocker to set_pidle would not do
something equivalent to this, but the bit's are probably a bit scattered
throughout the kernel. 
(Which I don't think is introduced by that patch set, but by the fact that 
suspend is currently not an idle state.)

I can understand if there needs to be a good solution in the kernel
from day 1. 

So, what would compose to a good solution? 

Here should probably the more experienced people jump in, but let me express 
what i've gathered in this discussion (especially from Thomas and Alan Cox):

1. change suspend framework to be "just another idle state"
2. specify that "just another idle state" can only be entered if
"global latency requirement" == 0
3. probably add some cost-estimate-computation to the "just another
idle state"

(the trick here is, that this idle-state ignores all current measures of "idle", 
so the cost for this would only depend on the cost-estimate to enter it and 
the suspend-power-usage. which also means it is probably 'opportune' to enter it, whenever possible, 
except the machine is idle the old way already (because the cost to enter is bigger))

4. change the userspace suspend interface 
	i.e. echo mem > /sys/power/state to override the "global
	latency requirement" to be 0.

5. convert the drivers to relax their latency-requirement to be 0
whenever possible. (in android land, this is already done, probably just needs a 
s/suspend_block/set_pidle(1)/ )
6. enhance the cpufreq drivers to take global latency requirement into
view. (i.e. opportunistic suspend would be implemented in the proper place,
 don't know which that is, please chime in)

So, what specifically would have to be done to the suspend blockers patches?
And can it be done incrementally? (I guess the answer is no, we don't want this done 
in the kernel , we want it done right?)

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 22:09:37 -0400
Ben Gamari <bgamari.foss@gmail.com> wrote:

> On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler <florian@mickler.org> wrote:
> > Because he is using a robust kernel that provides suspend blockers and
> > is preventing the vampire from sucking power? 
> > 
> Suspend blockers are only a flawed and indirect way to keep the vampire
> from sucking.
> 



> > Most users don't even grasp the simple concept of different "programs".
> > They just have a device and click here and there and are happy. 
> > 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> 
> He's getting at the fact that there are much better ways to deal with
> this problem. The issue here is that we seem to be expected to swallow
> whatever Google throws at us, regardless of the quality of the
> solution. It seems like the best argument we have for merging is "we
> couldn't think of anything better and we need it yesterday." This might be
> a good enough reason for shipping, but it certainly doesn't satisfy the
> requirements for merging.

I don't disagree on the quality. But I don't think it is because of the
patches, but because of how the kernel is architectured in that area
(suspend not being an idle state).

Look, probably suspend needs to be integrated into the idle states and
used from there. I could imagine a cost-specification for idle states:

c3
	cost-to-transition-to-this-state: X 
	powersavings-per-time: Y
	expected time we stay in this state: relative short, there is a
	timer sheduled
	suspend-blockers: ignored

suspend 
	cost-to-transition-to-this-state: depends, how much drivers to
	suspend, how much processes to freeze, ...
	powersavings-per-time: Y
	expected time we stay in this state: long, independent of
	sheduled timers
	suspend-blockers: need not be activated

Now, a governor could compute if it is ok, to enter suspend or only
wait for idle-c3. And maybe it would never transition from idle-c3 to
suspend but only from c1. because the cost to enter suspend would mean
it just has to go to c1 anyway.

what do ya think?

> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> It is absolutely not. If you want to keep power usage down, then
> implement real resource management in the scheduler. Suspend blockers
> are nothing but a clunky and ineffective means of resource allocation.
> As has been pointed out in this thread, there are much better ways of
> dealing with this problem.
> 
> - Ben

I think this has to be independently to the scheduler, because as soon
as the user interacts with the phone, everything needs to be scheduled.
even the stuff that doesn't directly interact with the user.
as soon as _nothing_ interacts with the user, the phone does schedule
_nothing_ anymore.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 22:09:37 -0400
Ben Gamari <bgamari.foss@gmail.com> wrote:

> On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler <florian@mickler.org> wrote:
> > Because he is using a robust kernel that provides suspend blockers and
> > is preventing the vampire from sucking power? 
> > 
> Suspend blockers are only a flawed and indirect way to keep the vampire
> from sucking.
> 



> > Most users don't even grasp the simple concept of different "programs".
> > They just have a device and click here and there and are happy. 
> > 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> 
> He's getting at the fact that there are much better ways to deal with
> this problem. The issue here is that we seem to be expected to swallow
> whatever Google throws at us, regardless of the quality of the
> solution. It seems like the best argument we have for merging is "we
> couldn't think of anything better and we need it yesterday." This might be
> a good enough reason for shipping, but it certainly doesn't satisfy the
> requirements for merging.

I don't disagree on the quality. But I don't think it is because of the
patches, but because of how the kernel is architectured in that area
(suspend not being an idle state).

Look, probably suspend needs to be integrated into the idle states and
used from there. I could imagine a cost-specification for idle states:

c3
	cost-to-transition-to-this-state: X 
	powersavings-per-time: Y
	expected time we stay in this state: relative short, there is a
	timer sheduled
	suspend-blockers: ignored

suspend 
	cost-to-transition-to-this-state: depends, how much drivers to
	suspend, how much processes to freeze, ...
	powersavings-per-time: Y
	expected time we stay in this state: long, independent of
	sheduled timers
	suspend-blockers: need not be activated

Now, a governor could compute if it is ok, to enter suspend or only
wait for idle-c3. And maybe it would never transition from idle-c3 to
suspend but only from c1. because the cost to enter suspend would mean
it just has to go to c1 anyway.

what do ya think?

> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> It is absolutely not. If you want to keep power usage down, then
> implement real resource management in the scheduler. Suspend blockers
> are nothing but a clunky and ineffective means of resource allocation.
> As has been pointed out in this thread, there are much better ways of
> dealing with this problem.
> 
> - Ben

I think this has to be independently to the scheduler, because as soon
as the user interacts with the phone, everything needs to be scheduled.
even the stuff that doesn't directly interact with the user.
as soon as _nothing_ interacts with the user, the phone does schedule
_nothing_ anymore.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
> Keep in mind, though, that a solution which is acceptable for Android
> has to include making sure that crappy applications don't cause the
> battery to get drained.  There seem to be some people who seem
> adamently against this requirement.  

Again, Alan, Thomas and myself don't argue against that, what we do
however argue against is suspend running apps as a form of power
management.

If you were to read Alan's latest posts he clearly outlines how you can
contain crappy apps.

A combination of weakening QoS guarantees (delaying wakeups etc.)
blocking on resources (delay servicing requests) and monitoring resource
usage (despite all that its still not idle) and taking affirmative
action (shoot it in the head).

If we pose that a well behaved application is one that listens to the
environment hints and idles when told to, we can let regular power
management kick in and let deep idle states do their thing.

If a bad application ignores those hints and manages to avoid getting
blocked on denied resources, we can easily spot it and promote an
attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM
and SIGKILL, possibly coupled with a pop-up dialog -- much like we get
today when we try to close a window and the app isn't responding.

If we then also let the environment maintain a shitlist of crappy apps
(those it had to take affirmative action against) and maybe set up a
service that allows people to share their results, it provides an
incentive to the app developers to fix their thing.

How is this not working?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
> Keep in mind, though, that a solution which is acceptable for Android
> has to include making sure that crappy applications don't cause the
> battery to get drained.  There seem to be some people who seem
> adamently against this requirement.  

Again, Alan, Thomas and myself don't argue against that, what we do
however argue against is suspend running apps as a form of power
management.

If you were to read Alan's latest posts he clearly outlines how you can
contain crappy apps.

A combination of weakening QoS guarantees (delaying wakeups etc.)
blocking on resources (delay servicing requests) and monitoring resource
usage (despite all that its still not idle) and taking affirmative
action (shoot it in the head).

If we pose that a well behaved application is one that listens to the
environment hints and idles when told to, we can let regular power
management kick in and let deep idle states do their thing.

If a bad application ignores those hints and manages to avoid getting
blocked on denied resources, we can easily spot it and promote an
attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM
and SIGKILL, possibly coupled with a pop-up dialog -- much like we get
today when we try to close a window and the app isn't responding.

If we then also let the environment maintain a shitlist of crappy apps
(those it had to take affirmative action against) and maybe set up a
service that allows people to share their results, it provides an
incentive to the app developers to fix their thing.

How is this not working?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> 
> > > And the forced-suspend design relies on the fact that processes remain 
> > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > somehow becomes runnable, that means we have to abort the forced 
> > > suspend before the process is allowed to run.
> > 
> > We could avoid that if drivers could block tasks, but there are questions to
> > answer.  First off, how a driver is supposed to know when to block the task
> > using it and when to do its power management transparently for the task?
> > Second, how to intercept and block all possible interfaces that user space
> > can use to talk to drivers (how to intercept a task using mmapped device, for
> > example)?
> 
> We talked about this a few years ago and decided it was not feasible.  
> It would require substantial changes to every device driver.

But what if its the _right_ thing to do? We make changes to every device
driver out there on a regular basis. Also, why won't an incremental
process work? Add the interface with a fallback for drivers that haven't
implemented it and implement it for those drivers its most urgent (like
those in use on an Android phone).

Not doing the right thing simply because its a lot of work seems like a
fine way to let the kernel rot into an unmaintainable mess.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> 
> > > And the forced-suspend design relies on the fact that processes remain 
> > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > somehow becomes runnable, that means we have to abort the forced 
> > > suspend before the process is allowed to run.
> > 
> > We could avoid that if drivers could block tasks, but there are questions to
> > answer.  First off, how a driver is supposed to know when to block the task
> > using it and when to do its power management transparently for the task?
> > Second, how to intercept and block all possible interfaces that user space
> > can use to talk to drivers (how to intercept a task using mmapped device, for
> > example)?
> 
> We talked about this a few years ago and decided it was not feasible.  
> It would require substantial changes to every device driver.

But what if its the _right_ thing to do? We make changes to every device
driver out there on a regular basis. Also, why won't an incremental
process work? Add the interface with a fallback for drivers that haven't
implemented it and implement it for those drivers its most urgent (like
those in use on an Android phone).

Not doing the right thing simply because its a lot of work seems like a
fine way to let the kernel rot into an unmaintainable mess.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 15:35:18 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 27 May 2010, Florian Mickler wrote:
> 
> > On Wed, 26 May 2010 22:03:37 +0200
> > Vitaly Wool <vitalywool@gmail.com> wrote:
> > 
> > > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> > > 
> > > > Your approach definitely sounds better than the current solution.
> > > > What about mapping suspend blocker functionality later on, when this
> > > > interface exists, on to this new approach and deprecating it?
> > > 
> > > What about coming back after some while with the appropriate solution
> > > when it's ready instead of stubbornly pushing crap?
> > > 
> > > ~Vitaly
> > 
> > Because quite frankly, for a good part of linux users, suspend blockers
> > is already in the kernel. It's just an historical mistake that they are
> > not in the linux kernel's hosted on kernel.org. 
> 
> No, it's not a historical mistake. It's a technical decision _NOT_ to
> merge crap. If we would accept every crappy patch which gets shipped
> in large quantities as a defacto part of the kernel we would have a
> completely unmaintainable mess since years.
> > So why don't we do what we always do? Improve existing interfaces step
> > by step? 
> 
> Exactly, that's what we are going to do. We improve and extend
> existing interfaces step by step, but not by creating a horrible and
> unmaintainable mess in the frist place which we can never get rid of
> anymore.

Ok to your two paragraphs. I can understand this. 

Nonetheless, i'm convinced that there has to be some solution in
mainline to allow for what android does. But perhaps it needs more
refactoring and piggybagging on some more general constraint interface.

> 
> > Top Down approaches fail from time to time. Also it is not clear, that
> > that proposed interface works for the use cases. This has to be proven
> > by providing an implementation. 
> 
> Nobody prevents you to sit down and start with a prove of concept
> implementation.

Hmm... *scratch*... *lookaround* .. who?

Really, I'd first like to get the whole picture before doing anything.

> 
> Thanks,
> 
> 	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 15:35:18 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 27 May 2010, Florian Mickler wrote:
> 
> > On Wed, 26 May 2010 22:03:37 +0200
> > Vitaly Wool <vitalywool@gmail.com> wrote:
> > 
> > > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@mickler.org> wrote:
> > > 
> > > > Your approach definitely sounds better than the current solution.
> > > > What about mapping suspend blocker functionality later on, when this
> > > > interface exists, on to this new approach and deprecating it?
> > > 
> > > What about coming back after some while with the appropriate solution
> > > when it's ready instead of stubbornly pushing crap?
> > > 
> > > ~Vitaly
> > 
> > Because quite frankly, for a good part of linux users, suspend blockers
> > is already in the kernel. It's just an historical mistake that they are
> > not in the linux kernel's hosted on kernel.org. 
> 
> No, it's not a historical mistake. It's a technical decision _NOT_ to
> merge crap. If we would accept every crappy patch which gets shipped
> in large quantities as a defacto part of the kernel we would have a
> completely unmaintainable mess since years.
> > So why don't we do what we always do? Improve existing interfaces step
> > by step? 
> 
> Exactly, that's what we are going to do. We improve and extend
> existing interfaces step by step, but not by creating a horrible and
> unmaintainable mess in the frist place which we can never get rid of
> anymore.

Ok to your two paragraphs. I can understand this. 

Nonetheless, i'm convinced that there has to be some solution in
mainline to allow for what android does. But perhaps it needs more
refactoring and piggybagging on some more general constraint interface.

> 
> > Top Down approaches fail from time to time. Also it is not clear, that
> > that proposed interface works for the use cases. This has to be proven
> > by providing an implementation. 
> 
> Nobody prevents you to sit down and start with a prove of concept
> implementation.

Hmm... *scratch*... *lookaround* .. who?

Really, I'd first like to get the whole picture before doing anything.

> 
> Thanks,
> 
> 	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?

I'm not sure we need or want to go there.

Why not simply let upatedb block on its IO because its QoS policy tells
us that its IO priority is idle. Therefore it will not avoid the IO
device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?

I'm not sure we need or want to go there.

Why not simply let upatedb block on its IO because its QoS policy tells
us that its IO priority is idle. Therefore it will not avoid the IO
device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
> What happens if the user presses the button right before you set QoS
> of 'user apps' to  QS_NONE?
> To me it looks like this solution would result in this sequence which
> may ignore the button press:
>         Button pushed
>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>         Set QoS of 'user apps' to QS_NONE 

I don't think we should change app QoS parameters, but change service
provider parameters.

For instance, suppose the filesystem-IO QoS has 3 levels: 
  High, Normal and Idle.

Then if we assign Idle to updatedb, we'll service it as long as the
filesystem-server QoS has a higher level (High and Normal). When we
change the filesystem-serves' QoS to idle, it finds there is nothing to
keep it servicing stuff and it'll block pending requests, updatedb stops
being runnable and we're good.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
> What happens if the user presses the button right before you set QoS
> of 'user apps' to  QS_NONE?
> To me it looks like this solution would result in this sequence which
> may ignore the button press:
>         Button pushed
>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>         Set QoS of 'user apps' to QS_NONE 

I don't think we should change app QoS parameters, but change service
provider parameters.

For instance, suppose the filesystem-IO QoS has 3 levels: 
  High, Normal and Idle.

Then if we assign Idle to updatedb, we'll service it as long as the
filesystem-server QoS has a higher level (High and Normal). When we
change the filesystem-serves' QoS to idle, it finds there is nothing to
keep it servicing stuff and it'll block pending requests, updatedb stops
being runnable and we're good.



_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 17:49 -0700, Mike Chan wrote:
> Even if we used the proposed QoS replacement, are there suggestions on
> how to keep the cpu idle for longer than 2 seconds in Linux without
> using suspend?

What exactly is stopping it from being idle?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Thu, 2010-05-27 at 17:49 -0700, Mike Chan wrote:
> Even if we used the proposed QoS replacement, are there suggestions on
> how to keep the cpu idle for longer than 2 seconds in Linux without
> using suspend?

What exactly is stopping it from being idle?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > > The two of you are talking at cross purposes.  Thomas is referring to 
> > > idle-based suspend and Matthew is talking about forced suspend.
> > 
> > Yes, and forced suspend to disk is the same as force suspend to disk,
> > which has both nothing to do with sensible resource management.
> 
> If I understand correctly, you are saying that all the untrusted 
> applications should run with QoS(NONE).  Then they could do whatever 
> they wanted without causing any interference.
> 
> And with idle-based power management (rather than forced suspend), 
> there would be no issue with wakeup events getting unduly delayed.
> 
> Unless one of those events was meant for an untrusted application.  Is 
> that the source of the difficulty?

Probably, but that's not solved by suspend blockers either as I
explained several times now. Because those untrusted apps either lack
blocker calls or are not allowed to use them, so the blocker does not
help for those either.

Thanks,

	tglx

Re: [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Thomas Gleixner wrote:
> 
> > > The two of you are talking at cross purposes.  Thomas is referring to 
> > > idle-based suspend and Matthew is talking about forced suspend.
> > 
> > Yes, and forced suspend to disk is the same as force suspend to disk,
> > which has both nothing to do with sensible resource management.
> 
> If I understand correctly, you are saying that all the untrusted 
> applications should run with QoS(NONE).  Then they could do whatever 
> they wanted without causing any interference.
> 
> And with idle-based power management (rather than forced suspend), 
> there would be no issue with wakeup events getting unduly delayed.
> 
> Unless one of those events was meant for an untrusted application.  Is 
> that the source of the difficulty?

Probably, but that's not solved by suspend blockers either as I
explained several times now. Because those untrusted apps either lack
blocker calls or are not allowed to use them, so the blocker does not
help for those either.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 27 May 2010, Matthew Garrett wrote:
> 
> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> > 
> > > Oh no. They paper over a short coming. If there is a pending event,
> > > the kernel knows that. It just does not make use of this
> > > information. Blockers just paper over this by sprinkling
> > > do_not_suspend() calls all over the place. What a sensible solution.
> > 
> > Even if we could use suspend-via-deep-idle-state on PCs, we still need 
> > to be able to enter suspend while the system isn't idle. There's two 
> > ways to do that:
> > 
> > 1) Force the system to be idle. Doing this race-free is difficult.
> > 
> > 2) Enter suspend even though the system isn't idle. Since we can't rely 
> > on the scheduler, we need drivers to know whether userspace has consumed 
> > all wakeup events before allowing the transition to occur. Doing so 
> > requires either in-kernel suspend blockers or something that's almost 
> > identical.
> 
> You're just not getting it. If user space has consumed the event is
> not relevant at all.
> 
> What's relevant is whether the app has processed the event and reacted
> accordingly. That's all that matters.
> 
> Emptying your input queue is just the wrong indicator.
> 
> And as I explained several times now: It does _NOT_ matter when the
> app goes back in to blocked/idle state. You have to spend the CPU
> cycles and power for that anyway.
> 
> And for the apps which do not use the user space blockers the queue
> empty indicator is just bullshit, because after emptying the queue the
> kernel can go into suspend w/o any guarantee that the event has been
> processed.
> 
> The whole concept sucks, as it does not solve anything. Burning power
> now or in 100ms is the same thing power consumption wise.
> 
> Thanks,
> 
> 	tglx

Thomas,
do you really have a problem with the actual concept? Or do you just
don't like the way it is done?

IMO, the whole concept is defining 2 modes of operation: 

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

In case 1. the device wants _everything_ sheduled as normal (and save
maximum possible power, i.e. runtime pm with every technology available
now).

In case 2. we want nothing sheduled (and save maximum possible power,
i.e. suspend)

And now, every application and every kernel driver annotates (on behalve
of the user) if it (possibly) interacts with the user. 

(Is this really the problematic bit, that userspace is giving
the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the
user.

To integrate this with the current way of doing things, i gathered it 
needs to be implemented as an idle-state that does the suspend()-call?

Attributes of the idle states could be smth like this:

c3
	cost-to-transition-to-this-state: X 
	powersavings-per-time: Y
	expected time we stay in this state: relative short, there is a
		timer sheduled
	suspend-blockers: ignored

suspend 
	cost-to-transition-to-this-state: depends, how much drivers to
	suspend, how much processes to freeze, how much state to save
	powersavings-per-time: Y
	expected time we stay in this state: long, independent of
		sheduled timers
	suspend-blockers: must not be activated


Now all transitions and opportunistic suspend could be handled by the
same algorithms.

Would this work?


Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 27 May 2010, Matthew Garrett wrote:
> 
> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> > 
> > > Oh no. They paper over a short coming. If there is a pending event,
> > > the kernel knows that. It just does not make use of this
> > > information. Blockers just paper over this by sprinkling
> > > do_not_suspend() calls all over the place. What a sensible solution.
> > 
> > Even if we could use suspend-via-deep-idle-state on PCs, we still need 
> > to be able to enter suspend while the system isn't idle. There's two 
> > ways to do that:
> > 
> > 1) Force the system to be idle. Doing this race-free is difficult.
> > 
> > 2) Enter suspend even though the system isn't idle. Since we can't rely 
> > on the scheduler, we need drivers to know whether userspace has consumed 
> > all wakeup events before allowing the transition to occur. Doing so 
> > requires either in-kernel suspend blockers or something that's almost 
> > identical.
> 
> You're just not getting it. If user space has consumed the event is
> not relevant at all.
> 
> What's relevant is whether the app has processed the event and reacted
> accordingly. That's all that matters.
> 
> Emptying your input queue is just the wrong indicator.
> 
> And as I explained several times now: It does _NOT_ matter when the
> app goes back in to blocked/idle state. You have to spend the CPU
> cycles and power for that anyway.
> 
> And for the apps which do not use the user space blockers the queue
> empty indicator is just bullshit, because after emptying the queue the
> kernel can go into suspend w/o any guarantee that the event has been
> processed.
> 
> The whole concept sucks, as it does not solve anything. Burning power
> now or in 100ms is the same thing power consumption wise.
> 
> Thanks,
> 
> 	tglx

Thomas,
do you really have a problem with the actual concept? Or do you just
don't like the way it is done?

IMO, the whole concept is defining 2 modes of operation: 

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

In case 1. the device wants _everything_ sheduled as normal (and save
maximum possible power, i.e. runtime pm with every technology available
now).

In case 2. we want nothing sheduled (and save maximum possible power,
i.e. suspend)

And now, every application and every kernel driver annotates (on behalve
of the user) if it (possibly) interacts with the user. 

(Is this really the problematic bit, that userspace is giving
the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the
user.

To integrate this with the current way of doing things, i gathered it 
needs to be implemented as an idle-state that does the suspend()-call?

Attributes of the idle states could be smth like this:

c3
	cost-to-transition-to-this-state: X 
	powersavings-per-time: Y
	expected time we stay in this state: relative short, there is a
		timer sheduled
	suspend-blockers: ignored

suspend 
	cost-to-transition-to-this-state: depends, how much drivers to
	suspend, how much processes to freeze, how much state to save
	powersavings-per-time: Y
	expected time we stay in this state: long, independent of
		sheduled timers
	suspend-blockers: must not be activated


Now all transitions and opportunistic suspend could be handled by the
same algorithms.

Would this work?


Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Android does not only run on phones. It is possible that no android
> devices have ACPI, but I don't know that for a fact. What I do know is
> that people want to run Android on x86 hardware and supporting suspend
> could be very benficial.

Sufficently beneficial to justify putting all this stuff all over the
kernel and apps ? That is a *very* high hurdle, doubly so when those
vendors who have chosen to be part of the community are shipping phones
and PDAs just fine without them.
 
> > I would imagine the existing laptops will handle power management limited
> > by the functionality they have available. Just like any other piece of
> > hardware.
> 
> I think existing laptops (and desktops) can benefit from opportunistic
> suspend support. If opportunistic suspend is used for auto-sleep after
> inactivity instead of forced suspend, the user space suspend blocker
> api will allow an application to delay this auto sleep until for
> instance a download completes. This part could also be done with a

This assumes you modify all the applications. That isn't going to happen.
The hardware is going to catch up anyway.

> alarms. I know my desktops can wakeup at a specific time by
> programming an RTC alarm, but without suspend blockers how do you
> ensure that the system does not suspend right after the alarm
> triggered? I have a system that wakes up at specific times requested

How do you know that isn't the correct behavior. My laptop behaves in
that way if for example the battery is almost flat. Your suspend blocker
would cause me to lose all my work with a flat battery. This is another
example of why the application must not be the policy manager.

In the normal case in the PC world outside of corner cases like flat
batteries the answer is really simple. The laptop suspend to RAM
on idle intervals set in the BIOS and the like are sufficient that
progress will have been made before it considers going back to sleep
again. Right now its about ten seconds in each direction plus other costs
(wear on LCD backlight, disc parking etc).

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Android does not only run on phones. It is possible that no android
> devices have ACPI, but I don't know that for a fact. What I do know is
> that people want to run Android on x86 hardware and supporting suspend
> could be very benficial.

Sufficently beneficial to justify putting all this stuff all over the
kernel and apps ? That is a *very* high hurdle, doubly so when those
vendors who have chosen to be part of the community are shipping phones
and PDAs just fine without them.
 
> > I would imagine the existing laptops will handle power management limited
> > by the functionality they have available. Just like any other piece of
> > hardware.
> 
> I think existing laptops (and desktops) can benefit from opportunistic
> suspend support. If opportunistic suspend is used for auto-sleep after
> inactivity instead of forced suspend, the user space suspend blocker
> api will allow an application to delay this auto sleep until for
> instance a download completes. This part could also be done with a

This assumes you modify all the applications. That isn't going to happen.
The hardware is going to catch up anyway.

> alarms. I know my desktops can wakeup at a specific time by
> programming an RTC alarm, but without suspend blockers how do you
> ensure that the system does not suspend right after the alarm
> triggered? I have a system that wakes up at specific times requested

How do you know that isn't the correct behavior. My laptop behaves in
that way if for example the battery is almost flat. Your suspend blocker
would cause me to lose all my work with a flat battery. This is another
example of why the application must not be the policy manager.

In the normal case in the PC world outside of corner cases like flat
batteries the answer is really simple. The laptop suspend to RAM
on idle intervals set in the BIOS and the like are sufficient that
progress will have been made before it considers going back to sleep
again. Right now its about ten seconds in each direction plus other costs
(wear on LCD backlight, disc parking etc).

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
> On Thu, 27 May 2010 20:05:39 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Thu, 27 May 2010, Matthew Garrett wrote:
>>
>> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
>> >
>> > > Oh no. They paper over a short coming. If there is a pending event,
>> > > the kernel knows that. It just does not make use of this
>> > > information. Blockers just paper over this by sprinkling
>> > > do_not_suspend() calls all over the place. What a sensible solution.
>> >
>> > Even if we could use suspend-via-deep-idle-state on PCs, we still need
>> > to be able to enter suspend while the system isn't idle. There's two
>> > ways to do that:
>> >
>> > 1) Force the system to be idle. Doing this race-free is difficult.
>> >
>> > 2) Enter suspend even though the system isn't idle. Since we can't rely
>> > on the scheduler, we need drivers to know whether userspace has consumed
>> > all wakeup events before allowing the transition to occur. Doing so
>> > requires either in-kernel suspend blockers or something that's almost
>> > identical.
>>
>> You're just not getting it. If user space has consumed the event is
>> not relevant at all.
>>
>> What's relevant is whether the app has processed the event and reacted
>> accordingly. That's all that matters.
>>
>> Emptying your input queue is just the wrong indicator.
>>
>> And as I explained several times now: It does _NOT_ matter when the
>> app goes back in to blocked/idle state. You have to spend the CPU
>> cycles and power for that anyway.
>>
>> And for the apps which do not use the user space blockers the queue
>> empty indicator is just bullshit, because after emptying the queue the
>> kernel can go into suspend w/o any guarantee that the event has been
>> processed.
>>
>> The whole concept sucks, as it does not solve anything. Burning power
>> now or in 100ms is the same thing power consumption wise.
>>
>> Thanks,
>>
>>       tglx
>
> Thomas,
> do you really have a problem with the actual concept? Or do you just
> don't like the way it is done?
>
> IMO, the whole concept is defining 2 modes of operation:
>
> 1. user interacts with the device (at least one suspend block active)
> 2. user doesn't interact with the device (zero suspend block active)

That is a somewhat odd way of looking at it. Yes we have two modes of
operation, but an active suspend blocker does not mean that the user
is interacting with the device. The way we use it, the "main" suspend
blocker is active when the user interacts with the device (controlled
by writing to /sys/power/state). All other suspend blockers are used
to prevent suspend when user space has decided that the user is not
interacting with the device. This includes blocking suspend in the
kernel on key events which means the user actually is interacting with
the device, even if user-space has not realized it yet. For other
events, like an incoming phone call, we block suspend and make some
noise with the hope that the user will start interacting with the
device.

>
> In case 1. the device wants _everything_ sheduled as normal (and save
> maximum possible power, i.e. runtime pm with every technology available
> now).
>
> In case 2. we want nothing sheduled (and save maximum possible power,
> i.e. suspend)
>
OK.

> And now, every application and every kernel driver annotates (on behalve
> of the user) if it (possibly) interacts with the user.
>

Applications that interact with the user do not normally need to block
suspend. The user interacting with the device blocks suspend (just
like with your desktop screen saver). Not every kernel driver needs to
be annotated either, only potential wakeup events need to be
annotated.

> (Is this really the problematic bit, that userspace is giving
> the kernel hints? Or is it that the hints are called "blocker"?)
>
> We can only enter mode 2, if _nothing_ (claims) to interact with the
> user.
>

If nothing blocks suspend. The reason to block suspend does not have
to be direct user interaction.

> To integrate this with the current way of doing things, i gathered it
> needs to be implemented as an idle-state that does the suspend()-call?
>

I think it is better no not confuse this with idle. Since initiating
suspend will cause the system to become not-idle, I don't think is is
beneficial to initiate suspend from idle.

> Attributes of the idle states could be smth like this:
>
> c3
>        cost-to-transition-to-this-state: X
>        powersavings-per-time: Y
>        expected time we stay in this state: relative short, there is a
>                timer sheduled
>        suspend-blockers: ignored
>
> suspend
>        cost-to-transition-to-this-state: depends, how much drivers to
>        suspend, how much processes to freeze, how much state to save
>        powersavings-per-time: Y
>        expected time we stay in this state: long, independent of
>                sheduled timers
>        suspend-blockers: must not be activated
>
>
> Now all transitions and opportunistic suspend could be handled by the
> same algorithms.
>
> Would this work?
>

I'm not sure what you mean.


-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
> On Thu, 27 May 2010 20:05:39 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Thu, 27 May 2010, Matthew Garrett wrote:
>>
>> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
>> >
>> > > Oh no. They paper over a short coming. If there is a pending event,
>> > > the kernel knows that. It just does not make use of this
>> > > information. Blockers just paper over this by sprinkling
>> > > do_not_suspend() calls all over the place. What a sensible solution.
>> >
>> > Even if we could use suspend-via-deep-idle-state on PCs, we still need
>> > to be able to enter suspend while the system isn't idle. There's two
>> > ways to do that:
>> >
>> > 1) Force the system to be idle. Doing this race-free is difficult.
>> >
>> > 2) Enter suspend even though the system isn't idle. Since we can't rely
>> > on the scheduler, we need drivers to know whether userspace has consumed
>> > all wakeup events before allowing the transition to occur. Doing so
>> > requires either in-kernel suspend blockers or something that's almost
>> > identical.
>>
>> You're just not getting it. If user space has consumed the event is
>> not relevant at all.
>>
>> What's relevant is whether the app has processed the event and reacted
>> accordingly. That's all that matters.
>>
>> Emptying your input queue is just the wrong indicator.
>>
>> And as I explained several times now: It does _NOT_ matter when the
>> app goes back in to blocked/idle state. You have to spend the CPU
>> cycles and power for that anyway.
>>
>> And for the apps which do not use the user space blockers the queue
>> empty indicator is just bullshit, because after emptying the queue the
>> kernel can go into suspend w/o any guarantee that the event has been
>> processed.
>>
>> The whole concept sucks, as it does not solve anything. Burning power
>> now or in 100ms is the same thing power consumption wise.
>>
>> Thanks,
>>
>>       tglx
>
> Thomas,
> do you really have a problem with the actual concept? Or do you just
> don't like the way it is done?
>
> IMO, the whole concept is defining 2 modes of operation:
>
> 1. user interacts with the device (at least one suspend block active)
> 2. user doesn't interact with the device (zero suspend block active)

That is a somewhat odd way of looking at it. Yes we have two modes of
operation, but an active suspend blocker does not mean that the user
is interacting with the device. The way we use it, the "main" suspend
blocker is active when the user interacts with the device (controlled
by writing to /sys/power/state). All other suspend blockers are used
to prevent suspend when user space has decided that the user is not
interacting with the device. This includes blocking suspend in the
kernel on key events which means the user actually is interacting with
the device, even if user-space has not realized it yet. For other
events, like an incoming phone call, we block suspend and make some
noise with the hope that the user will start interacting with the
device.

>
> In case 1. the device wants _everything_ sheduled as normal (and save
> maximum possible power, i.e. runtime pm with every technology available
> now).
>
> In case 2. we want nothing sheduled (and save maximum possible power,
> i.e. suspend)
>
OK.

> And now, every application and every kernel driver annotates (on behalve
> of the user) if it (possibly) interacts with the user.
>

Applications that interact with the user do not normally need to block
suspend. The user interacting with the device blocks suspend (just
like with your desktop screen saver). Not every kernel driver needs to
be annotated either, only potential wakeup events need to be
annotated.

> (Is this really the problematic bit, that userspace is giving
> the kernel hints? Or is it that the hints are called "blocker"?)
>
> We can only enter mode 2, if _nothing_ (claims) to interact with the
> user.
>

If nothing blocks suspend. The reason to block suspend does not have
to be direct user interaction.

> To integrate this with the current way of doing things, i gathered it
> needs to be implemented as an idle-state that does the suspend()-call?
>

I think it is better no not confuse this with idle. Since initiating
suspend will cause the system to become not-idle, I don't think is is
beneficial to initiate suspend from idle.

> Attributes of the idle states could be smth like this:
>
> c3
>        cost-to-transition-to-this-state: X
>        powersavings-per-time: Y
>        expected time we stay in this state: relative short, there is a
>                timer sheduled
>        suspend-blockers: ignored
>
> suspend
>        cost-to-transition-to-this-state: depends, how much drivers to
>        suspend, how much processes to freeze, how much state to save
>        powersavings-per-time: Y
>        expected time we stay in this state: long, independent of
>                sheduled timers
>        suspend-blockers: must not be activated
>
>
> Now all transitions and opportunistic suspend could be handled by the
> same algorithms.
>
> Would this work?
>

I'm not sure what you mean.


-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
> On Thu, 27 May 2010 20:05:39 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Thu, 27 May 2010, Matthew Garrett wrote:
>>
>> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
>> >
>> > > Oh no. They paper over a short coming. If there is a pending event,
>> > > the kernel knows that. It just does not make use of this
>> > > information. Blockers just paper over this by sprinkling
>> > > do_not_suspend() calls all over the place. What a sensible solution.
>> >
>> > Even if we could use suspend-via-deep-idle-state on PCs, we still need
>> > to be able to enter suspend while the system isn't idle. There's two
>> > ways to do that:
>> >
>> > 1) Force the system to be idle. Doing this race-free is difficult.
>> >
>> > 2) Enter suspend even though the system isn't idle. Since we can't rely
>> > on the scheduler, we need drivers to know whether userspace has consumed
>> > all wakeup events before allowing the transition to occur. Doing so
>> > requires either in-kernel suspend blockers or something that's almost
>> > identical.
>>
>> You're just not getting it. If user space has consumed the event is
>> not relevant at all.
>>
>> What's relevant is whether the app has processed the event and reacted
>> accordingly. That's all that matters.
>>
>> Emptying your input queue is just the wrong indicator.
>>
>> And as I explained several times now: It does _NOT_ matter when the
>> app goes back in to blocked/idle state. You have to spend the CPU
>> cycles and power for that anyway.
>>
>> And for the apps which do not use the user space blockers the queue
>> empty indicator is just bullshit, because after emptying the queue the
>> kernel can go into suspend w/o any guarantee that the event has been
>> processed.
>>
>> The whole concept sucks, as it does not solve anything. Burning power
>> now or in 100ms is the same thing power consumption wise.
>>
>> Thanks,
>>
>>       tglx
>
> Thomas,
> do you really have a problem with the actual concept? Or do you just
> don't like the way it is done?
>
> IMO, the whole concept is defining 2 modes of operation:
>
> 1. user interacts with the device (at least one suspend block active)
> 2. user doesn't interact with the device (zero suspend block active)

That is a somewhat odd way of looking at it. Yes we have two modes of
operation, but an active suspend blocker does not mean that the user
is interacting with the device. The way we use it, the "main" suspend
blocker is active when the user interacts with the device (controlled
by writing to /sys/power/state). All other suspend blockers are used
to prevent suspend when user space has decided that the user is not
interacting with the device. This includes blocking suspend in the
kernel on key events which means the user actually is interacting with
the device, even if user-space has not realized it yet. For other
events, like an incoming phone call, we block suspend and make some
noise with the hope that the user will start interacting with the
device.

>
> In case 1. the device wants _everything_ sheduled as normal (and save
> maximum possible power, i.e. runtime pm with every technology available
> now).
>
> In case 2. we want nothing sheduled (and save maximum possible power,
> i.e. suspend)
>
OK.

> And now, every application and every kernel driver annotates (on behalve
> of the user) if it (possibly) interacts with the user.
>

Applications that interact with the user do not normally need to block
suspend. The user interacting with the device blocks suspend (just
like with your desktop screen saver). Not every kernel driver needs to
be annotated either, only potential wakeup events need to be
annotated.

> (Is this really the problematic bit, that userspace is giving
> the kernel hints? Or is it that the hints are called "blocker"?)
>
> We can only enter mode 2, if _nothing_ (claims) to interact with the
> user.
>

If nothing blocks suspend. The reason to block suspend does not have
to be direct user interaction.

> To integrate this with the current way of doing things, i gathered it
> needs to be implemented as an idle-state that does the suspend()-call?
>

I think it is better no not confuse this with idle. Since initiating
suspend will cause the system to become not-idle, I don't think is is
beneficial to initiate suspend from idle.

> Attributes of the idle states could be smth like this:
>
> c3
>        cost-to-transition-to-this-state: X
>        powersavings-per-time: Y
>        expected time we stay in this state: relative short, there is a
>                timer sheduled
>        suspend-blockers: ignored
>
> suspend
>        cost-to-transition-to-this-state: depends, how much drivers to
>        suspend, how much processes to freeze, how much state to save
>        powersavings-per-time: Y
>        expected time we stay in this state: long, independent of
>                sheduled timers
>        suspend-blockers: must not be activated
>
>
> Now all transitions and opportunistic suspend could be handled by the
> same algorithms.
>
> Would this work?
>

I'm not sure what you mean.


-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

resume latency QoS support, unify suspend/resume into idle states

[Ingo Molnar]

* Arve Hj?nnev?g <arve@android.com> wrote:

> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> >>
> >> > This is I believe robust (and has been implemented on some non x86
> >> > boxes). It depends on not forcing running tasks into suspend. That is the
> >> > key.
> >>
> >> We've already established that ACPI systems require us to force running
> >> tasks into suspend. How do we avoid the race in that situation?
> >
> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID 
> > x86 devices do not have ACPI.
> 
> Android does not only run on phones. It is possible that no android devices 
> have ACPI, but I don't know that for a fact. What I do know is that people 
> want to run Android on x86 hardware and supporting suspend could be very 
> benficial.

(If there's a sane framework then we'll fix x86 to fit into it and will deal 
with quirks.)

> > I would imagine the existing laptops will handle power management limited 
> > by the functionality they have available. Just like any other piece of 
> > hardware.
> 
> I think existing laptops (and desktops) can benefit from opportunistic 
> suspend support. If opportunistic suspend is used for auto-sleep after 
> inactivity instead of forced suspend, the user space suspend blocker api 
> will allow an application to delay this auto sleep until for instance a 
> download completes. This part could also be done with a user-space IPC call, 
> but having a standard kernel interface for it may make it more common. A 
> less common case, but more critical, is RTC alarms. I know my desktops can 
> wakeup at a specific time by programming an RTC alarm, but without suspend 
> blockers how do you ensure that the system does not suspend right after the 
> alarm triggered? I have a system that wakes up at specific times requested 
> by my DVR application, but I cannot use this system for anything else unless 
> I manually turn off the DVR application's auto-sleep feature. With suspend 
> blockers and something like the android alarm driver, I could use this 
> system for more than one application that have scheduled tasks and it would 
> be more usable for interactive applications.

I really like the level of detail and care that went into suspend-blockers, 
and i think the Android solution is very mature in terms of functionality 
offered to users.

In terms of bringing this depth of functionality and control to the upstream 
kernel, what do you think about Alan's QoS scheme, described in:

   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>

?

It's in essence suspend-blockers on steroids. It consists of two main 
components:

 - Unify the 'suspended' state into the regular chain of idle states, and
   create a single, coherent and transparent way we handle system idleness.

 - Give apps a QoS attribute that allows them to express how long they can
   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
   and thus the kernel would know it automatically which method of idleness is 
   still achievable. If all currently running apps have a max(QoS) attribute 
   of infinite, then the kernel can suspend for an unlimited amount of time.)

AFAICS, and i have read through your suspend-blocker usecases, this should 
handle all the usecases you listed - and some more. (please yell if that's not 
so)

Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.

(And on x86, for BIOS/CPU combos that allow it we can implement this scheme 
too.)

Thoughts?

	Ingo

resume latency QoS support, unify suspend/resume into idle states

[Ingo Molnar]

* Arve Hj?nnev?g <arve@android.com> wrote:

> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> >>
> >> > This is I believe robust (and has been implemented on some non x86
> >> > boxes). It depends on not forcing running tasks into suspend. That is the
> >> > key.
> >>
> >> We've already established that ACPI systems require us to force running
> >> tasks into suspend. How do we avoid the race in that situation?
> >
> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID 
> > x86 devices do not have ACPI.
> 
> Android does not only run on phones. It is possible that no android devices 
> have ACPI, but I don't know that for a fact. What I do know is that people 
> want to run Android on x86 hardware and supporting suspend could be very 
> benficial.

(If there's a sane framework then we'll fix x86 to fit into it and will deal 
with quirks.)

> > I would imagine the existing laptops will handle power management limited 
> > by the functionality they have available. Just like any other piece of 
> > hardware.
> 
> I think existing laptops (and desktops) can benefit from opportunistic 
> suspend support. If opportunistic suspend is used for auto-sleep after 
> inactivity instead of forced suspend, the user space suspend blocker api 
> will allow an application to delay this auto sleep until for instance a 
> download completes. This part could also be done with a user-space IPC call, 
> but having a standard kernel interface for it may make it more common. A 
> less common case, but more critical, is RTC alarms. I know my desktops can 
> wakeup at a specific time by programming an RTC alarm, but without suspend 
> blockers how do you ensure that the system does not suspend right after the 
> alarm triggered? I have a system that wakes up at specific times requested 
> by my DVR application, but I cannot use this system for anything else unless 
> I manually turn off the DVR application's auto-sleep feature. With suspend 
> blockers and something like the android alarm driver, I could use this 
> system for more than one application that have scheduled tasks and it would 
> be more usable for interactive applications.

I really like the level of detail and care that went into suspend-blockers, 
and i think the Android solution is very mature in terms of functionality 
offered to users.

In terms of bringing this depth of functionality and control to the upstream 
kernel, what do you think about Alan's QoS scheme, described in:

   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>

?

It's in essence suspend-blockers on steroids. It consists of two main 
components:

 - Unify the 'suspended' state into the regular chain of idle states, and
   create a single, coherent and transparent way we handle system idleness.

 - Give apps a QoS attribute that allows them to express how long they can
   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
   and thus the kernel would know it automatically which method of idleness is 
   still achievable. If all currently running apps have a max(QoS) attribute 
   of infinite, then the kernel can suspend for an unlimited amount of time.)

AFAICS, and i have read through your suspend-blocker usecases, this should 
handle all the usecases you listed - and some more. (please yell if that's not 
so)

Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.

(And on x86, for BIOS/CPU combos that allow it we can implement this scheme 
too.)

Thoughts?

	Ingo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> Android does not only run on phones. It is possible that no android
>> devices have ACPI, but I don't know that for a fact. What I do know is
>> that people want to run Android on x86 hardware and supporting suspend
>> could be very benficial.
>
> Sufficently beneficial to justify putting all this stuff all over the
> kernel and apps ? That is a *very* high hurdle, doubly so when those

In my opinion yes.

> vendors who have chosen to be part of the community are shipping phones
> and PDAs just fine without them.
>
>> > I would imagine the existing laptops will handle power management limited
>> > by the functionality they have available. Just like any other piece of
>> > hardware.
>>
>> I think existing laptops (and desktops) can benefit from opportunistic
>> suspend support. If opportunistic suspend is used for auto-sleep after
>> inactivity instead of forced suspend, the user space suspend blocker
>> api will allow an application to delay this auto sleep until for
>> instance a download completes. This part could also be done with a
>
> This assumes you modify all the applications.

No it does not. You only have to modify the applications were you want
to improved behavior compared to what you have now.

> That isn't going to happen.
> The hardware is going to catch up anyway.

I want it work today.

>
>> alarms. I know my desktops can wakeup at a specific time by
>> programming an RTC alarm, but without suspend blockers how do you
>> ensure that the system does not suspend right after the alarm
>> triggered? I have a system that wakes up at specific times requested
>
> How do you know that isn't the correct behavior.

If the inactivity timeout happens to expire at the same time as my
alarm that would wake up the system to run my scheduled task if it was
already suspended my sceduled task will not run when scheduled. How
can you argue that this is the correct behavior.

> My laptop behaves in
> that way if for example the battery is almost flat. Your suspend blocker
> would cause me to lose all my work with a flat battery. This is another
> example of why the application must not be the policy manager.
>

You can still force suspend when the battery gets low.

> In the normal case in the PC world outside of corner cases like flat
> batteries the answer is really simple. The laptop suspend to RAM
> on idle intervals set in the BIOS and the like are sufficient that
> progress will have been made before it considers going back to sleep
> again. Right now its about ten seconds in each direction plus other costs
> (wear on LCD backlight, disc parking etc).
>

I'm not sure what you are trying to say here. Are you saying your
laptop enters S3 from idle?

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> Android does not only run on phones. It is possible that no android
>> devices have ACPI, but I don't know that for a fact. What I do know is
>> that people want to run Android on x86 hardware and supporting suspend
>> could be very benficial.
>
> Sufficently beneficial to justify putting all this stuff all over the
> kernel and apps ? That is a *very* high hurdle, doubly so when those

In my opinion yes.

> vendors who have chosen to be part of the community are shipping phones
> and PDAs just fine without them.
>
>> > I would imagine the existing laptops will handle power management limited
>> > by the functionality they have available. Just like any other piece of
>> > hardware.
>>
>> I think existing laptops (and desktops) can benefit from opportunistic
>> suspend support. If opportunistic suspend is used for auto-sleep after
>> inactivity instead of forced suspend, the user space suspend blocker
>> api will allow an application to delay this auto sleep until for
>> instance a download completes. This part could also be done with a
>
> This assumes you modify all the applications.

No it does not. You only have to modify the applications were you want
to improved behavior compared to what you have now.

> That isn't going to happen.
> The hardware is going to catch up anyway.

I want it work today.

>
>> alarms. I know my desktops can wakeup at a specific time by
>> programming an RTC alarm, but without suspend blockers how do you
>> ensure that the system does not suspend right after the alarm
>> triggered? I have a system that wakes up at specific times requested
>
> How do you know that isn't the correct behavior.

If the inactivity timeout happens to expire at the same time as my
alarm that would wake up the system to run my scheduled task if it was
already suspended my sceduled task will not run when scheduled. How
can you argue that this is the correct behavior.

> My laptop behaves in
> that way if for example the battery is almost flat. Your suspend blocker
> would cause me to lose all my work with a flat battery. This is another
> example of why the application must not be the policy manager.
>

You can still force suspend when the battery gets low.

> In the normal case in the PC world outside of corner cases like flat
> batteries the answer is really simple. The laptop suspend to RAM
> on idle intervals set in the BIOS and the like are sufficient that
> progress will have been made before it considers going back to sleep
> again. Right now its about ten seconds in each direction plus other costs
> (wear on LCD backlight, disc parking etc).
>

I'm not sure what you are trying to say here. Are you saying your
laptop enters S3 from idle?

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Keep in mind, though, that a solution which is acceptable for Android
> has to include making sure that crappy applications don't cause the

Ted if you are speaking for Android do you think you should post from a
google address or with a google .sig ?

> battery to get drained.  There seem to be some people who seem
> adamently against this requirement.  From the Android folks'
> perspective, this is part of what is required to have an open app
> store, as opposed to one where each application has to be carefully
> screened and approved ala the Apple iPhone App Store.

The other vendors appear to be managing nicely without magic blockers. I
conjecture therefore there are other solutions.

> We need to agree on the requirements up front, because otherwise this
> is going to be a waste of everyone's time.

This is why I am trying to understand the problem properly.

> And if we can't get agreement on requirements, I'd suggest appealing
> this whole thing to Linus.  Either he'll agree to the requirements
> and/or the existing implementation, in which case we can move on with

The existing implementation has been comprehensively rejected by half the
x86 maintainers and scheduler people to start with. That's a fairly big
'No'.

> our lives, or he'll say no, in which case it will be blately obvious
> that it was Linux developer community who rejected the Android
> approach, despite a fairly large amount of effort trying to get
> something that satisfies *all* of the various LKML developers who have

Ted save the politicing and blame mongering for management meetings
please.

If we don't have a solution it means that between us we couldn't find a
viable solution. Maybe there isn't one, maybe we missed it. It's as much
'google rejects kernel approach' as 'kernel rejects google approach' and
more importantly its actually 'we (cumulative) were not smart enough
between us to figure it out'

> P.S.  Keep in mind how this looks from an outsider's perspective; an
> embedded manufacturer spends a fairly large amount of time answering
> one set of review comments, and a few weeks later, more people pop up,
> and make a much deeper set of complaints, and request that the current
> implementation be completely thrown out and that someone new be
> designed from scratch --- and the new design isn't even going to meet
> all of the requirements that the embedded manufacturer thought were
> necessary.  Is it any wonder a number of embedded developers have
> decided it's Just Too Hard to Work With the LKML?

In some cases it is easier to do stuff yourself than work with others.
One of the conditions of working in a public space is that you do so
without harming others. This is why in much of the western world you can
drive a car around your own land without a licence but must have one to
drive on a public road. This is why a restuarant must meet different food
standards to a home kitchen. This is why the kernel standards are higher
than what you go off and do in private.

Android is a very unique and extremely narrow environment. If it really
is special enough to need its own kernel fork it isn't the first case for
that and it's not a problem. The GPL is quite happy to encourage this.
Time will then answer the questions because in 3 years time either every
non Google phone will be kicking butt without suspend blockers, or every
phone vendor using Linux with a traditional user space will be demanding
them.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Keep in mind, though, that a solution which is acceptable for Android
> has to include making sure that crappy applications don't cause the

Ted if you are speaking for Android do you think you should post from a
google address or with a google .sig ?

> battery to get drained.  There seem to be some people who seem
> adamently against this requirement.  From the Android folks'
> perspective, this is part of what is required to have an open app
> store, as opposed to one where each application has to be carefully
> screened and approved ala the Apple iPhone App Store.

The other vendors appear to be managing nicely without magic blockers. I
conjecture therefore there are other solutions.

> We need to agree on the requirements up front, because otherwise this
> is going to be a waste of everyone's time.

This is why I am trying to understand the problem properly.

> And if we can't get agreement on requirements, I'd suggest appealing
> this whole thing to Linus.  Either he'll agree to the requirements
> and/or the existing implementation, in which case we can move on with

The existing implementation has been comprehensively rejected by half the
x86 maintainers and scheduler people to start with. That's a fairly big
'No'.

> our lives, or he'll say no, in which case it will be blately obvious
> that it was Linux developer community who rejected the Android
> approach, despite a fairly large amount of effort trying to get
> something that satisfies *all* of the various LKML developers who have

Ted save the politicing and blame mongering for management meetings
please.

If we don't have a solution it means that between us we couldn't find a
viable solution. Maybe there isn't one, maybe we missed it. It's as much
'google rejects kernel approach' as 'kernel rejects google approach' and
more importantly its actually 'we (cumulative) were not smart enough
between us to figure it out'

> P.S.  Keep in mind how this looks from an outsider's perspective; an
> embedded manufacturer spends a fairly large amount of time answering
> one set of review comments, and a few weeks later, more people pop up,
> and make a much deeper set of complaints, and request that the current
> implementation be completely thrown out and that someone new be
> designed from scratch --- and the new design isn't even going to meet
> all of the requirements that the embedded manufacturer thought were
> necessary.  Is it any wonder a number of embedded developers have
> decided it's Just Too Hard to Work With the LKML?

In some cases it is easier to do stuff yourself than work with others.
One of the conditions of working in a public space is that you do so
without harming others. This is why in much of the western world you can
drive a car around your own land without a licence but must have one to
drive on a public road. This is why a restuarant must meet different food
standards to a home kitchen. This is why the kernel standards are higher
than what you go off and do in private.

Android is a very unique and extremely narrow environment. If it really
is special enough to need its own kernel fork it isn't the first case for
that and it's not a problem. The GPL is quite happy to encourage this.
Time will then answer the questions because in 3 years time either every
non Google phone will be kicking butt without suspend blockers, or every
phone vendor using Linux with a traditional user space will be demanding
them.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

Ted

As a PS to the previous email the situation has I think more choices than
you portray.

Given the need for various constraints imposed by drivers for things like
RT it's entirely possible that a solution ends up being something like


Kernel proper:
Turn suspend block kernel API into an expression of constraints (or
				whatever else seems to work)
Throw the user space in the bin

Google:
Use the constraints in a sledgehammer manner (hey it solves your problem
			in that form so why not)
Patch in a private user space API


That makes things much much easier as we don't risk getting a horribly
broken API into the kernel that is hard to remove, while hopefully
meaning its rather easier for google to merge drivers and other code as
well as to maintain a smaller patch set.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

Ted

As a PS to the previous email the situation has I think more choices than
you portray.

Given the need for various constraints imposed by drivers for things like
RT it's entirely possible that a solution ends up being something like


Kernel proper:
Turn suspend block kernel API into an expression of constraints (or
				whatever else seems to work)
Throw the user space in the bin

Google:
Use the constraints in a sledgehammer manner (hey it solves your problem
			in that form so why not)
Patch in a private user space API


That makes things much much easier as we don't risk getting a horribly
broken API into the kernel that is hard to remove, while hopefully
meaning its rather easier for google to merge drivers and other code as
well as to maintain a smaller patch set.

Re: resume latency QoS support, unify suspend/resume into idle states

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 2:21 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Arve Hj?nnev?g <arve@android.com> wrote:
>
>> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > On Thu, 27 May 2010 23:09:49 +0100
>> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> >
>> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
>> >>
>> >> > This is I believe robust (and has been implemented on some non x86
>> >> > boxes). It depends on not forcing running tasks into suspend. That is the
>> >> > key.
>> >>
>> >> We've already established that ACPI systems require us to force running
>> >> tasks into suspend. How do we avoid the race in that situation?
>> >
>> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
>> > x86 devices do not have ACPI.
>>
>> Android does not only run on phones. It is possible that no android devices
>> have ACPI, but I don't know that for a fact. What I do know is that people
>> want to run Android on x86 hardware and supporting suspend could be very
>> benficial.
>
> (If there's a sane framework then we'll fix x86 to fit into it and will deal
> with quirks.)
>
>> > I would imagine the existing laptops will handle power management limited
>> > by the functionality they have available. Just like any other piece of
>> > hardware.
>>
>> I think existing laptops (and desktops) can benefit from opportunistic
>> suspend support. If opportunistic suspend is used for auto-sleep after
>> inactivity instead of forced suspend, the user space suspend blocker api
>> will allow an application to delay this auto sleep until for instance a
>> download completes. This part could also be done with a user-space IPC call,
>> but having a standard kernel interface for it may make it more common. A
>> less common case, but more critical, is RTC alarms. I know my desktops can
>> wakeup at a specific time by programming an RTC alarm, but without suspend
>> blockers how do you ensure that the system does not suspend right after the
>> alarm triggered? I have a system that wakes up at specific times requested
>> by my DVR application, but I cannot use this system for anything else unless
>> I manually turn off the DVR application's auto-sleep feature. With suspend
>> blockers and something like the android alarm driver, I could use this
>> system for more than one application that have scheduled tasks and it would
>> be more usable for interactive applications.
>
> I really like the level of detail and care that went into suspend-blockers,
> and i think the Android solution is very mature in terms of functionality
> offered to users.
>
> In terms of bringing this depth of functionality and control to the upstream
> kernel, what do you think about Alan's QoS scheme, described in:
>
>   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>
>
> ?
>
> It's in essence suspend-blockers on steroids. It consists of two main
> components:
>
>  - Unify the 'suspended' state into the regular chain of idle states, and
>   create a single, coherent and transparent way we handle system idleness.
>
>  - Give apps a QoS attribute that allows them to express how long they can
>   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
>   and thus the kernel would know it automatically which method of idleness is
>   still achievable. If all currently running apps have a max(QoS) attribute
>   of infinite, then the kernel can suspend for an unlimited amount of time.)
>
> AFAICS, and i have read through your suspend-blocker usecases, this should
> handle all the usecases you listed - and some more. (please yell if that's not
> so)
>
> Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.
>
> (And on x86, for BIOS/CPU combos that allow it we can implement this scheme
> too.)
>
> Thoughts?

Tying the QoS attribute to apps does not work (all proposals I have
seen have race conditions), but replacing every suspend blocker with
unique QoS object will work, since is the same thing as what suspend
blockers provide. I think replacing suspend blockers with artificial
latency requirements is a bad idea though, since we use them to ensure
a specific level of functionality (tasks, timers and interrupts
operate normally). If we get a more generic constraint framework,
suspend blockers may possibly be absorbed by this, but I think the
current implementation is useful as is (it could even be useful to
someone working on a generic constraints framework).

-- 
Arve Hjønnevåg

Re: resume latency QoS support, unify suspend/resume into idle states

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 2:21 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Arve Hj?nnev?g <arve@android.com> wrote:
>
>> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > On Thu, 27 May 2010 23:09:49 +0100
>> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> >
>> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
>> >>
>> >> > This is I believe robust (and has been implemented on some non x86
>> >> > boxes). It depends on not forcing running tasks into suspend. That is the
>> >> > key.
>> >>
>> >> We've already established that ACPI systems require us to force running
>> >> tasks into suspend. How do we avoid the race in that situation?
>> >
>> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
>> > x86 devices do not have ACPI.
>>
>> Android does not only run on phones. It is possible that no android devices
>> have ACPI, but I don't know that for a fact. What I do know is that people
>> want to run Android on x86 hardware and supporting suspend could be very
>> benficial.
>
> (If there's a sane framework then we'll fix x86 to fit into it and will deal
> with quirks.)
>
>> > I would imagine the existing laptops will handle power management limited
>> > by the functionality they have available. Just like any other piece of
>> > hardware.
>>
>> I think existing laptops (and desktops) can benefit from opportunistic
>> suspend support. If opportunistic suspend is used for auto-sleep after
>> inactivity instead of forced suspend, the user space suspend blocker api
>> will allow an application to delay this auto sleep until for instance a
>> download completes. This part could also be done with a user-space IPC call,
>> but having a standard kernel interface for it may make it more common. A
>> less common case, but more critical, is RTC alarms. I know my desktops can
>> wakeup at a specific time by programming an RTC alarm, but without suspend
>> blockers how do you ensure that the system does not suspend right after the
>> alarm triggered? I have a system that wakes up at specific times requested
>> by my DVR application, but I cannot use this system for anything else unless
>> I manually turn off the DVR application's auto-sleep feature. With suspend
>> blockers and something like the android alarm driver, I could use this
>> system for more than one application that have scheduled tasks and it would
>> be more usable for interactive applications.
>
> I really like the level of detail and care that went into suspend-blockers,
> and i think the Android solution is very mature in terms of functionality
> offered to users.
>
> In terms of bringing this depth of functionality and control to the upstream
> kernel, what do you think about Alan's QoS scheme, described in:
>
>   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>
>
> ?
>
> It's in essence suspend-blockers on steroids. It consists of two main
> components:
>
>  - Unify the 'suspended' state into the regular chain of idle states, and
>   create a single, coherent and transparent way we handle system idleness.
>
>  - Give apps a QoS attribute that allows them to express how long they can
>   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
>   and thus the kernel would know it automatically which method of idleness is
>   still achievable. If all currently running apps have a max(QoS) attribute
>   of infinite, then the kernel can suspend for an unlimited amount of time.)
>
> AFAICS, and i have read through your suspend-blocker usecases, this should
> handle all the usecases you listed - and some more. (please yell if that's not
> so)
>
> Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.
>
> (And on x86, for BIOS/CPU combos that allow it we can implement this scheme
> too.)
>
> Thoughts?

Tying the QoS attribute to apps does not work (all proposals I have
seen have race conditions), but replacing every suspend blocker with
unique QoS object will work, since is the same thing as what suspend
blockers provide. I think replacing suspend blockers with artificial
latency requirements is a bad idea though, since we use them to ensure
a specific level of functionality (tasks, timers and interrupts
operate normally). If we get a more generic constraint framework,
suspend blockers may possibly be absorbed by this, but I think the
current implementation is useful as is (it could even be useful to
someone working on a generic constraints framework).

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Bernd Petrovitsch]

On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote:
> 
> > Would it help to divide the application into two processes, one of 
> > which receives events and the other does the drawing?
> 
> At the point where you're rewriting the application you can just make it 
> adhere to our current behavioural standards anyway.

Thank you for confirming that the so-called "feature" is just there to
make apps work in some area that are crappy anyways - and God knows in
which other areas they are crappy too.

SCNR,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [PATCH 0/8] Suspend block api (version 8)

[Bernd Petrovitsch]

On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote:
> 
> > Would it help to divide the application into two processes, one of 
> > which receives events and the other does the drawing?
> 
> At the point where you're rewriting the application you can just make it 
> adhere to our current behavioural standards anyway.

Thank you for confirming that the so-called "feature" is just there to
make apps work in some area that are crappy anyways - and God knows in
which other areas they are crappy too.

SCNR,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 02:18:06 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> > IMO, the whole concept is defining 2 modes of operation:
> >
> > 1. user interacts with the device (at least one suspend block active)
> > 2. user doesn't interact with the device (zero suspend block active)
> 
> That is a somewhat odd way of looking at it. Yes we have two modes of
> operation, but an active suspend blocker does not mean that the user
> is interacting with the device. The way we use it, the "main" suspend
> blocker is active when the user interacts with the device (controlled
> by writing to /sys/power/state). All other suspend blockers are used
> to prevent suspend when user space has decided that the user is not
> interacting with the device. This includes blocking suspend in the
> kernel on key events which means the user actually is interacting with
> the device, even if user-space has not realized it yet. For other
> events, like an incoming phone call, we block suspend and make some
> noise with the hope that the user will start interacting with the
> device.

Damn. I just want to put some abstract notion around this approach to
power saving. 

But one could say instead of "direct" interaction, that every time a
suspend blocker is taken it is "on behalf of the user"?

So if a suspend blocker is taken, because a download is in progress,
it is on behalf of (direct, or indirect) user interaction. 

If a suspend blocker is taken, because a key-press has to trickle up to
userspace, it is because of the user. 

If a call comes in, a suspend blocker is taken, because the user wants
to receive incomming calls. 

So suspend blockers are always a hint to the kernel, that the action is
"on behalf of the user" and it is therefore ok to not suspend the
device?

> 
> >
> > In case 1. the device wants _everything_ sheduled as normal (and save
> > maximum possible power, i.e. runtime pm with every technology available
> > now).
> >
> > In case 2. we want nothing sheduled (and save maximum possible power,
> > i.e. suspend)
> >
> OK.

Good. I got this right at least. 

> 
> > And now, every application and every kernel driver annotates (on behalve
> > of the user) if it (possibly) interacts with the user.
> >
> 
> Applications that interact with the user do not normally need to block
> suspend. The user interacting with the device blocks suspend (just
> like with your desktop screen saver). Not every kernel driver needs to
> be annotated either, only potential wakeup events need to be
> annotated.

The applications interacting with the user rely on other parts of
the system to block suspend then. 

So it is (in general) not the application which determines if the user
interacts, but other sources (like input-drivers) and possible a
timeout? 

> 
> > (Is this really the problematic bit, that userspace is giving
> > the kernel hints? Or is it that the hints are called "blocker"?)
> >
> > We can only enter mode 2, if _nothing_ (claims) to interact with the
> > user.
> >
> 
> If nothing blocks suspend. The reason to block suspend does not have
> to be direct user interaction.

But couldn't you say, that the suspend blockers are always due to the
user? Or is this too narrow?  I mean we talk about a device here. And
the device's purpose is it to serve the user. So it might be better to
say: suspend blockers annotate if a task is needed to fullfill the
devices purpose?

It is an easy to understand concept if one says, the device suspends if
it has nothing to do to further the cause.


I really want to get to a well expressed definition. suspend blockers
block suspend. Shure. Buy why?

> 
> > To integrate this with the current way of doing things, i gathered it
> > needs to be implemented as an idle-state that does the suspend()-call?
> >
> 
> I think it is better no not confuse this with idle. Since initiating
> suspend will cause the system to become not-idle, I don't think is is
> beneficial to initiate suspend from idle.

I'm not shure. But then again, i'm not too familiar with the kernel. It
sounds like it could save some duplication of effort to integrate
suspend into the idle-framework. "Purpose-fulness" could be just
another measure of "idle".


> 
> > Attributes of the idle states could be smth like this:
> >
> > c3
> >        cost-to-transition-to-this-state: X
> >        powersavings-per-time: Y
> >        expected time we stay in this state: relative short, there is a
> >                timer sheduled
> >        suspend-blockers: ignored
> >
> > suspend
> >        cost-to-transition-to-this-state: depends, how much drivers to
> >        suspend, how much processes to freeze, how much state to save
> >        powersavings-per-time: Y
> >        expected time we stay in this state: long, independent of
> >                sheduled timers
> >        suspend-blockers: must not be activated
> >
> >
> > Now all transitions and opportunistic suspend could be handled by the
> > same algorithms.
> >
> > Would this work?
> >
> 
> I'm not sure what you mean.

Yeah. It's a "little bit" handwavy. 

But the concept I have in mind:

	int what_good_would_it_be_to_go_into_this_state( state )
	{
		/*

		cur_state = get_current_state();
		benefit = ( get_power_per_time(cur_state)
			- get_power_per_time(state) ) * 
			get_expected_time_we_stay_there( state );
		cost = get_transition_cost(cur_state,state);
		return benefit-cost;

		*/
	}

and a constraint function:

	bool is_this_state_possible( state )
	{
		/* 

		ret = true;
		cur_latency_requirement = get_cur_latency_req();
		ret &= (cur_latency_requirement >=state_latency_guaranty( state ) );
		ret &= (some other QOS thingy);

		return ret;
		*/
	}

And now, a loop would enter the state which has the biggest score and
is possible at the time.

Afaik this is already implemented for c-states in the cpu_idle drivers?


cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 02:18:06 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> > IMO, the whole concept is defining 2 modes of operation:
> >
> > 1. user interacts with the device (at least one suspend block active)
> > 2. user doesn't interact with the device (zero suspend block active)
> 
> That is a somewhat odd way of looking at it. Yes we have two modes of
> operation, but an active suspend blocker does not mean that the user
> is interacting with the device. The way we use it, the "main" suspend
> blocker is active when the user interacts with the device (controlled
> by writing to /sys/power/state). All other suspend blockers are used
> to prevent suspend when user space has decided that the user is not
> interacting with the device. This includes blocking suspend in the
> kernel on key events which means the user actually is interacting with
> the device, even if user-space has not realized it yet. For other
> events, like an incoming phone call, we block suspend and make some
> noise with the hope that the user will start interacting with the
> device.

Damn. I just want to put some abstract notion around this approach to
power saving. 

But one could say instead of "direct" interaction, that every time a
suspend blocker is taken it is "on behalf of the user"?

So if a suspend blocker is taken, because a download is in progress,
it is on behalf of (direct, or indirect) user interaction. 

If a suspend blocker is taken, because a key-press has to trickle up to
userspace, it is because of the user. 

If a call comes in, a suspend blocker is taken, because the user wants
to receive incomming calls. 

So suspend blockers are always a hint to the kernel, that the action is
"on behalf of the user" and it is therefore ok to not suspend the
device?

> 
> >
> > In case 1. the device wants _everything_ sheduled as normal (and save
> > maximum possible power, i.e. runtime pm with every technology available
> > now).
> >
> > In case 2. we want nothing sheduled (and save maximum possible power,
> > i.e. suspend)
> >
> OK.

Good. I got this right at least. 

> 
> > And now, every application and every kernel driver annotates (on behalve
> > of the user) if it (possibly) interacts with the user.
> >
> 
> Applications that interact with the user do not normally need to block
> suspend. The user interacting with the device blocks suspend (just
> like with your desktop screen saver). Not every kernel driver needs to
> be annotated either, only potential wakeup events need to be
> annotated.

The applications interacting with the user rely on other parts of
the system to block suspend then. 

So it is (in general) not the application which determines if the user
interacts, but other sources (like input-drivers) and possible a
timeout? 

> 
> > (Is this really the problematic bit, that userspace is giving
> > the kernel hints? Or is it that the hints are called "blocker"?)
> >
> > We can only enter mode 2, if _nothing_ (claims) to interact with the
> > user.
> >
> 
> If nothing blocks suspend. The reason to block suspend does not have
> to be direct user interaction.

But couldn't you say, that the suspend blockers are always due to the
user? Or is this too narrow?  I mean we talk about a device here. And
the device's purpose is it to serve the user. So it might be better to
say: suspend blockers annotate if a task is needed to fullfill the
devices purpose?

It is an easy to understand concept if one says, the device suspends if
it has nothing to do to further the cause.


I really want to get to a well expressed definition. suspend blockers
block suspend. Shure. Buy why?

> 
> > To integrate this with the current way of doing things, i gathered it
> > needs to be implemented as an idle-state that does the suspend()-call?
> >
> 
> I think it is better no not confuse this with idle. Since initiating
> suspend will cause the system to become not-idle, I don't think is is
> beneficial to initiate suspend from idle.

I'm not shure. But then again, i'm not too familiar with the kernel. It
sounds like it could save some duplication of effort to integrate
suspend into the idle-framework. "Purpose-fulness" could be just
another measure of "idle".


> 
> > Attributes of the idle states could be smth like this:
> >
> > c3
> >        cost-to-transition-to-this-state: X
> >        powersavings-per-time: Y
> >        expected time we stay in this state: relative short, there is a
> >                timer sheduled
> >        suspend-blockers: ignored
> >
> > suspend
> >        cost-to-transition-to-this-state: depends, how much drivers to
> >        suspend, how much processes to freeze, how much state to save
> >        powersavings-per-time: Y
> >        expected time we stay in this state: long, independent of
> >                sheduled timers
> >        suspend-blockers: must not be activated
> >
> >
> > Now all transitions and opportunistic suspend could be handled by the
> > same algorithms.
> >
> > Would this work?
> >
> 
> I'm not sure what you mean.

Yeah. It's a "little bit" handwavy. 

But the concept I have in mind:

	int what_good_would_it_be_to_go_into_this_state( state )
	{
		/*

		cur_state = get_current_state();
		benefit = ( get_power_per_time(cur_state)
			- get_power_per_time(state) ) * 
			get_expected_time_we_stay_there( state );
		cost = get_transition_cost(cur_state,state);
		return benefit-cost;

		*/
	}

and a constraint function:

	bool is_this_state_possible( state )
	{
		/* 

		ret = true;
		cur_latency_requirement = get_cur_latency_req();
		ret &= (cur_latency_requirement >=state_latency_guaranty( state ) );
		ret &= (some other QOS thingy);

		return ret;
		*/
	}

And now, a loop would enter the state which has the biggest score and
is possible at the time.

Afaik this is already implemented for c-states in the cpu_idle drivers?


cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> This is a much harder question to answer that what we need to use
> opportunistic suspend. The question we ask is more like this: "Is all
> important work complete?". In the simplest case these can be the same,

I don't believe you can answer that question without telepathy and a
crystal ball.

The application doesn't know because it has no idea how to balance
conflicting resource demands or to infer the users requirements and
wishes. Most apps will misbehave anyway.

The OS doesn't know because it cannot tell what the app wants

So at best you have a heuristic.

> What happens if the user presses the button right before you set QoS
> of 'user apps' to  QS_NONE?

Read down a paragraph.

> To me it looks like this solution would result in this sequence which
> may ignore the button press:
>         Button pushed
>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>         Set QoS of 'user apps' to QS_NONE
> 
> 
> >        That would I think solve the reliable wakeup case although
> >        drivers raising a QoS parameter is a bit unusual in the kernel.
> >        That would at least however be specific to a few Android drivers
> >        and maybe a tiny amount of shared driver stuff so probably not
> >        unacceptable. (wake_up_pri(&queue, priority); isn't going to
> >        kill anyone is it - especially if it usually ignores the
> >        priority argument)
> 
> Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

We keep it kernel side
It expresses policy and wishes rather than enforcing a behaviour.

What for example does "suspend_block" mean on a virtual machine ?

I would prefer "priority" was some kind of resource constraint model
instead but I'm just trying to think how to be absolutely minimally
invasible at this point.

> What happens if the button press happend before this line:
> >        count2 = tasks to QS_NONE | QS_NOTCHANGED
> >        Screen off
> >                                        Button Press
> >                                        task to QS_ABOVESUSPEND
> >        count = tasks that are QS_NOTCHANGED to QS_NONE
> >
> >        if (count != count2) {
> >                Stuff happened ... rethink
> >        }
> >
> > That is still a bit weird and wonderful but all the logic is in the right
> > places. The special magic remains in the Android policy code and in the
> > kernel specifics for Android.
> >
> > Thoughts ?
> 
> I don't think it works. Also, it does not seem much less invasive than
> suspend blockers.

"I don't think it works" isn't that helpful. I don't think it works
because .. would help me a lot more.

I think it's a loss let invasive because you are not exposing a ton of
stuff to user space in general (just some private chit chat between a
couple of processes). I would prefer it didn't even do that but simply
used QoS guarantees. However I don't see a way to achieve that given your
intended QoS guarantees change according to actions like screen off.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> This is a much harder question to answer that what we need to use
> opportunistic suspend. The question we ask is more like this: "Is all
> important work complete?". In the simplest case these can be the same,

I don't believe you can answer that question without telepathy and a
crystal ball.

The application doesn't know because it has no idea how to balance
conflicting resource demands or to infer the users requirements and
wishes. Most apps will misbehave anyway.

The OS doesn't know because it cannot tell what the app wants

So at best you have a heuristic.

> What happens if the user presses the button right before you set QoS
> of 'user apps' to  QS_NONE?

Read down a paragraph.

> To me it looks like this solution would result in this sequence which
> may ignore the button press:
>         Button pushed
>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>         Set QoS of 'user apps' to QS_NONE
> 
> 
> >        That would I think solve the reliable wakeup case although
> >        drivers raising a QoS parameter is a bit unusual in the kernel.
> >        That would at least however be specific to a few Android drivers
> >        and maybe a tiny amount of shared driver stuff so probably not
> >        unacceptable. (wake_up_pri(&queue, priority); isn't going to
> >        kill anyone is it - especially if it usually ignores the
> >        priority argument)
> 
> Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

We keep it kernel side
It expresses policy and wishes rather than enforcing a behaviour.

What for example does "suspend_block" mean on a virtual machine ?

I would prefer "priority" was some kind of resource constraint model
instead but I'm just trying to think how to be absolutely minimally
invasible at this point.

> What happens if the button press happend before this line:
> >        count2 = tasks to QS_NONE | QS_NOTCHANGED
> >        Screen off
> >                                        Button Press
> >                                        task to QS_ABOVESUSPEND
> >        count = tasks that are QS_NOTCHANGED to QS_NONE
> >
> >        if (count != count2) {
> >                Stuff happened ... rethink
> >        }
> >
> > That is still a bit weird and wonderful but all the logic is in the right
> > places. The special magic remains in the Android policy code and in the
> > kernel specifics for Android.
> >
> > Thoughts ?
> 
> I don't think it works. Also, it does not seem much less invasive than
> suspend blockers.

"I don't think it works" isn't that helpful. I don't think it works
because .. would help me a lot more.

I think it's a loss let invasive because you are not exposing a ton of
stuff to user space in general (just some private chit chat between a
couple of processes). I would prefer it didn't even do that but simply
used QoS guarantees. However I don't see a way to achieve that given your
intended QoS guarantees change according to actions like screen off.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> This is a much harder question to answer that what we need to use
>> opportunistic suspend. The question we ask is more like this: "Is all
>> important work complete?". In the simplest case these can be the same,
>
> I don't believe you can answer that question without telepathy and a
> crystal ball.
>
But we have answered this question.

> The application doesn't know because it has no idea how to balance
> conflicting resource demands or to infer the users requirements and
> wishes. Most apps will misbehave anyway.
>
> The OS doesn't know because it cannot tell what the app wants
>
> So at best you have a heuristic.
>
>> What happens if the user presses the button right before you set QoS
>> of 'user apps' to  QS_NONE?
>
> Read down a paragraph.
>
>> To me it looks like this solution would result in this sequence which
>> may ignore the button press:
>>         Button pushed
>>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>>         Set QoS of 'user apps' to QS_NONE
>>
>>
>> >        That would I think solve the reliable wakeup case although
>> >        drivers raising a QoS parameter is a bit unusual in the kernel.
>> >        That would at least however be specific to a few Android drivers
>> >        and maybe a tiny amount of shared driver stuff so probably not
>> >        unacceptable. (wake_up_pri(&queue, priority); isn't going to
>> >        kill anyone is it - especially if it usually ignores the
>> >        priority argument)
>>
>> Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?
>
> We keep it kernel side
> It expresses policy and wishes rather than enforcing a behaviour.
>
> What for example does "suspend_block" mean on a virtual machine ?
>
> I would prefer "priority" was some kind of resource constraint model
> instead but I'm just trying to think how to be absolutely minimally
> invasible at this point.
>
>> What happens if the button press happend before this line:
>> >        count2 = tasks to QS_NONE | QS_NOTCHANGED
>> >        Screen off
>> >                                        Button Press
>> >                                        task to QS_ABOVESUSPEND
>> >        count = tasks that are QS_NOTCHANGED to QS_NONE
>> >
>> >        if (count != count2) {
>> >                Stuff happened ... rethink
>> >        }
>> >
>> > That is still a bit weird and wonderful but all the logic is in the right
>> > places. The special magic remains in the Android policy code and in the
>> > kernel specifics for Android.
>> >
>> > Thoughts ?
>>
>> I don't think it works. Also, it does not seem much less invasive than
>> suspend blockers.
>
> "I don't think it works" isn't that helpful. I don't think it works
> because .. would help me a lot more.

Did you miss this:
>> What happens if the button press happend before this line:
>> >        count2 = tasks to QS_NONE | QS_NOTCHANGED

As far as I can tell this is the same race I described where you just
told me to read down a paragraph.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> This is a much harder question to answer that what we need to use
>> opportunistic suspend. The question we ask is more like this: "Is all
>> important work complete?". In the simplest case these can be the same,
>
> I don't believe you can answer that question without telepathy and a
> crystal ball.
>
But we have answered this question.

> The application doesn't know because it has no idea how to balance
> conflicting resource demands or to infer the users requirements and
> wishes. Most apps will misbehave anyway.
>
> The OS doesn't know because it cannot tell what the app wants
>
> So at best you have a heuristic.
>
>> What happens if the user presses the button right before you set QoS
>> of 'user apps' to  QS_NONE?
>
> Read down a paragraph.
>
>> To me it looks like this solution would result in this sequence which
>> may ignore the button press:
>>         Button pushed
>>         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>>         Set QoS of 'user apps' to QS_NONE
>>
>>
>> >        That would I think solve the reliable wakeup case although
>> >        drivers raising a QoS parameter is a bit unusual in the kernel.
>> >        That would at least however be specific to a few Android drivers
>> >        and maybe a tiny amount of shared driver stuff so probably not
>> >        unacceptable. (wake_up_pri(&queue, priority); isn't going to
>> >        kill anyone is it - especially if it usually ignores the
>> >        priority argument)
>>
>> Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?
>
> We keep it kernel side
> It expresses policy and wishes rather than enforcing a behaviour.
>
> What for example does "suspend_block" mean on a virtual machine ?
>
> I would prefer "priority" was some kind of resource constraint model
> instead but I'm just trying to think how to be absolutely minimally
> invasible at this point.
>
>> What happens if the button press happend before this line:
>> >        count2 = tasks to QS_NONE | QS_NOTCHANGED
>> >        Screen off
>> >                                        Button Press
>> >                                        task to QS_ABOVESUSPEND
>> >        count = tasks that are QS_NOTCHANGED to QS_NONE
>> >
>> >        if (count != count2) {
>> >                Stuff happened ... rethink
>> >        }
>> >
>> > That is still a bit weird and wonderful but all the logic is in the right
>> > places. The special magic remains in the Android policy code and in the
>> > kernel specifics for Android.
>> >
>> > Thoughts ?
>>
>> I don't think it works. Also, it does not seem much less invasive than
>> suspend blockers.
>
> "I don't think it works" isn't that helpful. I don't think it works
> because .. would help me a lot more.

Did you miss this:
>> What happens if the button press happend before this line:
>> >        count2 = tasks to QS_NONE | QS_NOTCHANGED

As far as I can tell this is the same race I described where you just
told me to read down a paragraph.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > My laptop behaves in
> > that way if for example the battery is almost flat. Your suspend blocker
> > would cause me to lose all my work with a flat battery. This is another
> > example of why the application must not be the policy manager.
> >
> 
> You can still force suspend when the battery gets low.

So now we need suspend blocker blockers - as I predicted.

> > In the normal case in the PC world outside of corner cases like flat
> > batteries the answer is really simple. The laptop suspend to RAM
> > on idle intervals set in the BIOS and the like are sufficient that
> > progress will have been made before it considers going back to sleep
> > again. Right now its about ten seconds in each direction plus other costs
> > (wear on LCD backlight, disc parking etc).
> >
> 
> I'm not sure what you are trying to say here. Are you saying your
> laptop enters S3 from idle?

If I have an alarm set on my laptop it will wake up when the alarm goes
off. Once it has woken up it will not go back to suspend (except for
something libe a battery event) until a timeout has elapsed that began
when the laptop woke up.

This in the laptop work solves the problem of making progress. On a
laptop power budget, with laptop constraints on suspend (both physical
cycle limits of hardware and performance) this works fine.

If I suspend/resume my laptop every time I have a 30 second idle gap I
will need a new laptop much sooner than makes me happy.

I don't claim this is true for a typical mobile phone obviously.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > My laptop behaves in
> > that way if for example the battery is almost flat. Your suspend blocker
> > would cause me to lose all my work with a flat battery. This is another
> > example of why the application must not be the policy manager.
> >
> 
> You can still force suspend when the battery gets low.

So now we need suspend blocker blockers - as I predicted.

> > In the normal case in the PC world outside of corner cases like flat
> > batteries the answer is really simple. The laptop suspend to RAM
> > on idle intervals set in the BIOS and the like are sufficient that
> > progress will have been made before it considers going back to sleep
> > again. Right now its about ten seconds in each direction plus other costs
> > (wear on LCD backlight, disc parking etc).
> >
> 
> I'm not sure what you are trying to say here. Are you saying your
> laptop enters S3 from idle?

If I have an alarm set on my laptop it will wake up when the alarm goes
off. Once it has woken up it will not go back to suspend (except for
something libe a battery event) until a timeout has elapsed that began
when the laptop woke up.

This in the laptop work solves the problem of making progress. On a
laptop power budget, with laptop constraints on suspend (both physical
cycle limits of hardware and performance) this works fine.

If I suspend/resume my laptop every time I have a 30 second idle gap I
will need a new laptop much sooner than makes me happy.

I don't claim this is true for a typical mobile phone obviously.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> > My laptop behaves in
>> > that way if for example the battery is almost flat. Your suspend blocker
>> > would cause me to lose all my work with a flat battery. This is another
>> > example of why the application must not be the policy manager.
>> >
>>
>> You can still force suspend when the battery gets low.
>
> So now we need suspend blocker blockers - as I predicted.

Forced suspend is still supported. No new API is needed if you really
want to force suspend.

>
>> > In the normal case in the PC world outside of corner cases like flat
>> > batteries the answer is really simple. The laptop suspend to RAM
>> > on idle intervals set in the BIOS and the like are sufficient that
>> > progress will have been made before it considers going back to sleep
>> > again. Right now its about ten seconds in each direction plus other costs
>> > (wear on LCD backlight, disc parking etc).
>> >
>>
>> I'm not sure what you are trying to say here. Are you saying your
>> laptop enters S3 from idle?
>
> If I have an alarm set on my laptop it will wake up when the alarm goes
> off. Once it has woken up it will not go back to suspend (except for
> something libe a battery event) until a timeout has elapsed that began
> when the laptop woke up.
>

I think you are missing the point. It works fine if the alarm caused
the wakeup, but if you had just used your system and your inactivity
timeout expired just as your alarm goes off, the alarm will not wake
the system, nor does it prevent it from suspending.

> This in the laptop work solves the problem of making progress. On a
> laptop power budget, with laptop constraints on suspend (both physical
> cycle limits of hardware and performance) this works fine.
>
> If I suspend/resume my laptop every time I have a 30 second idle gap I
> will need a new laptop much sooner than makes me happy.
>

Then don't set your inactivity timeout to 30 seconds. I don't see how
this is relevant.

> I don't claim this is true for a typical mobile phone obviously.
>
The only difference on the phone is that we have way more wakeup
events which makes the race conditions more visible. The race exist on
your laptop as well.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> > My laptop behaves in
>> > that way if for example the battery is almost flat. Your suspend blocker
>> > would cause me to lose all my work with a flat battery. This is another
>> > example of why the application must not be the policy manager.
>> >
>>
>> You can still force suspend when the battery gets low.
>
> So now we need suspend blocker blockers - as I predicted.

Forced suspend is still supported. No new API is needed if you really
want to force suspend.

>
>> > In the normal case in the PC world outside of corner cases like flat
>> > batteries the answer is really simple. The laptop suspend to RAM
>> > on idle intervals set in the BIOS and the like are sufficient that
>> > progress will have been made before it considers going back to sleep
>> > again. Right now its about ten seconds in each direction plus other costs
>> > (wear on LCD backlight, disc parking etc).
>> >
>>
>> I'm not sure what you are trying to say here. Are you saying your
>> laptop enters S3 from idle?
>
> If I have an alarm set on my laptop it will wake up when the alarm goes
> off. Once it has woken up it will not go back to suspend (except for
> something libe a battery event) until a timeout has elapsed that began
> when the laptop woke up.
>

I think you are missing the point. It works fine if the alarm caused
the wakeup, but if you had just used your system and your inactivity
timeout expired just as your alarm goes off, the alarm will not wake
the system, nor does it prevent it from suspending.

> This in the laptop work solves the problem of making progress. On a
> laptop power budget, with laptop constraints on suspend (both physical
> cycle limits of hardware and performance) this works fine.
>
> If I suspend/resume my laptop every time I have a 30 second idle gap I
> will need a new laptop much sooner than makes me happy.
>

Then don't set your inactivity timeout to 30 seconds. I don't see how
this is relevant.

> I don't claim this is true for a typical mobile phone obviously.
>
The only difference on the phone is that we have way more wakeup
events which makes the race conditions more visible. The race exist on
your laptop as well.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> > My laptop behaves in
>> > that way if for example the battery is almost flat. Your suspend blocker
>> > would cause me to lose all my work with a flat battery. This is another
>> > example of why the application must not be the policy manager.
>> >
>>
>> You can still force suspend when the battery gets low.
>
> So now we need suspend blocker blockers - as I predicted.

Forced suspend is still supported. No new API is needed if you really
want to force suspend.

>
>> > In the normal case in the PC world outside of corner cases like flat
>> > batteries the answer is really simple. The laptop suspend to RAM
>> > on idle intervals set in the BIOS and the like are sufficient that
>> > progress will have been made before it considers going back to sleep
>> > again. Right now its about ten seconds in each direction plus other costs
>> > (wear on LCD backlight, disc parking etc).
>> >
>>
>> I'm not sure what you are trying to say here. Are you saying your
>> laptop enters S3 from idle?
>
> If I have an alarm set on my laptop it will wake up when the alarm goes
> off. Once it has woken up it will not go back to suspend (except for
> something libe a battery event) until a timeout has elapsed that began
> when the laptop woke up.
>

I think you are missing the point. It works fine if the alarm caused
the wakeup, but if you had just used your system and your inactivity
timeout expired just as your alarm goes off, the alarm will not wake
the system, nor does it prevent it from suspending.

> This in the laptop work solves the problem of making progress. On a
> laptop power budget, with laptop constraints on suspend (both physical
> cycle limits of hardware and performance) this works fine.
>
> If I suspend/resume my laptop every time I have a 30 second idle gap I
> will need a new laptop much sooner than makes me happy.
>

Then don't set your inactivity timeout to 30 seconds. I don't see how
this is relevant.

> I don't claim this is true for a typical mobile phone obviously.
>
The only difference on the phone is that we have way more wakeup
events which makes the race conditions more visible. The race exist on
your laptop as well.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Florian Mickler <florian@mickler.org>:
> On Fri, 28 May 2010 02:18:06 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> > IMO, the whole concept is defining 2 modes of operation:
>> >
>> > 1. user interacts with the device (at least one suspend block active)
>> > 2. user doesn't interact with the device (zero suspend block active)
>>
>> That is a somewhat odd way of looking at it. Yes we have two modes of
>> operation, but an active suspend blocker does not mean that the user
>> is interacting with the device. The way we use it, the "main" suspend
>> blocker is active when the user interacts with the device (controlled
>> by writing to /sys/power/state). All other suspend blockers are used
>> to prevent suspend when user space has decided that the user is not
>> interacting with the device. This includes blocking suspend in the
>> kernel on key events which means the user actually is interacting with
>> the device, even if user-space has not realized it yet. For other
>> events, like an incoming phone call, we block suspend and make some
>> noise with the hope that the user will start interacting with the
>> device.
>
> Damn. I just want to put some abstract notion around this approach to
> power saving.
>
> But one could say instead of "direct" interaction, that every time a
> suspend blocker is taken it is "on behalf of the user"?
>
> So if a suspend blocker is taken, because a download is in progress,
> it is on behalf of (direct, or indirect) user interaction.
>
> If a suspend blocker is taken, because a key-press has to trickle up to
> userspace, it is because of the user.
>
> If a call comes in, a suspend blocker is taken, because the user wants
> to receive incomming calls.
>
> So suspend blockers are always a hint to the kernel, that the action is
> "on behalf of the user" and it is therefore ok to not suspend the
> device?
>

We also use suspend blockers for work that is not visible to the user.
The battery driver on the Nexus One wakes up periodically while
charging to monitor the battery temperature and turn down the charge
current if it gets too hot.

>>
>> >
>> > In case 1. the device wants _everything_ sheduled as normal (and save
>> > maximum possible power, i.e. runtime pm with every technology available
>> > now).
>> >
>> > In case 2. we want nothing sheduled (and save maximum possible power,
>> > i.e. suspend)
>> >
>> OK.
>
> Good. I got this right at least.
>
>>
>> > And now, every application and every kernel driver annotates (on behalve
>> > of the user) if it (possibly) interacts with the user.
>> >
>>
>> Applications that interact with the user do not normally need to block
>> suspend. The user interacting with the device blocks suspend (just
>> like with your desktop screen saver). Not every kernel driver needs to
>> be annotated either, only potential wakeup events need to be
>> annotated.
>
> The applications interacting with the user rely on other parts of
> the system to block suspend then.
>
> So it is (in general) not the application which determines if the user
> interacts, but other sources (like input-drivers) and possible a
> timeout?
>

The user-space framework decides if the device is in an interactive
mode or not (on Android phones the screen is off when it is not
interactive). Input driver need to block suspend so the user-space
framework gets the event when it is not already in interactive mode.

>>
>> > (Is this really the problematic bit, that userspace is giving
>> > the kernel hints? Or is it that the hints are called "blocker"?)
>> >
>> > We can only enter mode 2, if _nothing_ (claims) to interact with the
>> > user.
>> >
>>
>> If nothing blocks suspend. The reason to block suspend does not have
>> to be direct user interaction.
>
> But couldn't you say, that the suspend blockers are always due to the
> user? Or is this too narrow?  I mean we talk about a device here. And
> the device's purpose is it to serve the user. So it might be better to
> say: suspend blockers annotate if a task is needed to fullfill the
> devices purpose?
>
I think it is more useful to say that suspend blockers annotate that
some event needs to be processed even if the device is currently not
in an interactive mode.

> It is an easy to understand concept if one says, the device suspends if
> it has nothing to do to further the cause.
>
>
> I really want to get to a well expressed definition. suspend blockers
> block suspend. Shure. Buy why?
>
>>
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> I'm not shure. But then again, i'm not too familiar with the kernel. It
> sounds like it could save some duplication of effort to integrate
> suspend into the idle-framework. "Purpose-fulness" could be just
> another measure of "idle".
>

To me idle means that no threads are ready to run and no interrupts are pending.

>
>>
>> > Attributes of the idle states could be smth like this:
>> >
>> > c3
>> >        cost-to-transition-to-this-state: X
>> >        powersavings-per-time: Y
>> >        expected time we stay in this state: relative short, there is a
>> >                timer sheduled
>> >        suspend-blockers: ignored
>> >
>> > suspend
>> >        cost-to-transition-to-this-state: depends, how much drivers to
>> >        suspend, how much processes to freeze, how much state to save
>> >        powersavings-per-time: Y
>> >        expected time we stay in this state: long, independent of
>> >                sheduled timers
>> >        suspend-blockers: must not be activated
>> >
>> >
>> > Now all transitions and opportunistic suspend could be handled by the
>> > same algorithms.
>> >
>> > Would this work?
>> >
>>
>> I'm not sure what you mean.
>
> Yeah. It's a "little bit" handwavy.
>
> But the concept I have in mind:
>
>        int what_good_would_it_be_to_go_into_this_state( state )
>        {
>                /*
>
>                cur_state = get_current_state();
>                benefit = ( get_power_per_time(cur_state)
>                        - get_power_per_time(state) ) *
>                        get_expected_time_we_stay_there( state );
>                cost = get_transition_cost(cur_state,state);
>                return benefit-cost;
>
>                */
>        }
>
> and a constraint function:
>
>        bool is_this_state_possible( state )
>        {
>                /*
>
>                ret = true;
>                cur_latency_requirement = get_cur_latency_req();
>                ret &= (cur_latency_requirement >=state_latency_guaranty( state ) );
>                ret &= (some other QOS thingy);
>
>                return ret;
>                */
>        }
>
> And now, a loop would enter the state which has the biggest score and
> is possible at the time.
>
> Afaik this is already implemented for c-states in the cpu_idle drivers?
>

I don't think we can plug suspend in as a cpu idle state. 1. we want
to suspend even the cpu is not idle. 2. starting suspend will cause
the cpu to not be idle.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Florian Mickler <florian@mickler.org>:
> On Fri, 28 May 2010 02:18:06 -0700
> Arve Hjønnevåg <arve@android.com> wrote:
>
>> > IMO, the whole concept is defining 2 modes of operation:
>> >
>> > 1. user interacts with the device (at least one suspend block active)
>> > 2. user doesn't interact with the device (zero suspend block active)
>>
>> That is a somewhat odd way of looking at it. Yes we have two modes of
>> operation, but an active suspend blocker does not mean that the user
>> is interacting with the device. The way we use it, the "main" suspend
>> blocker is active when the user interacts with the device (controlled
>> by writing to /sys/power/state). All other suspend blockers are used
>> to prevent suspend when user space has decided that the user is not
>> interacting with the device. This includes blocking suspend in the
>> kernel on key events which means the user actually is interacting with
>> the device, even if user-space has not realized it yet. For other
>> events, like an incoming phone call, we block suspend and make some
>> noise with the hope that the user will start interacting with the
>> device.
>
> Damn. I just want to put some abstract notion around this approach to
> power saving.
>
> But one could say instead of "direct" interaction, that every time a
> suspend blocker is taken it is "on behalf of the user"?
>
> So if a suspend blocker is taken, because a download is in progress,
> it is on behalf of (direct, or indirect) user interaction.
>
> If a suspend blocker is taken, because a key-press has to trickle up to
> userspace, it is because of the user.
>
> If a call comes in, a suspend blocker is taken, because the user wants
> to receive incomming calls.
>
> So suspend blockers are always a hint to the kernel, that the action is
> "on behalf of the user" and it is therefore ok to not suspend the
> device?
>

We also use suspend blockers for work that is not visible to the user.
The battery driver on the Nexus One wakes up periodically while
charging to monitor the battery temperature and turn down the charge
current if it gets too hot.

>>
>> >
>> > In case 1. the device wants _everything_ sheduled as normal (and save
>> > maximum possible power, i.e. runtime pm with every technology available
>> > now).
>> >
>> > In case 2. we want nothing sheduled (and save maximum possible power,
>> > i.e. suspend)
>> >
>> OK.
>
> Good. I got this right at least.
>
>>
>> > And now, every application and every kernel driver annotates (on behalve
>> > of the user) if it (possibly) interacts with the user.
>> >
>>
>> Applications that interact with the user do not normally need to block
>> suspend. The user interacting with the device blocks suspend (just
>> like with your desktop screen saver). Not every kernel driver needs to
>> be annotated either, only potential wakeup events need to be
>> annotated.
>
> The applications interacting with the user rely on other parts of
> the system to block suspend then.
>
> So it is (in general) not the application which determines if the user
> interacts, but other sources (like input-drivers) and possible a
> timeout?
>

The user-space framework decides if the device is in an interactive
mode or not (on Android phones the screen is off when it is not
interactive). Input driver need to block suspend so the user-space
framework gets the event when it is not already in interactive mode.

>>
>> > (Is this really the problematic bit, that userspace is giving
>> > the kernel hints? Or is it that the hints are called "blocker"?)
>> >
>> > We can only enter mode 2, if _nothing_ (claims) to interact with the
>> > user.
>> >
>>
>> If nothing blocks suspend. The reason to block suspend does not have
>> to be direct user interaction.
>
> But couldn't you say, that the suspend blockers are always due to the
> user? Or is this too narrow?  I mean we talk about a device here. And
> the device's purpose is it to serve the user. So it might be better to
> say: suspend blockers annotate if a task is needed to fullfill the
> devices purpose?
>
I think it is more useful to say that suspend blockers annotate that
some event needs to be processed even if the device is currently not
in an interactive mode.

> It is an easy to understand concept if one says, the device suspends if
> it has nothing to do to further the cause.
>
>
> I really want to get to a well expressed definition. suspend blockers
> block suspend. Shure. Buy why?
>
>>
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> I'm not shure. But then again, i'm not too familiar with the kernel. It
> sounds like it could save some duplication of effort to integrate
> suspend into the idle-framework. "Purpose-fulness" could be just
> another measure of "idle".
>

To me idle means that no threads are ready to run and no interrupts are pending.

>
>>
>> > Attributes of the idle states could be smth like this:
>> >
>> > c3
>> >        cost-to-transition-to-this-state: X
>> >        powersavings-per-time: Y
>> >        expected time we stay in this state: relative short, there is a
>> >                timer sheduled
>> >        suspend-blockers: ignored
>> >
>> > suspend
>> >        cost-to-transition-to-this-state: depends, how much drivers to
>> >        suspend, how much processes to freeze, how much state to save
>> >        powersavings-per-time: Y
>> >        expected time we stay in this state: long, independent of
>> >                sheduled timers
>> >        suspend-blockers: must not be activated
>> >
>> >
>> > Now all transitions and opportunistic suspend could be handled by the
>> > same algorithms.
>> >
>> > Would this work?
>> >
>>
>> I'm not sure what you mean.
>
> Yeah. It's a "little bit" handwavy.
>
> But the concept I have in mind:
>
>        int what_good_would_it_be_to_go_into_this_state( state )
>        {
>                /*
>
>                cur_state = get_current_state();
>                benefit = ( get_power_per_time(cur_state)
>                        - get_power_per_time(state) ) *
>                        get_expected_time_we_stay_there( state );
>                cost = get_transition_cost(cur_state,state);
>                return benefit-cost;
>
>                */
>        }
>
> and a constraint function:
>
>        bool is_this_state_possible( state )
>        {
>                /*
>
>                ret = true;
>                cur_latency_requirement = get_cur_latency_req();
>                ret &= (cur_latency_requirement >=state_latency_guaranty( state ) );
>                ret &= (some other QOS thingy);
>
>                return ret;
>                */
>        }
>
> And now, a loop would enter the state which has the biggest score and
> is possible at the time.
>
> Afaik this is already implemented for c-states in the cpu_idle drivers?
>

I don't think we can plug suspend in as a cpu idle state. 1. we want
to suspend even the cpu is not idle. 2. starting suspend will cause
the cpu to not be idle.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:

> The other vendors appear to be managing nicely without magic blockers. I
> conjecture therefore there are other solutions.

Actually, no. A badly behaved application will kill the N900's battery 
life. Nobody else has "managed nicely" - they've just made life harder 
for application developers and users, which may have something to do 
with the relative levels of market adoption of Maemo and Android. I'm 
not aware of any form of resource management framework in MeeGo either, 
so as far as I know it'll have exactly the same problem.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:

> The other vendors appear to be managing nicely without magic blockers. I
> conjecture therefore there are other solutions.

Actually, no. A badly behaved application will kill the N900's battery 
life. Nobody else has "managed nicely" - they've just made life harder 
for application developers and users, which may have something to do 
with the relative levels of market adoption of Maemo and Android. I'm 
not aware of any form of resource management framework in MeeGo either, 
so as far as I know it'll have exactly the same problem.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
> On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> > At the point where you're rewriting the application you can just make it 
> > adhere to our current behavioural standards anyway.
> 
> Thank you for confirming that the so-called "feature" is just there to
> make apps work in some area that are crappy anyways - and God knows in
> which other areas they are crappy too.

Kind of like memory protection, really. Or preemptive multitasking. Or 
many things that the kernel does to prevent badly written applications 
from interfering with other applications or the user's experience.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
> On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> > At the point where you're rewriting the application you can just make it 
> > adhere to our current behavioural standards anyway.
> 
> Thank you for confirming that the so-called "feature" is just there to
> make apps work in some area that are crappy anyways - and God knows in
> which other areas they are crappy too.

Kind of like memory protection, really. Or preemptive multitasking. Or 
many things that the kernel does to prevent badly written applications 
from interfering with other applications or the user's experience.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 04:35:34 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/28 Florian Mickler <florian@mickler.org>:

> > It sounds like it could save some duplication of effort to integrate
> > suspend into the idle-framework. "Purpose-fulness" could be just
> > another measure of "idle".
> >
> 
> To me idle means that no threads are ready to run and no interrupts are pending.

I misused the term "idle".  I tried to express this by "quoting" it.

> 
> I don't think we can plug suspend in as a cpu idle state. 1. we want
> to suspend even the cpu is not idle. 2. starting suspend will cause
> the cpu to not be idle.
> 

yeah. it would have to move out of the cpu-specific context. it would
be a more general "system-state" thing.

if the properties of the state's are well expressed, it does not matter
that starting suspend will cause the cpu to not be idle, because our
target-state(suspend) has better properties than any other state.

(or maybe there needs to be a "state-transition-in-flight" flag.)

if we take the "approximated duration of staying in that state" into
account, we could provoke the pm-framework to always suspend if no
constraint(i.e. blocker) is there.

But really. I think I can't implement something like that.
Also I really have _no_ idea how much work this would be.

_And_ I am not really shure if this is a better approach than the
current solution.

Just an idea. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 04:35:34 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/28 Florian Mickler <florian@mickler.org>:

> > It sounds like it could save some duplication of effort to integrate
> > suspend into the idle-framework. "Purpose-fulness" could be just
> > another measure of "idle".
> >
> 
> To me idle means that no threads are ready to run and no interrupts are pending.

I misused the term "idle".  I tried to express this by "quoting" it.

> 
> I don't think we can plug suspend in as a cpu idle state. 1. we want
> to suspend even the cpu is not idle. 2. starting suspend will cause
> the cpu to not be idle.
> 

yeah. it would have to move out of the cpu-specific context. it would
be a more general "system-state" thing.

if the properties of the state's are well expressed, it does not matter
that starting suspend will cause the cpu to not be idle, because our
target-state(suspend) has better properties than any other state.

(or maybe there needs to be a "state-transition-in-flight" flag.)

if we take the "approximated duration of staying in that state" into
account, we could provoke the pm-framework to always suspend if no
constraint(i.e. blocker) is there.

But really. I think I can't implement something like that.
Also I really have _no_ idea how much work this would be.

_And_ I am not really shure if this is a better approach than the
current solution.

Just an idea. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 04:35:34 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> 2010/5/28 Florian Mickler <florian@mickler.org>:

> > It sounds like it could save some duplication of effort to integrate
> > suspend into the idle-framework. "Purpose-fulness" could be just
> > another measure of "idle".
> >
> 
> To me idle means that no threads are ready to run and no interrupts are pending.

I misused the term "idle".  I tried to express this by "quoting" it.

> 
> I don't think we can plug suspend in as a cpu idle state. 1. we want
> to suspend even the cpu is not idle. 2. starting suspend will cause
> the cpu to not be idle.
> 

yeah. it would have to move out of the cpu-specific context. it would
be a more general "system-state" thing.

if the properties of the state's are well expressed, it does not matter
that starting suspend will cause the cpu to not be idle, because our
target-state(suspend) has better properties than any other state.

(or maybe there needs to be a "state-transition-in-flight" flag.)

if we take the "approximated duration of staying in that state" into
account, we could provoke the pm-framework to always suspend if no
constraint(i.e. blocker) is there.

But really. I think I can't implement something like that.
Also I really have _no_ idea how much work this would be.

_And_ I am not really shure if this is a better approach than the
current solution.

Just an idea. 

Cheers,
Flo



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 5:37 AM, Alan Cox wrote:

>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
> 
> Ted if you are speaking for Android do you think you should post from a
> google address or with a google .sig ?

We're all engineers here.   Nobody speaks for the company as a whole without the permission of corporate PR, and that's true for Intel, IBM, and all other companies.

>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.  From the Android folks'
>> perspective, this is part of what is required to have an open app
>> store, as opposed to one where each application has to be carefully
>> screened and approved ala the Apple iPhone App Store.
> 
> The other vendors appear to be managing nicely without magic blockers. I
> conjecture therefore there are other solutions.

I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.

> If we don't have a solution it means that between us we couldn't find a
> viable solution. Maybe there isn't one, maybe we missed it. It's as much
> 'google rejects kernel approach' as 'kernel rejects google approach' and
> more importantly its actually 'we (cumulative) were not smart enough
> between us to figure it out'

Maybe.  And perhaps the right solution in that case is to merge both, as opposed to "consign one to the outer darkness".   And I think that's a decision Linus should make.

I do hope we can come up with a better solution, eventually.  But I do want to point out as a process point of view, we do have other alternates other than "spinning endlessly".

-- Ted

Re: [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 5:37 AM, Alan Cox wrote:

>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
> 
> Ted if you are speaking for Android do you think you should post from a
> google address or with a google .sig ?

We're all engineers here.   Nobody speaks for the company as a whole without the permission of corporate PR, and that's true for Intel, IBM, and all other companies.

>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.  From the Android folks'
>> perspective, this is part of what is required to have an open app
>> store, as opposed to one where each application has to be carefully
>> screened and approved ala the Apple iPhone App Store.
> 
> The other vendors appear to be managing nicely without magic blockers. I
> conjecture therefore there are other solutions.

I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.

> If we don't have a solution it means that between us we couldn't find a
> viable solution. Maybe there isn't one, maybe we missed it. It's as much
> 'google rejects kernel approach' as 'kernel rejects google approach' and
> more importantly its actually 'we (cumulative) were not smart enough
> between us to figure it out'

Maybe.  And perhaps the right solution in that case is to merge both, as opposed to "consign one to the outer darkness".   And I think that's a decision Linus should make.

I do hope we can come up with a better solution, eventually.  But I do want to point out as a process point of view, we do have other alternates other than "spinning endlessly".

-- Ted

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

Ok lets try and produce something more concrete. The control groups may
be the wrong tool but we've got several such tools already


Kernel involved
----------------
acquire:		mark myself important (into cgroup important)
acquire(timeout)	ditto, plus app timer/timeout handler
release:		mark myself unimportant (into cgroup downtrodden) 

All user
--------
isHeld:			app implementation internal
setReferenceCounted:	app implementation internal


In the idle manager [Androids own probably]

	if (member of ignored cgroup && in user space)
		ignore for idle purposes


In the Android code managing this [Android specific bits of
probably userspace]
	mark downtrodden as ignored
	mark downtrodden as not ignored


[Total kernel changes

	Ability to mark/unmark a scheduler control group as outside of
	some parts of idle consideration. Generically useful and
	localised. Group latency will do most jobs fine (Zygo is correct
	it can't solve his backup case elegantly I think)

	Test in the idling logic to distinguish the case and only needed
	for a single Android specific power module. Generically useful
	and localised]

So I put my phone down

	The UI manager gets told the phone is 'down'
	Ten seconds later it is still down
	It marks the downtrodden group as 'ignored'

	The idle logic goes
		Nothing to run powersave
		Still nothing
		Ooh 0.3 seconds of nothing
		Drop into suspend state


If I push the button we get an IRQ
We come out of power save
The app gets poked
The app may be unimportant but the IRQ means we have a new timeout of
    some form to run down to idle
The app marks itself important
The app stays awake for 60 seconds rsyncing your email
The app marks itself unimportant
Time elapses
We return to suspend


If you are absolutely utterly paranoid about it you need the button
driver to mark the task it wakes back as important rather than rely on
time for response like everyone else. That specific bit is uggglly but
worst case its just a google private patch to a few drivers. I understand
why Android wants it. The narrower the gap between 'we are doing nothing,
sit in lowest CPU on state' and 'we are off' the better the battery life
and the more hittable the condition.

Apart from that optional paranoia case my kernel now contains some
trivial changes of generic value that have nothing to do with suspend
blocking. Android has suspend blocking by choosing to use the generic
features in its own specific way and we need almost no code writing ?

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

Ok lets try and produce something more concrete. The control groups may
be the wrong tool but we've got several such tools already


Kernel involved
----------------
acquire:		mark myself important (into cgroup important)
acquire(timeout)	ditto, plus app timer/timeout handler
release:		mark myself unimportant (into cgroup downtrodden) 

All user
--------
isHeld:			app implementation internal
setReferenceCounted:	app implementation internal


In the idle manager [Androids own probably]

	if (member of ignored cgroup && in user space)
		ignore for idle purposes


In the Android code managing this [Android specific bits of
probably userspace]
	mark downtrodden as ignored
	mark downtrodden as not ignored


[Total kernel changes

	Ability to mark/unmark a scheduler control group as outside of
	some parts of idle consideration. Generically useful and
	localised. Group latency will do most jobs fine (Zygo is correct
	it can't solve his backup case elegantly I think)

	Test in the idling logic to distinguish the case and only needed
	for a single Android specific power module. Generically useful
	and localised]

So I put my phone down

	The UI manager gets told the phone is 'down'
	Ten seconds later it is still down
	It marks the downtrodden group as 'ignored'

	The idle logic goes
		Nothing to run powersave
		Still nothing
		Ooh 0.3 seconds of nothing
		Drop into suspend state


If I push the button we get an IRQ
We come out of power save
The app gets poked
The app may be unimportant but the IRQ means we have a new timeout of
    some form to run down to idle
The app marks itself important
The app stays awake for 60 seconds rsyncing your email
The app marks itself unimportant
Time elapses
We return to suspend


If you are absolutely utterly paranoid about it you need the button
driver to mark the task it wakes back as important rather than rely on
time for response like everyone else. That specific bit is uggglly but
worst case its just a google private patch to a few drivers. I understand
why Android wants it. The narrower the gap between 'we are doing nothing,
sit in lowest CPU on state' and 'we are off' the better the battery life
and the more hittable the condition.

Apart from that optional paranoia case my kernel now contains some
trivial changes of generic value that have nothing to do with suspend
blocking. Android has suspend blocking by choosing to use the generic
features in its own specific way and we need almost no code writing ?

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Matthew Garrett wrote:

> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
>
>   
>> The other vendors appear to be managing nicely without magic blockers. I
>> conjecture therefore there are other solutions.
>>     
>
> Actually, no. A badly behaved application will kill the N900's battery 
> life. Nobody else has "managed nicely" - they've just made life harder 
> for application developers and users, which may have something to do 
> with the relative levels of market adoption of Maemo and Android. I'm 
> not aware of any form of resource management framework in MeeGo either, 
> so as far as I know it'll have exactly the same problem.
>
>   
It's true that a braindead app can kill the battery.

However we provide a version of powertop that is tailored to the N900, 
there is a nokia energy profiler meant to give graphical representation 
of the battery current, there is htop available and you can even get the 
processor activity visualized on the leftmost and rightmost keyboard 
backlight LEDS, when in RD mode and with screen blanked.

I would advice you to not start debating on company strategies, this is 
not the right place.

Otherwise I'll have to ask what's the expected threshold of devices sold 
with broken sw design to get automatic admission into the mainline 
kernel source tree.

But this is not the direction we want to take.

Notice also that we _do_ have a store and official repository where apps 
are monitored for sanity, also with feedback from users and their help 
to promote new apps to trusted state.

Former Maemo 6, now MeeGo do introduce resource management from security 
POV, but that will also have the side effect of discriminating between 
signers.

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Matthew Garrett wrote:

> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
>
>   
>> The other vendors appear to be managing nicely without magic blockers. I
>> conjecture therefore there are other solutions.
>>     
>
> Actually, no. A badly behaved application will kill the N900's battery 
> life. Nobody else has "managed nicely" - they've just made life harder 
> for application developers and users, which may have something to do 
> with the relative levels of market adoption of Maemo and Android. I'm 
> not aware of any form of resource management framework in MeeGo either, 
> so as far as I know it'll have exactly the same problem.
>
>   
It's true that a braindead app can kill the battery.

However we provide a version of powertop that is tailored to the N900, 
there is a nokia energy profiler meant to give graphical representation 
of the battery current, there is htop available and you can even get the 
processor activity visualized on the leftmost and rightmost keyboard 
backlight LEDS, when in RD mode and with screen blanked.

I would advice you to not start debating on company strategies, this is 
not the right place.

Otherwise I'll have to ask what's the expected threshold of devices sold 
with broken sw design to get automatic admission into the mainline 
kernel source tree.

But this is not the direction we want to take.

Notice also that we _do_ have a store and official repository where apps 
are monitored for sanity, also with feedback from users and their help 
to promote new apps to trusted state.

Former Maemo 6, now MeeGo do introduce resource management from security 
POV, but that will also have the side effect of discriminating between 
signers.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 8:16 AM, Theodore Tso wrote:
> 
> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   

Sorry, miswording:   s/faster/less frequent/

I'm not convinced CPU activity LEDs help either, BTW.    It only takes the CPU getting crowbarred out of idle for a tiny amount of time before you start impacting battery life, and if the crapplication is only doing it every 30-60 seconds or so, I doubt you'd see it on the LED's....  that sort of thing might be acceptable if you have a 1-3 pound battery, but maybe much less so if you have a bettery which is cell-phoned sized.

-- Ted

Re: [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 8:16 AM, Theodore Tso wrote:
> 
> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   

Sorry, miswording:   s/faster/less frequent/

I'm not convinced CPU activity LEDs help either, BTW.    It only takes the CPU getting crowbarred out of idle for a tiny amount of time before you start impacting battery life, and if the crapplication is only doing it every 30-60 seconds or so, I doubt you'd see it on the LED's....  that sort of thing might be acceptable if you have a 1-3 pound battery, but maybe much less so if you have a bettery which is cell-phoned sized.

-- Ted

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> [Total kernel changes
> 
>         Ability to mark/unmark a scheduler control group as outside of
>         some parts of idle consideration. Generically useful and
>         localised. Group latency will do most jobs fine (Zygo is correct
>         it can't solve his backup case elegantly I think)
> 
>         Test in the idling logic to distinguish the case and only needed
>         for a single Android specific power module. Generically useful
>         and localised] 

I really don't like this..

Why can't we go with the previously suggested: make bad apps block on
QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL?

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> [Total kernel changes
> 
>         Ability to mark/unmark a scheduler control group as outside of
>         some parts of idle consideration. Generically useful and
>         localised. Group latency will do most jobs fine (Zygo is correct
>         it can't solve his backup case elegantly I think)
> 
>         Test in the idling logic to distinguish the case and only needed
>         for a single Android specific power module. Generically useful
>         and localised] 

I really don't like this..

Why can't we go with the previously suggested: make bad apps block on
QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 8:49 AM, Igor Stoppa wrote:

> ext Theodore Tso wrote:
> 
>> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.
>>  
> Those apps were from an experimental repository, which is not enabled by default in stock SW.

Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler.   But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder.   I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository".

-- Ted
> 

Re: [PATCH 0/8] Suspend block api (version 8)

[Theodore Tso]

On May 28, 2010, at 8:49 AM, Igor Stoppa wrote:

> ext Theodore Tso wrote:
> 
>> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.
>>  
> Those apps were from an experimental repository, which is not enabled by default in stock SW.

Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler.   But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder.   I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository".

-- Ted
> 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 01:21:38PM +0100, Alan Cox wrote:

> So I put my phone down
> 
> 	The UI manager gets told the phone is 'down'
> 	Ten seconds later it is still down
            <- wakeup event that should be delivered to untrusted app arrives here

At this point you may mark the downtrodden group as ignored between the 
untrusted app receiving the event and the untrusted app marking itself 
as important. To avoid this you need the UI manager to receive every 
wakeup event in order to change its scheduling decisions.

> If I push the button we get an IRQ
> We come out of power save
> The app gets poked

(The cgroup has to have some awareness of suspend/resume so that it can 
allow the untrusted apps to be scheduled again)

> The app may be unimportant but the IRQ means we have a new timeout of
>     some form to run down to idle

The timeout-based nature means that if the application doesn't get 
scheduled for some reason (say there's heavy swap pressure - not likely 
in the embedded world, but an issue on laptop-type devices) the event 
may not be handled before you get back to sleep. I accept that this 
isn't likely to be a problem in the real world, but it does make this 
mechanism less deterministic than a suspend block based one.

> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.

Not just the button driver. Every driver that generates wakeupa. This 
gets difficult when it comes to the network layer, for instance, when 
the network driver has very little idea how the packet it just received 
will be routed.

> Apart from that optional paranoia case my kernel now contains some
> trivial changes of generic value that have nothing to do with suspend
> blocking. Android has suspend blocking by choosing to use the generic
> features in its own specific way and we need almost no code writing ?

The problem is that you still have a race, and fixing that race requires 
every event that could generate a wakeup to be proxied out to the policy 
manager as well. That's a moderate additional overhead.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 01:21:38PM +0100, Alan Cox wrote:

> So I put my phone down
> 
> 	The UI manager gets told the phone is 'down'
> 	Ten seconds later it is still down
            <- wakeup event that should be delivered to untrusted app arrives here

At this point you may mark the downtrodden group as ignored between the 
untrusted app receiving the event and the untrusted app marking itself 
as important. To avoid this you need the UI manager to receive every 
wakeup event in order to change its scheduling decisions.

> If I push the button we get an IRQ
> We come out of power save
> The app gets poked

(The cgroup has to have some awareness of suspend/resume so that it can 
allow the untrusted apps to be scheduled again)

> The app may be unimportant but the IRQ means we have a new timeout of
>     some form to run down to idle

The timeout-based nature means that if the application doesn't get 
scheduled for some reason (say there's heavy swap pressure - not likely 
in the embedded world, but an issue on laptop-type devices) the event 
may not be handled before you get back to sleep. I accept that this 
isn't likely to be a problem in the real world, but it does make this 
mechanism less deterministic than a suspend block based one.

> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.

Not just the button driver. Every driver that generates wakeupa. This 
gets difficult when it comes to the network layer, for instance, when 
the network driver has very little idea how the packet it just received 
will be routed.

> Apart from that optional paranoia case my kernel now contains some
> trivial changes of generic value that have nothing to do with suspend
> blocking. Android has suspend blocking by choosing to use the generic
> features in its own specific way and we need almost no code writing ?

The problem is that you still have a race, and fixing that race requires 
every event that could generate a wakeup to be proxied out to the policy 
manager as well. That's a moderate additional overhead.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Theodore Tso wrote:

> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.
>   
Those apps were from an experimental repository, which is not enabled by 
default in stock SW.

Of course tools can be improved, but if someone decides to run sw which 
is clearly under heavy development, i see little point in complaining 
that it might not work as expected.

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Theodore Tso wrote:

> I've seen very hard to debug situations  with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off.   And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication.   If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier.
>   
Those apps were from an experimental repository, which is not enabled by 
default in stock SW.

Of course tools can be improved, but if someone decides to run sw which 
is clearly under heavy development, i see little point in complaining 
that it might not work as expected.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Matthew Garrett wrote:
>> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
>>> The other vendors appear to be managing nicely without magic blockers. I
>>> conjecture therefore there are other solutions.
>>
>> Actually, no. A badly behaved application will kill the N900's battery
>> life. Nobody else has "managed nicely" - they've just made life harder for
>> application developers and users, which may have something to do with the
>> relative levels of market adoption of Maemo and Android. I'm not aware of
>> any form of resource management framework in MeeGo either, so as far as I
>> know it'll have exactly the same problem.
>
> It's true that a braindead app can kill the battery.
>
> However we provide a version of powertop that is tailored to the N900, there
> is a nokia energy profiler meant to give graphical representation of the
> battery current, there is htop available and you can even get the processor
> activity visualized on the leftmost and rightmost keyboard backlight LEDS,
> when in RD mode and with screen blanked.
>
> I would advice you to not start debating on company strategies, this is not
> the right place.

At a certain point, if one side of the argument is using "N900 / OMAP3
works just fine as is" (which has certainly been the case stated by a
number of folks throughout these discussions), I think it's a little
unrealistic to express shock that somebody argues the opposing point.

I've personally avoided commenting on specific power management issues
or properties of competitive platforms because it can easily be viewed
as rather rude or unprofessional.  (though in theory we all could
benefit from any improvements to the kernel regarding power
management, no?).

I am quite willing to state that on both MSM and OMAP based Android
platforms, we've found that the suspend blocker model allows us to
obtain a lower average power draw than if we don't use it -- Mike Chan
provided some numbers earlier in another thread in the trivial device
idle case, the win is of course much larger in the case of several
poorly behaved apps being active.

I do think that everyone involved agrees that it is beneficial to
educate users and developers in hopes that users will understand that
some apps are non-optimal and developers will be encouraged to write
better apps.

I think we also all agree that striving to obtain the lowest power
state at all times through cpu frequency scaling, runtime pm, drivers
that aggressively clock/power down when idle, etc is a worthy goal.
Some have argued that suspend blockers may deter further development
in these areas, but I think this is unlikely -- power usage while the
device is active and the user is interacting with it is just as
critical as when it's not being used interactively.  We (Android)
certainly pursue aggressive low power optimization in both states.

There appears to be some disagreement in terms of what one should do
in the face of poorly behaved applications.  The Android approach has
been to both gather as much data as possible for education of user and
developer and to mitigate the impact of poorly written apps on
endusers, goals which are aided by the suspend blocker model.

A reality of a mass market device with a completely open and
unrestricted application development and distribution ecosystem is
that there will be plenty of non-optimal apps available to users
(Sturgeon's Law applies everywhere, after all).  Worse yet, many of
these non-optimal apps may be beloved by users for various reasons.  I
think there's value in trying to do the best you can power-wise even
in the face of such horrible foes as the dreaded Bouncing Cows App
that Matthew is fond of citing as an example.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Matthew Garrett wrote:
>> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
>>> The other vendors appear to be managing nicely without magic blockers. I
>>> conjecture therefore there are other solutions.
>>
>> Actually, no. A badly behaved application will kill the N900's battery
>> life. Nobody else has "managed nicely" - they've just made life harder for
>> application developers and users, which may have something to do with the
>> relative levels of market adoption of Maemo and Android. I'm not aware of
>> any form of resource management framework in MeeGo either, so as far as I
>> know it'll have exactly the same problem.
>
> It's true that a braindead app can kill the battery.
>
> However we provide a version of powertop that is tailored to the N900, there
> is a nokia energy profiler meant to give graphical representation of the
> battery current, there is htop available and you can even get the processor
> activity visualized on the leftmost and rightmost keyboard backlight LEDS,
> when in RD mode and with screen blanked.
>
> I would advice you to not start debating on company strategies, this is not
> the right place.

At a certain point, if one side of the argument is using "N900 / OMAP3
works just fine as is" (which has certainly been the case stated by a
number of folks throughout these discussions), I think it's a little
unrealistic to express shock that somebody argues the opposing point.

I've personally avoided commenting on specific power management issues
or properties of competitive platforms because it can easily be viewed
as rather rude or unprofessional.  (though in theory we all could
benefit from any improvements to the kernel regarding power
management, no?).

I am quite willing to state that on both MSM and OMAP based Android
platforms, we've found that the suspend blocker model allows us to
obtain a lower average power draw than if we don't use it -- Mike Chan
provided some numbers earlier in another thread in the trivial device
idle case, the win is of course much larger in the case of several
poorly behaved apps being active.

I do think that everyone involved agrees that it is beneficial to
educate users and developers in hopes that users will understand that
some apps are non-optimal and developers will be encouraged to write
better apps.

I think we also all agree that striving to obtain the lowest power
state at all times through cpu frequency scaling, runtime pm, drivers
that aggressively clock/power down when idle, etc is a worthy goal.
Some have argued that suspend blockers may deter further development
in these areas, but I think this is unlikely -- power usage while the
device is active and the user is interacting with it is just as
critical as when it's not being used interactively.  We (Android)
certainly pursue aggressive low power optimization in both states.

There appears to be some disagreement in terms of what one should do
in the face of poorly behaved applications.  The Android approach has
been to both gather as much data as possible for education of user and
developer and to mitigate the impact of poorly written apps on
endusers, goals which are aided by the suspend blocker model.

A reality of a mass market device with a completely open and
unrestricted application development and distribution ecosystem is
that there will be plenty of non-optimal apps available to users
(Sturgeon's Law applies everywhere, after all).  Worse yet, many of
these non-optimal apps may be beloved by users for various reasons.  I
think there's value in trying to do the best you can power-wise even
in the face of such horrible foes as the dreaded Bouncing Cows App
that Matthew is fond of citing as an example.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 14:30:36 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > [Total kernel changes
> > 
> >         Ability to mark/unmark a scheduler control group as outside of
> >         some parts of idle consideration. Generically useful and
> >         localised. Group latency will do most jobs fine (Zygo is correct
> >         it can't solve his backup case elegantly I think)
> > 
> >         Test in the idling logic to distinguish the case and only needed
> >         for a single Android specific power module. Generically useful
> >         and localised] 
> 
> I really don't like this..
> 
> Why can't we go with the previously suggested: make bad apps block on
> QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL

Ok. Are you happy with the QoS being attached to a scheduler control
group and the use of them to figure out what is what ?

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 14:30:36 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > [Total kernel changes
> > 
> >         Ability to mark/unmark a scheduler control group as outside of
> >         some parts of idle consideration. Generically useful and
> >         localised. Group latency will do most jobs fine (Zygo is correct
> >         it can't solve his backup case elegantly I think)
> > 
> >         Test in the idling logic to distinguish the case and only needed
> >         for a single Android specific power module. Generically useful
> >         and localised] 
> 
> I really don't like this..
> 
> Why can't we go with the previously suggested: make bad apps block on
> QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL

Ok. Are you happy with the QoS being attached to a scheduler control
group and the use of them to figure out what is what ?

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> On Fri, 28 May 2010 14:30:36 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > [Total kernel changes
> > > 
> > >         Ability to mark/unmark a scheduler control group as outside of
> > >         some parts of idle consideration. Generically useful and
> > >         localised. Group latency will do most jobs fine (Zygo is correct
> > >         it can't solve his backup case elegantly I think)
> > > 
> > >         Test in the idling logic to distinguish the case and only needed
> > >         for a single Android specific power module. Generically useful
> > >         and localised] 
> > 
> > I really don't like this..
> > 
> > Why can't we go with the previously suggested: make bad apps block on
> > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> 
> Ok. Are you happy with the QoS being attached to a scheduler control
> group and the use of them to figure out what is what ?

Up to a point, but explicitly not running runnable tasks complicates the
task model significantly, and interacts with fun stuff like bandwidth
inheritance and priority/deadline inheritance like things -- a subject
you really don't want to complicate further.

We really want to do our utmost best to make applications block on
something without altering our task model.

If applications keep running despite being told repeatedly to cease, I
think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
SIGTERM before that) and got ample opportunity to block on something.

Traditional cpu resource management treats the CPU as an ever
replenished resource, breaking that assumption (not running runnable
tasks) puts us on very shaky ground indeed.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> On Fri, 28 May 2010 14:30:36 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > [Total kernel changes
> > > 
> > >         Ability to mark/unmark a scheduler control group as outside of
> > >         some parts of idle consideration. Generically useful and
> > >         localised. Group latency will do most jobs fine (Zygo is correct
> > >         it can't solve his backup case elegantly I think)
> > > 
> > >         Test in the idling logic to distinguish the case and only needed
> > >         for a single Android specific power module. Generically useful
> > >         and localised] 
> > 
> > I really don't like this..
> > 
> > Why can't we go with the previously suggested: make bad apps block on
> > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> 
> Ok. Are you happy with the QoS being attached to a scheduler control
> group and the use of them to figure out what is what ?

Up to a point, but explicitly not running runnable tasks complicates the
task model significantly, and interacts with fun stuff like bandwidth
inheritance and priority/deadline inheritance like things -- a subject
you really don't want to complicate further.

We really want to do our utmost best to make applications block on
something without altering our task model.

If applications keep running despite being told repeatedly to cease, I
think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
SIGTERM before that) and got ample opportunity to block on something.

Traditional cpu resource management treats the CPU as an ever
replenished resource, breaking that assumption (not running runnable
tasks) puts us on very shaky ground indeed.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:49:36PM -0700, Mike Chan wrote:

> Even if we used the proposed QoS replacement, are there suggestions on
> how to keep the cpu idle for longer than 2 seconds in Linux without
> using suspend?

I believe that the "Maximum idle time on 32-bit is 2 seconds" issue is 
solved in recent kernels.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Thu, May 27, 2010 at 05:49:36PM -0700, Mike Chan wrote:

> Even if we used the proposed QoS replacement, are there suggestions on
> how to keep the cpu idle for longer than 2 seconds in Linux without
> using suspend?

I believe that the "Maximum idle time on 32-bit is 2 seconds" issue is 
solved in recent kernels.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
>
> What I consider plain wrong i to claim that since there are this many units
> out, some code should be merged.

I've never suggested that we should get a get-out-of-code-review-free
card or be automatically merged based on shipping volume.

Hell, I never thought we should even bother trying to merge wakelocks
upstream, because I assumed that they'd be hated for not being the
linux way (tm).  Greg KH and others have spent a bunch of time
shouting at me (or Google) that we should be doing this, and here we
are giving it a go.  At this point we've spent more engineering time
on revising this one patchset (10 revisions to address various rounds
of feedback) and discussion of it than we have on rebasing our working
kernel trees to roughly every other linux release from 2.6.16 to
2.6.32 (which became much easier after switching to git).

> A company needs to cut corners sometimes when making a product but this
> should not affect upstream code.

I will disagree that wakelocks are "cutting corners" (we certainly
have some corner cutting code in our trees, because yeah, ship is
compromise, but I don't believe wakelocks are an example).  They're a
real solution for real problems faced on real devices.  Obviously not
a solution that everyone here likes, and maybe they'll never end up in
mainline as a result, but so far I haven't seen a counter proposed
solution that seems to solve the same problem, avoid races, and be
simpler/cleaner (at least to my eyes).

>> I am quite willing to state that on both MSM and OMAP based Android
>> platforms, we've found that the suspend blocker model allows us to
>> obtain a lower average power draw than if we don't use it -- Mike Chan
>> provided some numbers earlier in another thread in the trivial device
>> idle case, the win is of course much larger in the case of several
>> poorly behaved apps being active.
>
> That's very good. But if it is done in a conceptually flawed way, some
> better solution should be considered for upstream merge.

How is it flawed?  Serious question.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
>
> What I consider plain wrong i to claim that since there are this many units
> out, some code should be merged.

I've never suggested that we should get a get-out-of-code-review-free
card or be automatically merged based on shipping volume.

Hell, I never thought we should even bother trying to merge wakelocks
upstream, because I assumed that they'd be hated for not being the
linux way (tm).  Greg KH and others have spent a bunch of time
shouting at me (or Google) that we should be doing this, and here we
are giving it a go.  At this point we've spent more engineering time
on revising this one patchset (10 revisions to address various rounds
of feedback) and discussion of it than we have on rebasing our working
kernel trees to roughly every other linux release from 2.6.16 to
2.6.32 (which became much easier after switching to git).

> A company needs to cut corners sometimes when making a product but this
> should not affect upstream code.

I will disagree that wakelocks are "cutting corners" (we certainly
have some corner cutting code in our trees, because yeah, ship is
compromise, but I don't believe wakelocks are an example).  They're a
real solution for real problems faced on real devices.  Obviously not
a solution that everyone here likes, and maybe they'll never end up in
mainline as a result, but so far I haven't seen a counter proposed
solution that seems to solve the same problem, avoid races, and be
simpler/cleaner (at least to my eyes).

>> I am quite willing to state that on both MSM and OMAP based Android
>> platforms, we've found that the suspend blocker model allows us to
>> obtain a lower average power draw than if we don't use it -- Mike Chan
>> provided some numbers earlier in another thread in the trivial device
>> idle case, the win is of course much larger in the case of several
>> poorly behaved apps being active.
>
> That's very good. But if it is done in a conceptually flawed way, some
> better solution should be considered for upstream merge.

How is it flawed?  Serious question.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Theodore Tso wrote:

>
>
> Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler.   

No, the strategy is to try to merge commercial and community needs.

We do support signed repositories.

The community has control on the public one.

Members are encouraged to help by alpha/beta testing apps that are under 
development.
They even organize testing marathons.

> But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder.

That's a wrong way to put it. By installing something on your phone you 
_do_ approve it.

>    I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository".

What it meant is totally different. Regardless how much effort you put 
into twisting it.
It means that different repositories provide different level of trust.

As Debian user, I don't blame anybody other than myself is something 
I've pulled from unstable or experimental breaks my system.
Debian by default doesn't ship with either unstable or experimental enabled.

And using suspend blockers doesn't really solve the problem of who to 
trust to take the block and who not.

Or we'll have to have suspend-blockers-blockers and so on ...

Like it or not, QoS and resource management - in some form - are needed 
to allow trusted application to provide valuable feedback, while 
filtering requests from untrusted applications.

You might want to add dynamic profiling and try to use some heuristic to 
have the system doing runtime evaluation of good vs bad applications, 
but still some discrimination mechanism will be required.


igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Theodore Tso wrote:

>
>
> Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler.   

No, the strategy is to try to merge commercial and community needs.

We do support signed repositories.

The community has control on the public one.

Members are encouraged to help by alpha/beta testing apps that are under 
development.
They even organize testing marathons.

> But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder.

That's a wrong way to put it. By installing something on your phone you 
_do_ approve it.

>    I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository".

What it meant is totally different. Regardless how much effort you put 
into twisting it.
It means that different repositories provide different level of trust.

As Debian user, I don't blame anybody other than myself is something 
I've pulled from unstable or experimental breaks my system.
Debian by default doesn't ship with either unstable or experimental enabled.

And using suspend blockers doesn't really solve the problem of who to 
trust to take the block and who not.

Or we'll have to have suspend-blockers-blockers and so on ...

Like it or not, QoS and resource management - in some form - are needed 
to allow trusted application to provide valuable feedback, while 
filtering requests from untrusted applications.

You might want to add dynamic profiling and try to use some heuristic to 
have the system doing runtime evaluation of good vs bad applications, 
but still some discrimination mechanism will be required.


igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Brian Swetland wrote:

> At a certain point, if one side of the argument is using "N900 / OMAP3
> works just fine as is" (which has certainly been the case stated by a
> number of folks throughout these discussions), I think it's a little
> unrealistic to express shock that somebody argues the opposing point.
>   
The problem lies in the definition of the goal and means to achieve it.
We do rely on repositories to discriminate on the quality of applications.
As I stated some are accessible and run by our community.

So, in this scenario, it works well enough.

> I've personally avoided commenting on specific power management issues
> or properties of competitive platforms because it can easily be viewed
> as rather rude or unprofessional.  (though in theory we all could
> benefit from any improvements to the kernel regarding power
> management, no?).
>   

What I consider plain wrong i to claim that since there are this many 
units out, some code should be merged.
A company needs to cut corners sometimes when making a product but this 
should not affect upstream code.
> I am quite willing to state that on both MSM and OMAP based Android
> platforms, we've found that the suspend blocker model allows us to
> obtain a lower average power draw than if we don't use it -- Mike Chan
> provided some numbers earlier in another thread in the trivial device
> idle case, the win is of course much larger in the case of several
> poorly behaved apps being active.
>   

That's very good. But if it is done in a conceptually flawed way, some 
better solution should be considered for upstream merge.

[snip]
> A reality of a mass market device with a completely open and
> unrestricted application development and distribution ecosystem is
> that there will be plenty of non-optimal apps available to users
> (Sturgeon's Law applies everywhere, after all).  Worse yet, many of
> these non-optimal apps may be beloved by users for various reasons.  I
> think there's value in trying to do the best you can power-wise even
> in the face of such horrible foes as the dreaded Bouncing Cows App
> that Matthew is fond of citing as an example.

Sure.

I simply disagree on the methods proposed (suspend_blockers) and some of 
the rationale used for promoting them (volume of otherwise unsupported 
units).

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Brian Swetland wrote:

> At a certain point, if one side of the argument is using "N900 / OMAP3
> works just fine as is" (which has certainly been the case stated by a
> number of folks throughout these discussions), I think it's a little
> unrealistic to express shock that somebody argues the opposing point.
>   
The problem lies in the definition of the goal and means to achieve it.
We do rely on repositories to discriminate on the quality of applications.
As I stated some are accessible and run by our community.

So, in this scenario, it works well enough.

> I've personally avoided commenting on specific power management issues
> or properties of competitive platforms because it can easily be viewed
> as rather rude or unprofessional.  (though in theory we all could
> benefit from any improvements to the kernel regarding power
> management, no?).
>   

What I consider plain wrong i to claim that since there are this many 
units out, some code should be merged.
A company needs to cut corners sometimes when making a product but this 
should not affect upstream code.
> I am quite willing to state that on both MSM and OMAP based Android
> platforms, we've found that the suspend blocker model allows us to
> obtain a lower average power draw than if we don't use it -- Mike Chan
> provided some numbers earlier in another thread in the trivial device
> idle case, the win is of course much larger in the case of several
> poorly behaved apps being active.
>   

That's very good. But if it is done in a conceptually flawed way, some 
better solution should be considered for upstream merge.

[snip]
> A reality of a mass market device with a completely open and
> unrestricted application development and distribution ecosystem is
> that there will be plenty of non-optimal apps available to users
> (Sturgeon's Law applies everywhere, after all).  Worse yet, many of
> these non-optimal apps may be beloved by users for various reasons.  I
> think there's value in trying to do the best you can power-wise even
> in the face of such horrible foes as the dreaded Bouncing Cows App
> that Matthew is fond of citing as an example.

Sure.

I simply disagree on the methods proposed (suspend_blockers) and some of 
the rationale used for promoting them (volume of otherwise unsupported 
units).

igor

Re: Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Pavel Machek]

Hi!

> > I don't fully understand your requirements for accounting of devices drivers
> > rejecting or blocking a suspend, so I cannot say precisely how that would fit
> > in.  Maybe you just need to know - whenever the 'suspend request' completes -
> > what the wakeup events were.  It shouldn't be too hard to export that to
> > user-space via sysfs.
> >
> > I won't propose an exact enhancement to the user-space interface for
> > requesting a suspend, but I suspect it should expose each of
> >  suspend_prepare
> >  suspend_devices_and_enter
> >  suspend_finish
> > (or close analogues there-of) to user-space.  It is tempting to map those to
> > "open-for-write", "write", "close", but I'm not sure that suspend_prepare
> > would be appropriate if the app was about to write "disk" - it is a pity that
> > both suspend and hibernate use the same sysfs file.
> >
> > So just fix the bug, and everyone will be happy :-)
> >
> 
> I already have, but everyone do not appear to be happy.

Half of the code you submitted was infrastructure for debugging
userspace. Sorry, that does not count as a bugfix.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[tytso]

On Fri, May 28, 2010 at 04:32:15PM +0300, Igor Stoppa wrote:
> 
> What I consider plain wrong i to claim that since there are this
> many units out, some code should be merged.
> A company needs to cut corners sometimes when making a product but
> this should not affect upstream code.

Linus will disagree with you there.  Linus *has* merged code on the
basis that it is shipping in distributions, regardless of the fact
that some developers objected to it.  Sometimes "perfect" should not
be the enemy of "good enough" shipping code.

For example, I used to point out that we shipped PCMCIA code in
mainline that had a 10% chance of crashing the system if you ejected
the card.  NetBSD was proud to say that their code was so iron-clad
and well designed that it always did the right thing, even if you
ejected while it was busily passing network traffic.  Unfortunately,
NetBSD had working PCMCIA support 3 years later than Linux.  So it
used to be that we were the technical pragmatists (and Linus
fortunately, still very much is the pragmatists, while others were the
hard-line perfectionists.  It seems to me we've started getting some
of the NetBSD attitude infecting LKML, and IMHO, that's unfortunate.

We've rewritten our networking stack, 3 or 4 times, depending on how
you count.  And sometimes shipping in products counts for a lot.  It
doesn't count for everything, and it isn't a get-out-of-jail card, for
sure.  But if it's a hard problem, and we have something that's good
enough, maybe the right call is to merge it now, and we'll rework
things to make something better and more general later.  Ultimately
that's a call only Linus can make.

If everyone agrees we're making progress, and we can let this 100+
mail thread keep going.  But if anyone feels that we are spinning
endlessly without making forward progress (which is after all the same
criteria the OOM killer uses, no? :-), people should remember that
sometimes Linus *has* ended arguments that have gone on too long by
making a "merge or kill" decision.

						- Ted

Re: [PATCH 0/8] Suspend block api (version 8)

[tytso]

On Fri, May 28, 2010 at 04:32:15PM +0300, Igor Stoppa wrote:
> 
> What I consider plain wrong i to claim that since there are this
> many units out, some code should be merged.
> A company needs to cut corners sometimes when making a product but
> this should not affect upstream code.

Linus will disagree with you there.  Linus *has* merged code on the
basis that it is shipping in distributions, regardless of the fact
that some developers objected to it.  Sometimes "perfect" should not
be the enemy of "good enough" shipping code.

For example, I used to point out that we shipped PCMCIA code in
mainline that had a 10% chance of crashing the system if you ejected
the card.  NetBSD was proud to say that their code was so iron-clad
and well designed that it always did the right thing, even if you
ejected while it was busily passing network traffic.  Unfortunately,
NetBSD had working PCMCIA support 3 years later than Linux.  So it
used to be that we were the technical pragmatists (and Linus
fortunately, still very much is the pragmatists, while others were the
hard-line perfectionists.  It seems to me we've started getting some
of the NetBSD attitude infecting LKML, and IMHO, that's unfortunate.

We've rewritten our networking stack, 3 or 4 times, depending on how
you count.  And sometimes shipping in products counts for a lot.  It
doesn't count for everything, and it isn't a get-out-of-jail card, for
sure.  But if it's a hard problem, and we have something that's good
enough, maybe the right call is to merge it now, and we'll rework
things to make something better and more general later.  Ultimately
that's a call only Linus can make.

If everyone agrees we're making progress, and we can let this 100+
mail thread keep going.  But if anyone feels that we are spinning
endlessly without making forward progress (which is after all the same
criteria the OOM killer uses, no? :-), people should remember that
sometimes Linus *has* ended arguments that have gone on too long by
making a "merge or kill" decision.

						- Ted

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > 	The UI manager gets told the phone is 'down'
> > 	Ten seconds later it is still down
>             <- wakeup event that should be delivered to untrusted app arrives here
> 
> At this point you may mark the downtrodden group as ignored between the 
> untrusted app receiving the event and the untrusted app marking itself 
> as important. To avoid this you need the UI manager to receive every 
> wakeup event in order to change its scheduling decisions.

The event wakes the device, the event itself means the kernel is doing
bits so the kernel is active and we are not idled so we have a time
before we will consider re-suspending.

[If you accept that untrusted apps must be constrained then you can't
 allow one to mark itself important - or at least you can't listen to it
 doing so and it goes to the static case which is trivial]

> (The cgroup has to have some awareness of suspend/resume so that it can 
> allow the untrusted apps to be scheduled again)

I don't think so. The apps will get scheduled anyway when not suspended.
The only reason they are not being scheduled is that the device is
suspended.

> Not just the button driver. Every driver that generates wakeupa. This 
> gets difficult when it comes to the network layer, for instance, when 
> the network driver has very little idea how the packet it just received 
> will be routed.

No. Every driver which generates wakeups which should wake an untrusted
application. If network packets to untrusted applications should wake the
box up then a simple background ping process left running is going to
drain your battery and bugger your containment of the mess completely as
you've just accepted an infinite supply of untrusted timed wakeup events
with delay.

> > Apart from that optional paranoia case my kernel now contains some
> > trivial changes of generic value that have nothing to do with suspend
> > blocking. Android has suspend blocking by choosing to use the generic
> > features in its own specific way and we need almost no code writing ?
> 
> The problem is that you still have a race, and fixing that race requires 
> every event that could generate a wakeup to be proxied out to the policy 
> manager as well. That's a moderate additional overhead.

I am not convinced at this point. If the app gets put into the important
group by the driver then you don't need to poke a policy manager.

This again moves us beyond containment because we just allowed an
'untrusted' app a way to be trusted - just as it might abuse a suspend
blocker.

If you accept untrusted apps can't be fixed (for example they could
simply lose the event internally due to app code bugs) then the static
case all looks pretty trivial.

With a Meego hat on you'd dump all the stuff you didn't trust into a
scheduler group and tell the suspend aspect of the idle choice to ignore
it when the screen blanks. While you are it you also get a free ticket to
putting trusted rt apps into the 'and don't even C6' group.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > 	The UI manager gets told the phone is 'down'
> > 	Ten seconds later it is still down
>             <- wakeup event that should be delivered to untrusted app arrives here
> 
> At this point you may mark the downtrodden group as ignored between the 
> untrusted app receiving the event and the untrusted app marking itself 
> as important. To avoid this you need the UI manager to receive every 
> wakeup event in order to change its scheduling decisions.

The event wakes the device, the event itself means the kernel is doing
bits so the kernel is active and we are not idled so we have a time
before we will consider re-suspending.

[If you accept that untrusted apps must be constrained then you can't
 allow one to mark itself important - or at least you can't listen to it
 doing so and it goes to the static case which is trivial]

> (The cgroup has to have some awareness of suspend/resume so that it can 
> allow the untrusted apps to be scheduled again)

I don't think so. The apps will get scheduled anyway when not suspended.
The only reason they are not being scheduled is that the device is
suspended.

> Not just the button driver. Every driver that generates wakeupa. This 
> gets difficult when it comes to the network layer, for instance, when 
> the network driver has very little idea how the packet it just received 
> will be routed.

No. Every driver which generates wakeups which should wake an untrusted
application. If network packets to untrusted applications should wake the
box up then a simple background ping process left running is going to
drain your battery and bugger your containment of the mess completely as
you've just accepted an infinite supply of untrusted timed wakeup events
with delay.

> > Apart from that optional paranoia case my kernel now contains some
> > trivial changes of generic value that have nothing to do with suspend
> > blocking. Android has suspend blocking by choosing to use the generic
> > features in its own specific way and we need almost no code writing ?
> 
> The problem is that you still have a race, and fixing that race requires 
> every event that could generate a wakeup to be proxied out to the policy 
> manager as well. That's a moderate additional overhead.

I am not convinced at this point. If the app gets put into the important
group by the driver then you don't need to poke a policy manager.

This again moves us beyond containment because we just allowed an
'untrusted' app a way to be trusted - just as it might abuse a suspend
blocker.

If you accept untrusted apps can't be fixed (for example they could
simply lose the event internally due to app code bugs) then the static
case all looks pretty trivial.

With a Meego hat on you'd dump all the stuff you didn't trust into a
scheduler group and tell the suspend aspect of the idle choice to ignore
it when the screen blanks. While you are it you also get a free ticket to
putting trusted rt apps into the 'and don't even C6' group.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 12:41:23 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
> 
> > The other vendors appear to be managing nicely without magic blockers. I
> > conjecture therefore there are other solutions.
> 
> Actually, no. A badly behaved application will kill the N900's battery 
> life. Nobody else has "managed nicely" - they've just made life harder 
> for application developers and users, which may have something to do 
> with the relative levels of market adoption of Maemo and Android. I'm 
> not aware of any form of resource management framework in MeeGo either, 
> so as far as I know it'll have exactly the same problem.

Maemo has battery management applications. Right now they show you what
is going on but haven't gone to a pop-up 'XYZ is eating all your battery'
kill it behaviour. The information is there.

If my phone eventually becomes a 1GB RAM PC class system I will be running
PC class apps on it and I will be migrating virtual machines to and from
my phone which have no idea about the device properties of each device
they migrate to and from.

Be that as it may the question of how you manage a naughty app is a good
one. Historically we've managed them for network abuse, memory abuse, cpu
use abuse, access rights, but not yet power.

Whether that looks like

	setrlimit(pid, LIMIT_CHARGE, 150mWH);

or
	setrlimit(pid, LIMIT_POWER, 150mW);

or something else is the question. I rather like the above but I don't
see how to implement them nicely at the moment.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 12:41:23 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
> 
> > The other vendors appear to be managing nicely without magic blockers. I
> > conjecture therefore there are other solutions.
> 
> Actually, no. A badly behaved application will kill the N900's battery 
> life. Nobody else has "managed nicely" - they've just made life harder 
> for application developers and users, which may have something to do 
> with the relative levels of market adoption of Maemo and Android. I'm 
> not aware of any form of resource management framework in MeeGo either, 
> so as far as I know it'll have exactly the same problem.

Maemo has battery management applications. Right now they show you what
is going on but haven't gone to a pop-up 'XYZ is eating all your battery'
kill it behaviour. The information is there.

If my phone eventually becomes a 1GB RAM PC class system I will be running
PC class apps on it and I will be migrating virtual machines to and from
my phone which have no idea about the device properties of each device
they migrate to and from.

Be that as it may the question of how you manage a naughty app is a good
one. Historically we've managed them for network abuse, memory abuse, cpu
use abuse, access rights, but not yet power.

Whether that looks like

	setrlimit(pid, LIMIT_CHARGE, 150mWH);

or
	setrlimit(pid, LIMIT_POWER, 150mW);

or something else is the question. I rather like the above but I don't
see how to implement them nicely at the moment.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think you are missing the point. It works fine if the alarm caused
> the wakeup, but if you had just used your system and your inactivity
> timeout expired just as your alarm goes off, the alarm will not wake
> the system, nor does it prevent it from suspending.

As far as I can tell (and its an extremely hard situation to replicate),
this is not true. My laptop sleeps and wakes straight back up.

The following cannot occur on my laptop for simple idling

	Alarm
		Suspend

because the Alarm resets the suspend timer when it is delivered. The wake
pins and wake logic also ensure that the sequence

		Suspend
			Alarm

always causes

		Suspend
			Alarm
		Suspend Finishes
		Resume


> > If I suspend/resume my laptop every time I have a 30 second idle gap I
> > will need a new laptop much sooner than makes me happy.
> >
> 
> Then don't set your inactivity timeout to 30 seconds. I don't see how
> this is relevant.

It's very relevant because it means that considering current laptops is
not that important because they can't do this kind of fast sleep/wakeup

> > I don't claim this is true for a typical mobile phone obviously.
> >
> The only difference on the phone is that we have way more wakeup
> events which makes the race conditions more visible. The race exist on
> your laptop as well.

The number of events is I think only partly relevant. What matters is how
long you wait between idle and suspending. The longer you wait the less
potential you have to end up with an event successfully owned by an
application you are not considering relevant to suspend.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think you are missing the point. It works fine if the alarm caused
> the wakeup, but if you had just used your system and your inactivity
> timeout expired just as your alarm goes off, the alarm will not wake
> the system, nor does it prevent it from suspending.

As far as I can tell (and its an extremely hard situation to replicate),
this is not true. My laptop sleeps and wakes straight back up.

The following cannot occur on my laptop for simple idling

	Alarm
		Suspend

because the Alarm resets the suspend timer when it is delivered. The wake
pins and wake logic also ensure that the sequence

		Suspend
			Alarm

always causes

		Suspend
			Alarm
		Suspend Finishes
		Resume


> > If I suspend/resume my laptop every time I have a 30 second idle gap I
> > will need a new laptop much sooner than makes me happy.
> >
> 
> Then don't set your inactivity timeout to 30 seconds. I don't see how
> this is relevant.

It's very relevant because it means that considering current laptops is
not that important because they can't do this kind of fast sleep/wakeup

> > I don't claim this is true for a typical mobile phone obviously.
> >
> The only difference on the phone is that we have way more wakeup
> events which makes the race conditions more visible. The race exist on
> your laptop as well.

The number of events is I think only partly relevant. What matters is how
long you wait between idle and suspending. The longer you wait the less
potential you have to end up with an event successfully owned by an
application you are not considering relevant to suspend.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 02:54:20PM +0100, Alan Cox wrote:

> I am not convinced at this point. If the app gets put into the important
> group by the driver then you don't need to poke a policy manager.

Ok, I think I've misunderstood you. You're actually saying that only 
applications that are trusted to behave well are allowed to receive 
wakeup events? Yes, that makes implementation significantly easier. If 
that maps reasonably well onto the existing Android application space, 
it may even be an acceptable compromise.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 02:54:20PM +0100, Alan Cox wrote:

> I am not convinced at this point. If the app gets put into the important
> group by the driver then you don't need to poke a policy manager.

Ok, I think I've misunderstood you. You're actually saying that only 
applications that are trusted to behave well are allowed to receive 
wakeup events? Yes, that makes implementation significantly easier. If 
that maps reasonably well onto the existing Android application space, 
it may even be an acceptable compromise.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote:

> The following cannot occur on my laptop for simple idling
> 
> 	Alarm
> 		Suspend
> 
> because the Alarm resets the suspend timer when it is delivered.

Userspace is about to write to /sys/power/state when it gets scheduled. 
Alarm delivery occurs at that instant. Kernel has no idea that it's 
about to go to sleep, so the driver handles things appropriately and 
clears the hardware state. Userspace gets scheduled, writes and the 
system suspends. The problem is that having userspace decidie to 
initiate a suspend and then actually initiate a suspend isn't an atomic 
operation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote:

> The following cannot occur on my laptop for simple idling
> 
> 	Alarm
> 		Suspend
> 
> because the Alarm resets the suspend timer when it is delivered.

Userspace is about to write to /sys/power/state when it gets scheduled. 
Alarm delivery occurs at that instant. Kernel has no idea that it's 
about to go to sleep, so the driver handles things appropriately and 
clears the hardware state. Userspace gets scheduled, writes and the 
system suspends. The problem is that having userspace decidie to 
initiate a suspend and then actually initiate a suspend isn't an atomic 
operation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?

Here are the deficiencies in the current PM-QOS implementation which 
would need to be solved for Android's purposes:

	The system includes parameters for latency and throughput.
	It does not include a parameter to describe whether timers
	are enabled.  The presumption is that timers are always
	enabled.

For example, the low-power state used by Android would be described as
one in which the CPU does not run and timers are disabled, with some
appropriate latencies and zero throughput.  On some platforms even some
interrupt sources are disabled (those not marked as wakeup-enabled).

	There's no way to indicate minimum system operating 
	requirements.

For example, we may know that work needs to be done without knowing 
specifically which processes are going to carry out that work.  In such 
cases we would like to require that the CPU continues to run at a 
certain minimum speed so long as _any_ threads are runnable, even if 
those threads don't have any QOS requirements of their own.

Similarly, the requirement that timers be enabled is a system-wide sort 
of thing, not necessarily applying to a particular thread (and in fact, 
not all timers are associated with a thread anyway).

	There's no way to boost the minimum system operating
	requirements upon the arrival of an event.

For example, when an input event enters the queue, it should be
possible to prevent the system from entering its lowest power state
until the event can be consumed by userspace.  Simply boosting the QOS
requirements of the threads waiting on the input queue isn't good
enough, because there may not be any such threads when the event occurs 
(they may be busy doing something else).

The matter of _which_ events should boost the system operating
requirements is debatable.  In the Android proposal it is a fixed set:
those events which enable a suspend blocker.  In theory it could
instead be determined by requests from userspace, although I don't know
how such requests would be expressed.


Until these weaknesses are rectified, Android cannot use the PM-QOS 
system or idle-time power management to satisfy its needs.  That's why 
they have to resort to forced suspends.

Can the PM-QOS framework be enhanced to include these considerations?  
I don't see why not (but on the other hand, I know nothing about its
internal workings).

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?

Here are the deficiencies in the current PM-QOS implementation which 
would need to be solved for Android's purposes:

	The system includes parameters for latency and throughput.
	It does not include a parameter to describe whether timers
	are enabled.  The presumption is that timers are always
	enabled.

For example, the low-power state used by Android would be described as
one in which the CPU does not run and timers are disabled, with some
appropriate latencies and zero throughput.  On some platforms even some
interrupt sources are disabled (those not marked as wakeup-enabled).

	There's no way to indicate minimum system operating 
	requirements.

For example, we may know that work needs to be done without knowing 
specifically which processes are going to carry out that work.  In such 
cases we would like to require that the CPU continues to run at a 
certain minimum speed so long as _any_ threads are runnable, even if 
those threads don't have any QOS requirements of their own.

Similarly, the requirement that timers be enabled is a system-wide sort 
of thing, not necessarily applying to a particular thread (and in fact, 
not all timers are associated with a thread anyway).

	There's no way to boost the minimum system operating
	requirements upon the arrival of an event.

For example, when an input event enters the queue, it should be
possible to prevent the system from entering its lowest power state
until the event can be consumed by userspace.  Simply boosting the QOS
requirements of the threads waiting on the input queue isn't good
enough, because there may not be any such threads when the event occurs 
(they may be busy doing something else).

The matter of _which_ events should boost the system operating
requirements is debatable.  In the Android proposal it is a fixed set:
those events which enable a suspend blocker.  In theory it could
instead be determined by requests from userspace, although I don't know
how such requests would be expressed.


Until these weaknesses are rectified, Android cannot use the PM-QOS 
system or idle-time power management to satisfy its needs.  That's why 
they have to resort to forced suspends.

Can the PM-QOS framework be enhanced to include these considerations?  
I don't see why not (but on the other hand, I know nothing about its
internal workings).

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Brian Swetland wrote:

> How is it flawed?  Serious question.
>   

I would avoid repeating all the good arguments given so far, but to make 
it short:

* I believe runtime PM is a much better starting point (at least for the 
type of HW targeted at mobile devices) because it mimics an always-on 
system toward userspace, which requires less disruption in the way apps 
are designed

* QoS is closer to the apps pov: fps if it is a media player or a game, 
transfer speed if it is a file manager, bandwidth if it is a network 
app, etc
The app is required to express its opinion by using a format that it 
understands better and is less system dependent.
Actually the kernel should only be concerned with 2 parameters at most 
for any given operation: latency and bandwidth/throughput

* Some form of resource management is needed as trust mechanism to 
discriminate "trusted" vs untrusted apps that can give reliable info 
(but in your case you should give trust to whom prevents the suspend)

* Most of this could be done in userspace with the kernel merely 
providing the means to enforce the decisions taken by the userspace manager.

* The kernel wouldn't even have to try to outsmart the "evil application 
writer"

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Brian Swetland wrote:

> How is it flawed?  Serious question.
>   

I would avoid repeating all the good arguments given so far, but to make 
it short:

* I believe runtime PM is a much better starting point (at least for the 
type of HW targeted at mobile devices) because it mimics an always-on 
system toward userspace, which requires less disruption in the way apps 
are designed

* QoS is closer to the apps pov: fps if it is a media player or a game, 
transfer speed if it is a file manager, bandwidth if it is a network 
app, etc
The app is required to express its opinion by using a format that it 
understands better and is less system dependent.
Actually the kernel should only be concerned with 2 parameters at most 
for any given operation: latency and bandwidth/throughput

* Some form of resource management is needed as trust mechanism to 
discriminate "trusted" vs untrusted apps that can give reliable info 
(but in your case you should give trust to whom prevents the suspend)

* Most of this could be done in userspace with the kernel merely 
providing the means to enforce the decisions taken by the userspace manager.

* The kernel wouldn't even have to try to outsmart the "evil application 
writer"

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext tytso@mit.edu wrote:

> Linus will disagree with you there.  Linus *has* merged code on the
> basis that it is shipping in distributions, regardless of the fact
> that some developers objected to it.  Sometimes "perfect" should not
> be the enemy of "good enough" shipping code.
>   

"good enough" is very subjective, in this case

> If everyone agrees we're making progress, and we can let this 100+
> mail thread keep going.

I have seen very good proposals for saner solutions.

Is that progress?

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext tytso@mit.edu wrote:

> Linus will disagree with you there.  Linus *has* merged code on the
> basis that it is shipping in distributions, regardless of the fact
> that some developers objected to it.  Sometimes "perfect" should not
> be the enemy of "good enough" shipping code.
>   

"good enough" is very subjective, in this case

> If everyone agrees we're making progress, and we can let this 100+
> mail thread keep going.

I have seen very good proposals for saner solutions.

Is that progress?

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext tytso@mit.edu wrote:

> Linus will disagree with you there.  Linus *has* merged code on the
> basis that it is shipping in distributions, regardless of the fact
> that some developers objected to it.  Sometimes "perfect" should not
> be the enemy of "good enough" shipping code.
>   

"good enough" is very subjective, in this case

> If everyone agrees we're making progress, and we can let this 100+
> mail thread keep going.

I have seen very good proposals for saner solutions.

Is that progress?

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > That's very good. But if it is done in a conceptually flawed way, some
> > better solution should be considered for upstream merge.
> 
> How is it flawed?  Serious question.

- It means changing drivers and quite a few apps
- It doesn't solve the problem of rogue apps if they end up owning locks
- It puts the deep knowledge of the platform in the applications
- It gives the apps control of the action taken not policy indication
- It doesn't resolve the problem of synchronization of take/releases
  stopping any suspend
- The kernel parts are not generically useful, merely effective for
  solving a specific problem right now - even things like VM migration
  to/from phones seems to break it
- It inverts the whole logic the kernel is following and trend it is
  following that suspend is simply a very deep idle (with implementations
  merged)

If it was a localised turd I wouldn't worry. There are plenty df deep
unmentionables hidden away enirely in platform specific code that deal
with everything from stoned hardware engineers to crazed software stack
implementations.

Here is a question back the other way perhaps

- If the existing kerne was almostl entirely read only, or you had to pay
  a large fee per line of code changed outside your own driver how would
  you implement the wakelock/suspend blocker API ?

Because if you take the path that 'we want wakelockers' that is
essentially the question you have to answer. How do you merge it so that
nobody outside of your driver and maybe a spot of arch code knows about
it. You are permitted a couple of sneaky substitions of core function
bits in headers.

Right now bits are going to leak out over the kernel which is the cause of
friction. At the point it's invisible to everyone else they cease to be
stakeholders so you don't have keep them happy. You've only got a couple
in your patches but its painfully obvious from Matthew and your comments
you'll end up needing a ton more and these will get everywhere as Android
grows hardware platforms and CPU support as phones become more featureful
and PC like. The moment a phone grows a USB base station with hub for
example the entire USB stack becomes burdened with them. Matthew has
already indicated networking needs them. Good luck with Dave Miller on
that.

I'm asking questions to look for generalised approaches, or even better
doing it without new kernel stuff in the first place, but it's not the
only way.

Alan

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > That's very good. But if it is done in a conceptually flawed way, some
> > better solution should be considered for upstream merge.
> 
> How is it flawed?  Serious question.

- It means changing drivers and quite a few apps
- It doesn't solve the problem of rogue apps if they end up owning locks
- It puts the deep knowledge of the platform in the applications
- It gives the apps control of the action taken not policy indication
- It doesn't resolve the problem of synchronization of take/releases
  stopping any suspend
- The kernel parts are not generically useful, merely effective for
  solving a specific problem right now - even things like VM migration
  to/from phones seems to break it
- It inverts the whole logic the kernel is following and trend it is
  following that suspend is simply a very deep idle (with implementations
  merged)

If it was a localised turd I wouldn't worry. There are plenty df deep
unmentionables hidden away enirely in platform specific code that deal
with everything from stoned hardware engineers to crazed software stack
implementations.

Here is a question back the other way perhaps

- If the existing kerne was almostl entirely read only, or you had to pay
  a large fee per line of code changed outside your own driver how would
  you implement the wakelock/suspend blocker API ?

Because if you take the path that 'we want wakelockers' that is
essentially the question you have to answer. How do you merge it so that
nobody outside of your driver and maybe a spot of arch code knows about
it. You are permitted a couple of sneaky substitions of core function
bits in headers.

Right now bits are going to leak out over the kernel which is the cause of
friction. At the point it's invisible to everyone else they cease to be
stakeholders so you don't have keep them happy. You've only got a couple
in your patches but its painfully obvious from Matthew and your comments
you'll end up needing a ton more and these will get everywhere as Android
grows hardware platforms and CPU support as phones become more featureful
and PC like. The moment a phone grows a USB base station with hub for
example the entire USB stack becomes burdened with them. Matthew has
already indicated networking needs them. Good luck with Dave Miller on
that.

I'm asking questions to look for generalised approaches, or even better
doing it without new kernel stuff in the first place, but it's not the
only way.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote:

> I have seen very good proposals for saner solutions.
>
> Is that progress?

The proposals so far involve either redefining the problem space or 
being inherently racey. It may be that we can redefine the problem space 
in such a way that everyone's happy, but it's not possible to do so by 
fiat.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote:

> I have seen very good proposals for saner solutions.
>
> Is that progress?

The proposals so far involve either redefining the problem space or 
being inherently racey. It may be that we can redefine the problem space 
in such a way that everyone's happy, but it's not possible to do so by 
fiat.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Just fix the bug - Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Florian Mickler]

On Fri, 28 May 2010 15:35:16 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> > > I don't fully understand your requirements for accounting of devices drivers
> > > rejecting or blocking a suspend, so I cannot say precisely how that would fit
> > > in.  Maybe you just need to know - whenever the 'suspend request' completes -
> > > what the wakeup events were.  It shouldn't be too hard to export that to
> > > user-space via sysfs.
> > >
> > > I won't propose an exact enhancement to the user-space interface for
> > > requesting a suspend, but I suspect it should expose each of
> > >  suspend_prepare
> > >  suspend_devices_and_enter
> > >  suspend_finish
> > > (or close analogues there-of) to user-space.  It is tempting to map those to
> > > "open-for-write", "write", "close", but I'm not sure that suspend_prepare
> > > would be appropriate if the app was about to write "disk" - it is a pity that
> > > both suspend and hibernate use the same sysfs file.
> > >
> > > So just fix the bug, and everyone will be happy :-)
> > >
> > 
> > I already have, but everyone do not appear to be happy.
> 
> Half of the code you submitted was infrastructure for debugging
> userspace. Sorry, that does not count as a bugfix.
> 
That is not the issue here.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Alan Cox wrote:

> Be that as it may the question of how you manage a naughty app is a good
> one. Historically we've managed them for network abuse, memory abuse, cpu
> use abuse, access rights, but not yet power.
>
> Whether that looks like
>
> 	setrlimit(pid, LIMIT_CHARGE, 150mWH);
>
> or
> 	setrlimit(pid, LIMIT_POWER, 150mW);
>
> or something else is the question.

Either way, this will require a detailed model of the system in terms of 
latency, throughput, current consumption and heat generation.

Which can be provided only by the HW manufacturer.

But, should such model be available (and we have some form of it for the 
OMAP3 in N900), then it can be abstracted through generic interfaces, 
which accept constraints and produce the selected target state 
(typically a vector of states for each sub component).

igor

Re: [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Alan Cox wrote:

> Be that as it may the question of how you manage a naughty app is a good
> one. Historically we've managed them for network abuse, memory abuse, cpu
> use abuse, access rights, but not yet power.
>
> Whether that looks like
>
> 	setrlimit(pid, LIMIT_CHARGE, 150mWH);
>
> or
> 	setrlimit(pid, LIMIT_POWER, 150mW);
>
> or something else is the question.

Either way, this will require a detailed model of the system in terms of 
latency, throughput, current consumption and heat generation.

Which can be provided only by the HW manufacturer.

But, should such model be available (and we have some form of it for the 
OMAP3 in N900), then it can be abstracted through generic interfaces, 
which accept constraints and produce the selected target state 
(typically a vector of states for each sub component).

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote:
>
>> I have seen very good proposals for saner solutions.
>>
>> Is that progress?
>
> The proposals so far involve either redefining the problem space or
> being inherently racey. It may be that we can redefine the problem space
> in such a way that everyone's happy, but it's not possible to do so by
> fiat.

I think the suggestion that has the closet fit with what we're trying
to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
constraint of some sort.

Arve points out that qos constraint objects could work (but not if
specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
he suggests that "latency" constraints don't represent this as well as
"state" constraints.

Though if you look at it that way, then suspend_blockers become qos
constraint objects, but their implementation and usage remain pretty
much the same as we have now, which does not address Alan's concern
regarding code turning up in drivers, etc.  I'm not sure how you can
solve this problem (avoiding races around entering/exiting the suspend
or suspend-like state) without having a means for drivers to prevent
entry to that state.

I need to think more about the cgroups approach, but I'm pretty sure
it still suffers from wakeup race situations, and due to the
complexity of userspace (at least ours), I suspect it would risk
livelock/deadlock/priority-inversion style issues due to interaction
between different processes in different groups.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote:
>
>> I have seen very good proposals for saner solutions.
>>
>> Is that progress?
>
> The proposals so far involve either redefining the problem space or
> being inherently racey. It may be that we can redefine the problem space
> in such a way that everyone's happy, but it's not possible to do so by
> fiat.

I think the suggestion that has the closet fit with what we're trying
to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
constraint of some sort.

Arve points out that qos constraint objects could work (but not if
specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
he suggests that "latency" constraints don't represent this as well as
"state" constraints.

Though if you look at it that way, then suspend_blockers become qos
constraint objects, but their implementation and usage remain pretty
much the same as we have now, which does not address Alan's concern
regarding code turning up in drivers, etc.  I'm not sure how you can
solve this problem (avoiding races around entering/exiting the suspend
or suspend-like state) without having a means for drivers to prevent
entry to that state.

I need to think more about the cgroups approach, but I'm pretty sure
it still suffers from wakeup race situations, and due to the
complexity of userspace (at least ours), I suspect it would risk
livelock/deadlock/priority-inversion style issues due to interaction
between different processes in different groups.

Brian

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> If I push the button we get an IRQ
> We come out of power save
> The app gets poked
> The app may be unimportant but the IRQ means we have a new timeout of
>     some form to run down to idle
> The app marks itself important
> The app stays awake for 60 seconds rsyncing your email
> The app marks itself unimportant
> Time elapses
> We return to suspend
> 
> 
> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.

That "private patch to a few drivers" is almost exactly what suspend
blockers are.  Given that much of this discussion has revolved around 
whether suspend blockers are accptable in the kernel, I don't think you 
should shrug them off quite so easily.

Also, you have forgotten about the case where there is no app waiting 
to get poked:

	The app is busy doing something else unimportant
	We do into power save
	Push a button, generate an IRQ
	Come out of power save
	No app to poke
	* System goes back to sleep and eventually wakes up again
	The app finishes what it was doing
	The app sees there is a keystroke and marks itself important
	...

The * step is where trouble can occur.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> If I push the button we get an IRQ
> We come out of power save
> The app gets poked
> The app may be unimportant but the IRQ means we have a new timeout of
>     some form to run down to idle
> The app marks itself important
> The app stays awake for 60 seconds rsyncing your email
> The app marks itself unimportant
> Time elapses
> We return to suspend
> 
> 
> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.

That "private patch to a few drivers" is almost exactly what suspend
blockers are.  Given that much of this discussion has revolved around 
whether suspend blockers are accptable in the kernel, I don't think you 
should shrug them off quite so easily.

Also, you have forgotten about the case where there is no app waiting 
to get poked:

	The app is busy doing something else unimportant
	We do into power save
	Push a button, generate an IRQ
	Come out of power save
	No app to poke
	* System goes back to sleep and eventually wakes up again
	The app finishes what it was doing
	The app sees there is a keystroke and marks itself important
	...

The * step is where trouble can occur.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 07:29:27AM -0700, Brian Swetland wrote:

> I need to think more about the cgroups approach, but I'm pretty sure
> it still suffers from wakeup race situations, and due to the
> complexity of userspace (at least ours), I suspect it would risk
> livelock/deadlock/priority-inversion style issues due to interaction
> between different processes in different groups.

I think the cgroups approach works if you assume that applications that 
consume wakeup events can be trusted to otherwise be good citizens. 
Everything that has no direct interest in wakeup events (except the 
generic Android userspace) can be frozen, and you can use the scheduler 
to make everything else Just Work. That's a rather big if, but you've 
got a better idea of the state of the Android app base than I do.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett]

On Fri, May 28, 2010 at 07:29:27AM -0700, Brian Swetland wrote:

> I need to think more about the cgroups approach, but I'm pretty sure
> it still suffers from wakeup race situations, and due to the
> complexity of userspace (at least ours), I suspect it would risk
> livelock/deadlock/priority-inversion style issues due to interaction
> between different processes in different groups.

I think the cgroups approach works if you assume that applications that 
consume wakeup events can be trusted to otherwise be good citizens. 
Everything that has no direct interest in wakeup events (except the 
generic Android userspace) can be frozen, and you can use the scheduler 
to make everything else Just Work. That's a rather big if, but you've 
got a better idea of the state of the Android app base than I do.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> > On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> > 
> > > > And the forced-suspend design relies on the fact that processes remain 
> > > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > > somehow becomes runnable, that means we have to abort the forced 
> > > > suspend before the process is allowed to run.
> > > 
> > > We could avoid that if drivers could block tasks, but there are questions to
> > > answer.  First off, how a driver is supposed to know when to block the task
> > > using it and when to do its power management transparently for the task?
> > > Second, how to intercept and block all possible interfaces that user space
> > > can use to talk to drivers (how to intercept a task using mmapped device, for
> > > example)?
> > 
> > We talked about this a few years ago and decided it was not feasible.  
> > It would require substantial changes to every device driver.
> 
> But what if its the _right_ thing to do? We make changes to every device
> driver out there on a regular basis. Also, why won't an incremental
> process work? Add the interface with a fallback for drivers that haven't
> implemented it and implement it for those drivers its most urgent (like
> those in use on an Android phone).

There is no reasonable fallback.  In fact, I seriously doubt that
there's any way to carry this out at all, reasonable or not.  For
example, how do you handle the situation where a user task gets an
error because it accessed an mmapped address belonging to a device that
has been suspended?

> Not doing the right thing simply because its a lot of work seems like a
> fine way to let the kernel rot into an unmaintainable mess.

Firstly, it's not at all clear that this _is_ the right thing.

Secondly, when doing the right thing involves making invasive changes 
to half the .c files in the kernel, people might stop to think that it 
would add more bugs than it would solve problems.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> > On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> > 
> > > > And the forced-suspend design relies on the fact that processes remain 
> > > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > > somehow becomes runnable, that means we have to abort the forced 
> > > > suspend before the process is allowed to run.
> > > 
> > > We could avoid that if drivers could block tasks, but there are questions to
> > > answer.  First off, how a driver is supposed to know when to block the task
> > > using it and when to do its power management transparently for the task?
> > > Second, how to intercept and block all possible interfaces that user space
> > > can use to talk to drivers (how to intercept a task using mmapped device, for
> > > example)?
> > 
> > We talked about this a few years ago and decided it was not feasible.  
> > It would require substantial changes to every device driver.
> 
> But what if its the _right_ thing to do? We make changes to every device
> driver out there on a regular basis. Also, why won't an incremental
> process work? Add the interface with a fallback for drivers that haven't
> implemented it and implement it for those drivers its most urgent (like
> those in use on an Android phone).

There is no reasonable fallback.  In fact, I seriously doubt that
there's any way to carry this out at all, reasonable or not.  For
example, how do you handle the situation where a user task gets an
error because it accessed an mmapped address belonging to a device that
has been suspended?

> Not doing the right thing simply because its a lot of work seems like a
> fine way to let the kernel rot into an unmaintainable mess.

Firstly, it's not at all clear that this _is_ the right thing.

Secondly, when doing the right thing involves making invasive changes 
to half the .c files in the kernel, people might stop to think that it 
would add more bugs than it would solve problems.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> > On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> > 
> > > > And the forced-suspend design relies on the fact that processes remain 
> > > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > > somehow becomes runnable, that means we have to abort the forced 
> > > > suspend before the process is allowed to run.
> > > 
> > > We could avoid that if drivers could block tasks, but there are questions to
> > > answer.  First off, how a driver is supposed to know when to block the task
> > > using it and when to do its power management transparently for the task?
> > > Second, how to intercept and block all possible interfaces that user space
> > > can use to talk to drivers (how to intercept a task using mmapped device, for
> > > example)?
> > 
> > We talked about this a few years ago and decided it was not feasible.  
> > It would require substantial changes to every device driver.
> 
> But what if its the _right_ thing to do? We make changes to every device
> driver out there on a regular basis. Also, why won't an incremental
> process work? Add the interface with a fallback for drivers that haven't
> implemented it and implement it for those drivers its most urgent (like
> those in use on an Android phone).

There is no reasonable fallback.  In fact, I seriously doubt that
there's any way to carry this out at all, reasonable or not.  For
example, how do you handle the situation where a user task gets an
error because it accessed an mmapped address belonging to a device that
has been suspended?

> Not doing the right thing simply because its a lot of work seems like a
> fine way to let the kernel rot into an unmaintainable mess.

Firstly, it's not at all clear that this _is_ the right thing.

Secondly, when doing the right thing involves making invasive changes 
to half the .c files in the kernel, people might stop to think that it 
would add more bugs than it would solve problems.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> > On Fri, 28 May 2010 14:30:36 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > > [Total kernel changes
> > > > 
> > > >         Ability to mark/unmark a scheduler control group as outside of
> > > >         some parts of idle consideration. Generically useful and
> > > >         localised. Group latency will do most jobs fine (Zygo is correct
> > > >         it can't solve his backup case elegantly I think)
> > > > 
> > > >         Test in the idling logic to distinguish the case and only needed
> > > >         for a single Android specific power module. Generically useful
> > > >         and localised] 
> > > 
> > > I really don't like this..
> > > 
> > > Why can't we go with the previously suggested: make bad apps block on
> > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> > 
> > Ok. Are you happy with the QoS being attached to a scheduler control
> > group and the use of them to figure out what is what ?
> 
> Up to a point, but explicitly not running runnable tasks complicates the
> task model significantly, and interacts with fun stuff like bandwidth
> inheritance and priority/deadline inheritance like things -- a subject
> you really don't want to complicate further.
> 
> We really want to do our utmost best to make applications block on
> something without altering our task model.
> 
> If applications keep running despite being told repeatedly to cease, I
> think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
> SIGTERM before that) and got ample opportunity to block on something.
> 
> Traditional cpu resource management treats the CPU as an ever
> replenished resource, breaking that assumption (not running runnable
> tasks) puts us on very shaky ground indeed.

Also, I'm not quite sure why we would need cgroups to pull this off.

It seems most of the problems the suspend-blockers are trying to solve
are due to the fact of not running runnable tasks. Not running runnable
tasks can be seen as assigning tasks 0 bandwidth. Which is a situation
extremely prone to all things inversion. Such a situation would require
bandwidth inheritance to function at all, so possibly we can see
suspend-blockers as a misguided implementation of that.

So lets look at the problem, we want to be frugal with power, this means
that the system as a whole should strive to do nothing. And we want to
enforce this as strict as possible.

If we look at the windowing thing, lets call it X, X will inform its
clients about the visibility of their window, any client trying to draw
to its window when it has been informed about it not being visible is
wasting energy and should be punished.

(I really wish the actual X on my desktop would do more of that -- its
utterly rediculous that firefox keeps animating banners and the like
when nobody can possibly see them)

Clearly when we turn the screen off, nothing is visible and all clients
should cease to draw.

How do we want to punish dis-obedient clients? Is blocking them
sufficient? Do we want to maintain a shitlist of iffy clients?

Note that the 'buggy' client doesn't function properly, if we block its
main event loop doing this, it won't respond to other events -- but as
argued, its a buggy app, hence its per definition unreliable and we
don't care.

Next comes the interesting problem of who gets to keep the screen lit, I
think in the above case that is a pure userspace problem and doesn't
need kernel intervention.

Can we apply the same reasoning to other resources, filesystems,
network? For both of them it seems the main governing body isn't this
windowing system, but the kernel (although arguably you could fully do
it in middle-ware, just like X is that).

But in both cases I think we can work with a QoS system where we assign
some service-level to each task, and a server-level (with inverse
priority scales to the task level), and only provide service when
task-level >= server-level. [server-level 0 would serve everybody,
task-level 0 would only get service when everybody does]

If we allow userspace to set server-levels, we need to ensure that
whoever is allowed that is a well functioning program.

We can do a similar thing for wakeups, aside from setting wakeup slack,
we can also set a wakeup limit per task, but I'm not quite sure how that
would work out. That needs more thought. But an application exceeding
its wakeup limit would still need to be woken (not doing so leads to fun
problems) but the event is clearly attributable and loggable.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> > On Fri, 28 May 2010 14:30:36 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > > [Total kernel changes
> > > > 
> > > >         Ability to mark/unmark a scheduler control group as outside of
> > > >         some parts of idle consideration. Generically useful and
> > > >         localised. Group latency will do most jobs fine (Zygo is correct
> > > >         it can't solve his backup case elegantly I think)
> > > > 
> > > >         Test in the idling logic to distinguish the case and only needed
> > > >         for a single Android specific power module. Generically useful
> > > >         and localised] 
> > > 
> > > I really don't like this..
> > > 
> > > Why can't we go with the previously suggested: make bad apps block on
> > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> > 
> > Ok. Are you happy with the QoS being attached to a scheduler control
> > group and the use of them to figure out what is what ?
> 
> Up to a point, but explicitly not running runnable tasks complicates the
> task model significantly, and interacts with fun stuff like bandwidth
> inheritance and priority/deadline inheritance like things -- a subject
> you really don't want to complicate further.
> 
> We really want to do our utmost best to make applications block on
> something without altering our task model.
> 
> If applications keep running despite being told repeatedly to cease, I
> think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
> SIGTERM before that) and got ample opportunity to block on something.
> 
> Traditional cpu resource management treats the CPU as an ever
> replenished resource, breaking that assumption (not running runnable
> tasks) puts us on very shaky ground indeed.

Also, I'm not quite sure why we would need cgroups to pull this off.

It seems most of the problems the suspend-blockers are trying to solve
are due to the fact of not running runnable tasks. Not running runnable
tasks can be seen as assigning tasks 0 bandwidth. Which is a situation
extremely prone to all things inversion. Such a situation would require
bandwidth inheritance to function at all, so possibly we can see
suspend-blockers as a misguided implementation of that.

So lets look at the problem, we want to be frugal with power, this means
that the system as a whole should strive to do nothing. And we want to
enforce this as strict as possible.

If we look at the windowing thing, lets call it X, X will inform its
clients about the visibility of their window, any client trying to draw
to its window when it has been informed about it not being visible is
wasting energy and should be punished.

(I really wish the actual X on my desktop would do more of that -- its
utterly rediculous that firefox keeps animating banners and the like
when nobody can possibly see them)

Clearly when we turn the screen off, nothing is visible and all clients
should cease to draw.

How do we want to punish dis-obedient clients? Is blocking them
sufficient? Do we want to maintain a shitlist of iffy clients?

Note that the 'buggy' client doesn't function properly, if we block its
main event loop doing this, it won't respond to other events -- but as
argued, its a buggy app, hence its per definition unreliable and we
don't care.

Next comes the interesting problem of who gets to keep the screen lit, I
think in the above case that is a pure userspace problem and doesn't
need kernel intervention.

Can we apply the same reasoning to other resources, filesystems,
network? For both of them it seems the main governing body isn't this
windowing system, but the kernel (although arguably you could fully do
it in middle-ware, just like X is that).

But in both cases I think we can work with a QoS system where we assign
some service-level to each task, and a server-level (with inverse
priority scales to the task level), and only provide service when
task-level >= server-level. [server-level 0 would serve everybody,
task-level 0 would only get service when everybody does]

If we allow userspace to set server-levels, we need to ensure that
whoever is allowed that is a well functioning program.

We can do a similar thing for wakeups, aside from setting wakeup slack,
we can also set a wakeup limit per task, but I'm not quite sure how that
would work out. That needs more thought. But an application exceeding
its wakeup limit would still need to be woken (not doing so leads to fun
problems) but the event is clearly attributable and loggable.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think the suggestion that has the closet fit with what we're trying
> to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
> http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
> constraint of some sort.

I think we ended up in the same place on our own.

> Arve points out that qos constraint objects could work (but not if
> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
> he suggests that "latency" constraints don't represent this as well as
> "state" constraints.

With latency you have an "I don't give damn" latency in your model which
we could describe as infinite or "manyana" perhaps.

> Though if you look at it that way, then suspend_blockers become qos
> constraint objects, but their implementation and usage remain pretty
> much the same as we have now, which does not address Alan's concern
> regarding code turning up in drivers, etc.  I'm not sure how you can
> solve this problem (avoiding races around entering/exiting the suspend
> or suspend-like state) without having a means for drivers to prevent
> entry to that state.

I am much much less concerned about general expressions of constraint
appearing in drivers. One of my early mails gave a list of other
people/projects/problems that need them - from hard real time, to high
speed serial on low end embedded to virtualisation.

They fix a general problem in terms of a driver specific item. We end up
making changes around the tree but we make everyone happy not just
Android. Also we are isolating policy properly. The apps and drivers say
"I have these needs", the power manager figures out how to meet them.

Where it gets ugly is if you start trying to have drivers giving an app a
guarantee which the app then magically has to know to dispose of.

If you are prepared to exclude untrusted apps from perfectly reliable
event reporting (ie from finger to application action) that doesn't seem
to be a neccessity anyway.
 
> livelock/deadlock/priority-inversion style issues due to interaction
> between different processes in different groups.

Priority inversion with the cgroup case is like synchronization effects
with the suspend blockers - its a real ugly problem and one that is known
to be hard to fix if you let it happen so I agree there.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think the suggestion that has the closet fit with what we're trying
> to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
> http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
> constraint of some sort.

I think we ended up in the same place on our own.

> Arve points out that qos constraint objects could work (but not if
> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
> he suggests that "latency" constraints don't represent this as well as
> "state" constraints.

With latency you have an "I don't give damn" latency in your model which
we could describe as infinite or "manyana" perhaps.

> Though if you look at it that way, then suspend_blockers become qos
> constraint objects, but their implementation and usage remain pretty
> much the same as we have now, which does not address Alan's concern
> regarding code turning up in drivers, etc.  I'm not sure how you can
> solve this problem (avoiding races around entering/exiting the suspend
> or suspend-like state) without having a means for drivers to prevent
> entry to that state.

I am much much less concerned about general expressions of constraint
appearing in drivers. One of my early mails gave a list of other
people/projects/problems that need them - from hard real time, to high
speed serial on low end embedded to virtualisation.

They fix a general problem in terms of a driver specific item. We end up
making changes around the tree but we make everyone happy not just
Android. Also we are isolating policy properly. The apps and drivers say
"I have these needs", the power manager figures out how to meet them.

Where it gets ugly is if you start trying to have drivers giving an app a
guarantee which the app then magically has to know to dispose of.

If you are prepared to exclude untrusted apps from perfectly reliable
event reporting (ie from finger to application action) that doesn't seem
to be a neccessity anyway.
 
> livelock/deadlock/priority-inversion style issues due to interaction
> between different processes in different groups.

Priority inversion with the cgroup case is like synchronization effects
with the suspend blockers - its a real ugly problem and one that is known
to be hard to fix if you let it happen so I agree there.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Arve points out that qos constraint objects could work (but not if
>> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
>> he suggests that "latency" constraints don't represent this as well as
>> "state" constraints.
>
> With latency you have an "I don't give damn" latency in your model which
> we could describe as infinite or "manyana" perhaps.

I think Arve's concern was the representation of the "I care, but only
a little" or "just low enough to ensure threads must run" level which
is what suspend blockers would map to (low enough to ensure we
shouldn't halt the world but not necessarily implying a hard latency
constraint beyond that).

>> Though if you look at it that way, then suspend_blockers become qos
>> constraint objects, but their implementation and usage remain pretty
>> much the same as we have now, which does not address Alan's concern
>> regarding code turning up in drivers, etc.  I'm not sure how you can
>> solve this problem (avoiding races around entering/exiting the suspend
>> or suspend-like state) without having a means for drivers to prevent
>> entry to that state.
>
> I am much much less concerned about general expressions of constraint
> appearing in drivers. One of my early mails gave a list of other
> people/projects/problems that need them - from hard real time, to high
> speed serial on low end embedded to virtualisation.
>
> They fix a general problem in terms of a driver specific item. We end up
> making changes around the tree but we make everyone happy not just
> Android. Also we are isolating policy properly. The apps and drivers say
> "I have these needs", the power manager figures out how to meet them.

That makes sense -- and as I've mentioned elsewhere, we're really not
super picky about naming -- if it turns out that
wakelocks/suspendblockers were shorthand for "request a qos constraint
that ensures that threads are running", we'll be able to get things
done just as well as we do now.

> Where it gets ugly is if you start trying to have drivers giving an app a
> guarantee which the app then magically has to know to dispose of.

Yeah -- which is something we've avoided in the existing model with
overlapping wakelocks during handoff between domains.
- input service is select()ing on input devices
- when select() returns it grabs a wakelock, reads events, passes them
on, releases the wakelock
- the event subsystem can then safely drop its "should be running
threads" constraint as soon as the last event is read because it has
no queues for userspace to drain, but the overlapping wakelock
prevents the system from immediately snapping back to sleep

> If you are prepared to exclude untrusted apps from perfectly reliable
> event reporting (ie from finger to application action) that doesn't seem
> to be a neccessity anyway.

Currently in the Android userpace only trusted (system) apps can
directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
trusted system service (which ensures the app has been granted
permission to do this and tracks usage for accountability to
user/developer).

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Arve points out that qos constraint objects could work (but not if
>> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
>> he suggests that "latency" constraints don't represent this as well as
>> "state" constraints.
>
> With latency you have an "I don't give damn" latency in your model which
> we could describe as infinite or "manyana" perhaps.

I think Arve's concern was the representation of the "I care, but only
a little" or "just low enough to ensure threads must run" level which
is what suspend blockers would map to (low enough to ensure we
shouldn't halt the world but not necessarily implying a hard latency
constraint beyond that).

>> Though if you look at it that way, then suspend_blockers become qos
>> constraint objects, but their implementation and usage remain pretty
>> much the same as we have now, which does not address Alan's concern
>> regarding code turning up in drivers, etc.  I'm not sure how you can
>> solve this problem (avoiding races around entering/exiting the suspend
>> or suspend-like state) without having a means for drivers to prevent
>> entry to that state.
>
> I am much much less concerned about general expressions of constraint
> appearing in drivers. One of my early mails gave a list of other
> people/projects/problems that need them - from hard real time, to high
> speed serial on low end embedded to virtualisation.
>
> They fix a general problem in terms of a driver specific item. We end up
> making changes around the tree but we make everyone happy not just
> Android. Also we are isolating policy properly. The apps and drivers say
> "I have these needs", the power manager figures out how to meet them.

That makes sense -- and as I've mentioned elsewhere, we're really not
super picky about naming -- if it turns out that
wakelocks/suspendblockers were shorthand for "request a qos constraint
that ensures that threads are running", we'll be able to get things
done just as well as we do now.

> Where it gets ugly is if you start trying to have drivers giving an app a
> guarantee which the app then magically has to know to dispose of.

Yeah -- which is something we've avoided in the existing model with
overlapping wakelocks during handoff between domains.
- input service is select()ing on input devices
- when select() returns it grabs a wakelock, reads events, passes them
on, releases the wakelock
- the event subsystem can then safely drop its "should be running
threads" constraint as soon as the last event is read because it has
no queues for userspace to drain, but the overlapping wakelock
prevents the system from immediately snapping back to sleep

> If you are prepared to exclude untrusted apps from perfectly reliable
> event reporting (ie from finger to application action) that doesn't seem
> to be a neccessity anyway.

Currently in the Android userpace only trusted (system) apps can
directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
trusted system service (which ensures the app has been granted
permission to do this and tracks usage for accountability to
user/developer).

Brian
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Arve points out that qos constraint objects could work (but not if
>> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
>> he suggests that "latency" constraints don't represent this as well as
>> "state" constraints.
>
> With latency you have an "I don't give damn" latency in your model which
> we could describe as infinite or "manyana" perhaps.

I think Arve's concern was the representation of the "I care, but only
a little" or "just low enough to ensure threads must run" level which
is what suspend blockers would map to (low enough to ensure we
shouldn't halt the world but not necessarily implying a hard latency
constraint beyond that).

>> Though if you look at it that way, then suspend_blockers become qos
>> constraint objects, but their implementation and usage remain pretty
>> much the same as we have now, which does not address Alan's concern
>> regarding code turning up in drivers, etc.  I'm not sure how you can
>> solve this problem (avoiding races around entering/exiting the suspend
>> or suspend-like state) without having a means for drivers to prevent
>> entry to that state.
>
> I am much much less concerned about general expressions of constraint
> appearing in drivers. One of my early mails gave a list of other
> people/projects/problems that need them - from hard real time, to high
> speed serial on low end embedded to virtualisation.
>
> They fix a general problem in terms of a driver specific item. We end up
> making changes around the tree but we make everyone happy not just
> Android. Also we are isolating policy properly. The apps and drivers say
> "I have these needs", the power manager figures out how to meet them.

That makes sense -- and as I've mentioned elsewhere, we're really not
super picky about naming -- if it turns out that
wakelocks/suspendblockers were shorthand for "request a qos constraint
that ensures that threads are running", we'll be able to get things
done just as well as we do now.

> Where it gets ugly is if you start trying to have drivers giving an app a
> guarantee which the app then magically has to know to dispose of.

Yeah -- which is something we've avoided in the existing model with
overlapping wakelocks during handoff between domains.
- input service is select()ing on input devices
- when select() returns it grabs a wakelock, reads events, passes them
on, releases the wakelock
- the event subsystem can then safely drop its "should be running
threads" constraint as soon as the last event is read because it has
no queues for userspace to drain, but the overlapping wakelock
prevents the system from immediately snapping back to sleep

> If you are prepared to exclude untrusted apps from perfectly reliable
> event reporting (ie from finger to application action) that doesn't seem
> to be a neccessity anyway.

Currently in the Android userpace only trusted (system) apps can
directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
trusted system service (which ensures the app has been granted
permission to do this and tracks usage for accountability to
user/developer).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> It seems most of the problems the suspend-blockers are trying to solve
> are due to the fact of not running runnable tasks.

That is only partially correct.

If Android were using idle-time PM and not forced suspend, then yes -- 
not running runnable tasks would be a big problem.

But as it stands, with forced suspend the problem is to avoid delays in
processing wakeup events.  That's what suspend blockers are meant to
solve.  The same problem would occur with idle-time PM if you don't run
all runnable tasks, and it would need a similar solution.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> It seems most of the problems the suspend-blockers are trying to solve
> are due to the fact of not running runnable tasks.

That is only partially correct.

If Android were using idle-time PM and not forced suspend, then yes -- 
not running runnable tasks would be a big problem.

But as it stands, with forced suspend the problem is to avoid delays in
processing wakeup events.  That's what suspend blockers are meant to
solve.  The same problem would occur with idle-time PM if you don't run
all runnable tasks, and it would need a similar solution.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
>         The app is busy doing something else unimportant
>         We do into power save
>         Push a button, generate an IRQ
>         Come out of power save
>         No app to poke
>         * System goes back to sleep and eventually wakes up again
>         The app finishes what it was doing
>         The app sees there is a keystroke and marks itself important
>         ...
> 
> The * step is where trouble can occur. 

Only because you don't run runnable tasks. Please stop considering that
an option and these problems go away.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
>         The app is busy doing something else unimportant
>         We do into power save
>         Push a button, generate an IRQ
>         Come out of power save
>         No app to poke
>         * System goes back to sleep and eventually wakes up again
>         The app finishes what it was doing
>         The app sees there is a keystroke and marks itself important
>         ...
> 
> The * step is where trouble can occur. 

Only because you don't run runnable tasks. Please stop considering that
an option and these problems go away.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 15:02:37 +0100
> Ok, I think I've misunderstood you. You're actually saying that only 
> applications that are trusted to behave well are allowed to receive 
> wakeup events? Yes, that makes implementation significantly easier. If 

To receive them in a manner that they are permitted to defer a suspend.
There is non reason why bouncing cows shouldn't get to see an event, but
there is always the miniscule possibility that we choose to suspend as it
gets the event.

That to me seems fine. Our starting basis was

- Bouncing cows is not trusted

Android's reaction was

- We reserve the right to suspend bouncing cows where it likes it or not

The caveat becomes

- Bouncing cows may get suspended then get an event when the phone wakes
  back up. So I might press "Moo" just before a suspend and get the noise
  when it resumes.

Given the untrusted cows could respond to the event otherwise by blocking
the suspend for as long as permitted with a suspend blocker or similar
that seems no worse. In this case probably better [oof zap! as opposed to
60 seconds of 'event, no sorry got a cow to draw at 100% CPU')

As the app is untrusted we can't assume they would get suspend blockers
right even if they had any.

You can still be nice to the cows app and when the phone is put down send
it a 10 second warning via dbus or Android equivalents.

Your trusted call handling app can still request (by QoS or big hammers)
that the phone does not suspend even if the app goes idle (because you
have a wakeup latency QoS)

A naïve trusted app will behave according to power management idling to
suspend and get stopped

A naïve untrusted app that is doing sane things will spend most of its
life asleep and behave.

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Fri, 28 May 2010 15:02:37 +0100
> Ok, I think I've misunderstood you. You're actually saying that only 
> applications that are trusted to behave well are allowed to receive 
> wakeup events? Yes, that makes implementation significantly easier. If 

To receive them in a manner that they are permitted to defer a suspend.
There is non reason why bouncing cows shouldn't get to see an event, but
there is always the miniscule possibility that we choose to suspend as it
gets the event.

That to me seems fine. Our starting basis was

- Bouncing cows is not trusted

Android's reaction was

- We reserve the right to suspend bouncing cows where it likes it or not

The caveat becomes

- Bouncing cows may get suspended then get an event when the phone wakes
  back up. So I might press "Moo" just before a suspend and get the noise
  when it resumes.

Given the untrusted cows could respond to the event otherwise by blocking
the suspend for as long as permitted with a suspend blocker or similar
that seems no worse. In this case probably better [oof zap! as opposed to
60 seconds of 'event, no sorry got a cow to draw at 100% CPU')

As the app is untrusted we can't assume they would get suspend blockers
right even if they had any.

You can still be nice to the cows app and when the phone is put down send
it a 10 second warning via dbus or Android equivalents.

Your trusted call handling app can still request (by QoS or big hammers)
that the phone does not suspend even if the app goes idle (because you
have a wakeup latency QoS)

A naïve trusted app will behave according to power management idling to
suspend and get stopped

A naïve untrusted app that is doing sane things will spend most of its
life asleep and behave.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
> >         The app is busy doing something else unimportant
> >         We do into power save
> >         Push a button, generate an IRQ
> >         Come out of power save
> >         No app to poke
> >         * System goes back to sleep and eventually wakes up again
> >         The app finishes what it was doing
> >         The app sees there is a keystroke and marks itself important
> >         ...
> > 
> > The * step is where trouble can occur. 
> 
> Only because you don't run runnable tasks. Please stop considering that
> an option and these problems go away.

True.  If the untrusted apps can be segregated and forcibly stopped, 
and if they don't need timely delivery of wakeup events, then there's 
no problem.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
> >         The app is busy doing something else unimportant
> >         We do into power save
> >         Push a button, generate an IRQ
> >         Come out of power save
> >         No app to poke
> >         * System goes back to sleep and eventually wakes up again
> >         The app finishes what it was doing
> >         The app sees there is a keystroke and marks itself important
> >         ...
> > 
> > The * step is where trouble can occur. 
> 
> Only because you don't run runnable tasks. Please stop considering that
> an option and these problems go away.

True.  If the untrusted apps can be segregated and forcibly stopped, 
and if they don't need timely delivery of wakeup events, then there's 
no problem.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 16:59:54 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> So lets look at the problem, we want to be frugal with power, this means
> that the system as a whole should strive to do nothing. And we want to
> enforce this as strict as possible.

An interesting thought might be to add the costs of staying in
a state versus going to a lower power state into consideration. 

If the system is busy doing stuff it would need to do anyway (today
stuff that is guarded/annotated by the suspend blockers) , the costs for
not being in suspend have to be paid anyway. So it is opportune for
processes to run. Even if they by themselves would not justify the
system running. 

If instead nothing system-relevant has to be done, the costs of running
anything non-relevant is the full amount of battery-life that could
be saved by suspending + (some minor) running costs. 

Also if there is much work to do (many tasks) its more likely that it's
good to do the work.

something along the lines :

(amount of energy saved by being in suspend) / (number of tasks we
would run if we werent suspended) *
some_parameter_for_this_tasks_importance (which falls clearly into
scheduler-territory)

And if this goes above some threshold we run it.

But this isn't easily done in a robust way.
Also it complicates things. 

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Fri, 28 May 2010 16:59:54 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> So lets look at the problem, we want to be frugal with power, this means
> that the system as a whole should strive to do nothing. And we want to
> enforce this as strict as possible.

An interesting thought might be to add the costs of staying in
a state versus going to a lower power state into consideration. 

If the system is busy doing stuff it would need to do anyway (today
stuff that is guarded/annotated by the suspend blockers) , the costs for
not being in suspend have to be paid anyway. So it is opportune for
processes to run. Even if they by themselves would not justify the
system running. 

If instead nothing system-relevant has to be done, the costs of running
anything non-relevant is the full amount of battery-life that could
be saved by suspending + (some minor) running costs. 

Also if there is much work to do (many tasks) its more likely that it's
good to do the work.

something along the lines :

(amount of energy saved by being in suspend) / (number of tasks we
would run if we werent suspended) *
some_parameter_for_this_tasks_importance (which falls clearly into
scheduler-territory)

And if this goes above some threshold we run it.

But this isn't easily done in a robust way.
Also it complicates things. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think Arve's concern was the representation of the "I care, but only
> a little" or "just low enough to ensure threads must run" level which
> is what suspend blockers would map to (low enough to ensure we
> shouldn't halt the world but not necessarily implying a hard latency
> constraint beyond that).

That's why I suggested "manyana" (can't get accents for mañana in a
define) or perhaps "dreckly"[1]. They are both words that mean "at some
point" but in a very very vague and 'relax it'll happen eventually' sense.

More importantly it's policy. It's a please meet this constraint guide
to the PM layer - not a you must do as say even if its stupid.

> > They fix a general problem in terms of a driver specific item. We end up
> > making changes around the tree but we make everyone happy not just
> > Android. Also we are isolating policy properly. The apps and drivers say
> > "I have these needs", the power manager figures out how to meet them.
> 
> That makes sense -- and as I've mentioned elsewhere, we're really not
> super picky about naming -- if it turns out that
> wakelocks/suspendblockers were shorthand for "request a qos constraint
> that ensures that threads are running", we'll be able to get things
> done just as well as we do now.

Cool. I think they are or at least they are close enough that nobody will
notice the join ;)

> > Where it gets ugly is if you start trying to have drivers giving an app a
> > guarantee which the app then magically has to know to dispose of.
> 
> Yeah -- which is something we've avoided in the existing model with
> overlapping wakelocks during handoff between domains.

I'm not sure avoided is the right description - its there in all its
identical ugliness in wakelock magic

If you treat QoS guarantees as a wakelock for your purposes (which is
just fine, drivers and apps give you policy, you use it how you like)
then you could write the paragraph below substituting the word
'guarantee' for 'wakelock' So in that sense the mess is the same because
in both cases you are trying to suspend active tasks rather than asking
the task to behave and then taking remedial action with offenders.

> - input service is select()ing on input devices
> - when select() returns it grabs a wakelock, reads events, passes them
> on, releases the wakelock
> - the event subsystem can then safely drop its "should be running
> threads" constraint as soon as the last event is read because it has
> no queues for userspace to drain, but the overlapping wakelock
> prevents the system from immediately snapping back to sleep

The conventional PC model is 'we don't go back into sleep proper fast
enough for that race to occur'. It's hard to see how you change it. An
app->device "thank you for that event, I enjoyed it very much and have
finished with it" message moves the underlying event management and QoS
knowledge into he driver proper but doesn't really change the interface.

> > If you are prepared to exclude untrusted apps from perfectly reliable
> > event reporting (ie from finger to application action) that doesn't seem
> > to be a neccessity anyway.
> 
> Currently in the Android userpace only trusted (system) apps can
> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
> trusted system service (which ensures the app has been granted
> permission to do this and tracks usage for accountability to
> user/developer).

Clearly that would continue to work out.

Alan
[1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
without that dreadful sense of urgency'

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think Arve's concern was the representation of the "I care, but only
> a little" or "just low enough to ensure threads must run" level which
> is what suspend blockers would map to (low enough to ensure we
> shouldn't halt the world but not necessarily implying a hard latency
> constraint beyond that).

That's why I suggested "manyana" (can't get accents for mañana in a
define) or perhaps "dreckly"[1]. They are both words that mean "at some
point" but in a very very vague and 'relax it'll happen eventually' sense.

More importantly it's policy. It's a please meet this constraint guide
to the PM layer - not a you must do as say even if its stupid.

> > They fix a general problem in terms of a driver specific item. We end up
> > making changes around the tree but we make everyone happy not just
> > Android. Also we are isolating policy properly. The apps and drivers say
> > "I have these needs", the power manager figures out how to meet them.
> 
> That makes sense -- and as I've mentioned elsewhere, we're really not
> super picky about naming -- if it turns out that
> wakelocks/suspendblockers were shorthand for "request a qos constraint
> that ensures that threads are running", we'll be able to get things
> done just as well as we do now.

Cool. I think they are or at least they are close enough that nobody will
notice the join ;)

> > Where it gets ugly is if you start trying to have drivers giving an app a
> > guarantee which the app then magically has to know to dispose of.
> 
> Yeah -- which is something we've avoided in the existing model with
> overlapping wakelocks during handoff between domains.

I'm not sure avoided is the right description - its there in all its
identical ugliness in wakelock magic

If you treat QoS guarantees as a wakelock for your purposes (which is
just fine, drivers and apps give you policy, you use it how you like)
then you could write the paragraph below substituting the word
'guarantee' for 'wakelock' So in that sense the mess is the same because
in both cases you are trying to suspend active tasks rather than asking
the task to behave and then taking remedial action with offenders.

> - input service is select()ing on input devices
> - when select() returns it grabs a wakelock, reads events, passes them
> on, releases the wakelock
> - the event subsystem can then safely drop its "should be running
> threads" constraint as soon as the last event is read because it has
> no queues for userspace to drain, but the overlapping wakelock
> prevents the system from immediately snapping back to sleep

The conventional PC model is 'we don't go back into sleep proper fast
enough for that race to occur'. It's hard to see how you change it. An
app->device "thank you for that event, I enjoyed it very much and have
finished with it" message moves the underlying event management and QoS
knowledge into he driver proper but doesn't really change the interface.

> > If you are prepared to exclude untrusted apps from perfectly reliable
> > event reporting (ie from finger to application action) that doesn't seem
> > to be a neccessity anyway.
> 
> Currently in the Android userpace only trusted (system) apps can
> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
> trusted system service (which ensures the app has been granted
> permission to do this and tracks usage for accountability to
> user/developer).

Clearly that would continue to work out.

Alan
[1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
without that dreadful sense of urgency'

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I think Arve's concern was the representation of the "I care, but only
> a little" or "just low enough to ensure threads must run" level which
> is what suspend blockers would map to (low enough to ensure we
> shouldn't halt the world but not necessarily implying a hard latency
> constraint beyond that).

That's why I suggested "manyana" (can't get accents for mañana in a
define) or perhaps "dreckly"[1]. They are both words that mean "at some
point" but in a very very vague and 'relax it'll happen eventually' sense.

More importantly it's policy. It's a please meet this constraint guide
to the PM layer - not a you must do as say even if its stupid.

> > They fix a general problem in terms of a driver specific item. We end up
> > making changes around the tree but we make everyone happy not just
> > Android. Also we are isolating policy properly. The apps and drivers say
> > "I have these needs", the power manager figures out how to meet them.
> 
> That makes sense -- and as I've mentioned elsewhere, we're really not
> super picky about naming -- if it turns out that
> wakelocks/suspendblockers were shorthand for "request a qos constraint
> that ensures that threads are running", we'll be able to get things
> done just as well as we do now.

Cool. I think they are or at least they are close enough that nobody will
notice the join ;)

> > Where it gets ugly is if you start trying to have drivers giving an app a
> > guarantee which the app then magically has to know to dispose of.
> 
> Yeah -- which is something we've avoided in the existing model with
> overlapping wakelocks during handoff between domains.

I'm not sure avoided is the right description - its there in all its
identical ugliness in wakelock magic

If you treat QoS guarantees as a wakelock for your purposes (which is
just fine, drivers and apps give you policy, you use it how you like)
then you could write the paragraph below substituting the word
'guarantee' for 'wakelock' So in that sense the mess is the same because
in both cases you are trying to suspend active tasks rather than asking
the task to behave and then taking remedial action with offenders.

> - input service is select()ing on input devices
> - when select() returns it grabs a wakelock, reads events, passes them
> on, releases the wakelock
> - the event subsystem can then safely drop its "should be running
> threads" constraint as soon as the last event is read because it has
> no queues for userspace to drain, but the overlapping wakelock
> prevents the system from immediately snapping back to sleep

The conventional PC model is 'we don't go back into sleep proper fast
enough for that race to occur'. It's hard to see how you change it. An
app->device "thank you for that event, I enjoyed it very much and have
finished with it" message moves the underlying event management and QoS
knowledge into he driver proper but doesn't really change the interface.

> > If you are prepared to exclude untrusted apps from perfectly reliable
> > event reporting (ie from finger to application action) that doesn't seem
> > to be a neccessity anyway.
> 
> Currently in the Android userpace only trusted (system) apps can
> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
> trusted system service (which ensures the app has been granted
> permission to do this and tracks usage for accountability to
> user/developer).

Clearly that would continue to work out.

Alan
[1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
without that dreadful sense of urgency'

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > I think Arve's concern was the representation of the "I care, but only
> > a little" or "just low enough to ensure threads must run" level which
> > is what suspend blockers would map to (low enough to ensure we
> > shouldn't halt the world but not necessarily implying a hard latency
> > constraint beyond that).
> 
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.

A USA-style equivalent phrase might be "Real Soon Now".  Except that it 
conveys a strong implication that the event will never happen...

> > That makes sense -- and as I've mentioned elsewhere, we're really not
> > super picky about naming -- if it turns out that
> > wakelocks/suspendblockers were shorthand for "request a qos constraint
> > that ensures that threads are running", we'll be able to get things
> > done just as well as we do now.
> 
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)

Why are suspend blockers needed if you're going to put all untrusted 
apps in a cgroup and freeze/stop them?  Or is that not what you're 
planning to do?

ALan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > I think Arve's concern was the representation of the "I care, but only
> > a little" or "just low enough to ensure threads must run" level which
> > is what suspend blockers would map to (low enough to ensure we
> > shouldn't halt the world but not necessarily implying a hard latency
> > constraint beyond that).
> 
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.

A USA-style equivalent phrase might be "Real Soon Now".  Except that it 
conveys a strong implication that the event will never happen...

> > That makes sense -- and as I've mentioned elsewhere, we're really not
> > super picky about naming -- if it turns out that
> > wakelocks/suspendblockers were shorthand for "request a qos constraint
> > that ensures that threads are running", we'll be able to get things
> > done just as well as we do now.
> 
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)

Why are suspend blockers needed if you're going to put all untrusted 
apps in a cgroup and freeze/stop them?  Or is that not what you're 
planning to do?

ALan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > I think Arve's concern was the representation of the "I care, but only
> > a little" or "just low enough to ensure threads must run" level which
> > is what suspend blockers would map to (low enough to ensure we
> > shouldn't halt the world but not necessarily implying a hard latency
> > constraint beyond that).
> 
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.

A USA-style equivalent phrase might be "Real Soon Now".  Except that it 
conveys a strong implication that the event will never happen...

> > That makes sense -- and as I've mentioned elsewhere, we're really not
> > super picky about naming -- if it turns out that
> > wakelocks/suspendblockers were shorthand for "request a qos constraint
> > that ensures that threads are running", we'll be able to get things
> > done just as well as we do now.
> 
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)

Why are suspend blockers needed if you're going to put all untrusted 
apps in a cgroup and freeze/stop them?  Or is that not what you're 
planning to do?

ALan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Bernd Petrovitsch]

On Fre, 2010-05-28 at 12:45 +0100, Matthew Garrett wrote:
> On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
> > On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> > > At the point where you're rewriting the application you can just make it 
> > > adhere to our current behavioural standards anyway.
> > 
> > Thank you for confirming that the so-called "feature" is just there to
> > make apps work in some area that are crappy anyways - and God knows in
> > which other areas they are crappy too.
> 
> Kind of like memory protection, really. Or preemptive multitasking. Or 
> many things that the kernel does to prevent badly written applications 
> from interfering with other applications or the user's experience.

With the main difference that their semantics and API is defined by the
lower layer so that the lower layer can make useful - for the
multitasking part - scheduling decisions.
There were other forms of multitasking before preemptive multitasking -
coroutines (e.g. in Win-3.x quite late in IT history) and the like.
So why not simply skip one step in evolution and go more directly to a
useful solution?

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [PATCH 0/8] Suspend block api (version 8)

[Bernd Petrovitsch]

On Fre, 2010-05-28 at 12:45 +0100, Matthew Garrett wrote:
> On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
> > On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> > > At the point where you're rewriting the application you can just make it 
> > > adhere to our current behavioural standards anyway.
> > 
> > Thank you for confirming that the so-called "feature" is just there to
> > make apps work in some area that are crappy anyways - and God knows in
> > which other areas they are crappy too.
> 
> Kind of like memory protection, really. Or preemptive multitasking. Or 
> many things that the kernel does to prevent badly written applications 
> from interfering with other applications or the user's experience.

With the main difference that their semantics and API is defined by the
lower layer so that the lower layer can make useful - for the
multitasking part - scheduling decisions.
There were other forms of multitasking before preemptive multitasking -
coroutines (e.g. in Win-3.x quite late in IT history) and the like.
So why not simply skip one step in evolution and go more directly to a
useful solution?

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Fri, May 28, 2010 at 08:13:08AM -0700, Brian Swetland wrote:
> On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > They fix a general problem in terms of a driver specific item. We end up
> > making changes around the tree but we make everyone happy not just
> > Android. Also we are isolating policy properly. The apps and drivers say
> > "I have these needs", the power manager figures out how to meet them.
> 
> That makes sense -- and as I've mentioned elsewhere, we're really not
> super picky about naming -- if it turns out that
> wakelocks/suspendblockers were shorthand for "request a qos constraint
> that ensures that threads are running", we'll be able to get things
> done just as well as we do now.

>From my reading of this thread, there's a lot of overlap between
suspendblockers and constraints.  Many use cases are served equally
well with one or the other, except for one:  a case where an event that
should ultimately wake the system triggers a code execution path (or data
flow path) that wanders through a user-space full of complex interacting
processes where the kernel (and maybe even the processes) can't see it.

Suspend-blockers in user-space handle this by making such code/data paths
visible to the kernel.  An all-kernel constraint-based approach has no
way to see the user-space paths, so the system will end up trying to
sleep when it should be waking up.

Wait, what?  Surely all the user-space code handling such events is
running under a PM-QoS constraint that says "don't sleep if this process
is runnable," so the system won't go to sleep.  Presumably all other
processes which don't handle wakeup events will be running under a
PM-QoS constraint that says "do sleep even if this process is runnable."

That's true, except for one common case:  a process is drawing things on
the display on behalf of other processes, and that drawing process can't
have the "don't sleep" constraint because if it did the system would
seem to be continuously busy and never go to sleep.  Any process that is
handling a critical event but also needs to talk to the display process
will end up being not-runnable, and the system may go to sleep before the
display process wakes up.  So we need another PM-QoS constraint that says
"don't sleep even if this process isn't runnable, because some *other*
runnable process might do something that makes our critical process
runnable again."  The critical event handling app would switch to this
PM-QoS constraint until it had received an ack from whatever it talked
to in user-space, then switch back to the "don't sleep if this process
is runnable" state until a new event comes in.

So, three constraint policies should do it (*):

	1.  Do sleep even if this process is runnable,

	2.  Don't sleep if this process is runnable, and

	3.  Don't sleep even if this process isn't runnable, as long as
	at least one other runnable process exists somewhere on the
	system.

"Runnable" would include tasks that are literally runnable as well as
tasks that aren't runnable but are presumed to be imminently runnable
(e.g. blocked on timers that are going to expire before the wakeup
latency).

"Sleep" means going into any state where the scheduler doesn't run
any tasks.  That covers most CPU idle modes, deep power saving states,
ACPI suspend, or whatever.

(*) or you could define a "please stop wasting CPU" message in user-space,
and send that message to anything in user-space which has a PM-QoS
constraint better than "none" whenever something in user-space thinks
the user has gone away.  Then the display process can have constraint #2,
and we don't need #3.

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Fri, May 28, 2010 at 08:13:08AM -0700, Brian Swetland wrote:
> On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > They fix a general problem in terms of a driver specific item. We end up
> > making changes around the tree but we make everyone happy not just
> > Android. Also we are isolating policy properly. The apps and drivers say
> > "I have these needs", the power manager figures out how to meet them.
> 
> That makes sense -- and as I've mentioned elsewhere, we're really not
> super picky about naming -- if it turns out that
> wakelocks/suspendblockers were shorthand for "request a qos constraint
> that ensures that threads are running", we'll be able to get things
> done just as well as we do now.

>From my reading of this thread, there's a lot of overlap between
suspendblockers and constraints.  Many use cases are served equally
well with one or the other, except for one:  a case where an event that
should ultimately wake the system triggers a code execution path (or data
flow path) that wanders through a user-space full of complex interacting
processes where the kernel (and maybe even the processes) can't see it.

Suspend-blockers in user-space handle this by making such code/data paths
visible to the kernel.  An all-kernel constraint-based approach has no
way to see the user-space paths, so the system will end up trying to
sleep when it should be waking up.

Wait, what?  Surely all the user-space code handling such events is
running under a PM-QoS constraint that says "don't sleep if this process
is runnable," so the system won't go to sleep.  Presumably all other
processes which don't handle wakeup events will be running under a
PM-QoS constraint that says "do sleep even if this process is runnable."

That's true, except for one common case:  a process is drawing things on
the display on behalf of other processes, and that drawing process can't
have the "don't sleep" constraint because if it did the system would
seem to be continuously busy and never go to sleep.  Any process that is
handling a critical event but also needs to talk to the display process
will end up being not-runnable, and the system may go to sleep before the
display process wakes up.  So we need another PM-QoS constraint that says
"don't sleep even if this process isn't runnable, because some *other*
runnable process might do something that makes our critical process
runnable again."  The critical event handling app would switch to this
PM-QoS constraint until it had received an ack from whatever it talked
to in user-space, then switch back to the "don't sleep if this process
is runnable" state until a new event comes in.

So, three constraint policies should do it (*):

	1.  Do sleep even if this process is runnable,

	2.  Don't sleep if this process is runnable, and

	3.  Don't sleep even if this process isn't runnable, as long as
	at least one other runnable process exists somewhere on the
	system.

"Runnable" would include tasks that are literally runnable as well as
tasks that aren't runnable but are presumed to be imminently runnable
(e.g. blocked on timers that are going to expire before the wakeup
latency).

"Sleep" means going into any state where the scheduler doesn't run
any tasks.  That covers most CPU idle modes, deep power saving states,
ACPI suspend, or whatever.

(*) or you could define a "please stop wasting CPU" message in user-space,
and send that message to anything in user-space which has a PM-QoS
constraint better than "none" whenever something in user-space thinks
the user has gone away.  Then the display process can have constraint #2,
and we don't need #3.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
> From my reading of this thread, there's a lot of overlap between
> suspendblockers and constraints.  Many use cases are served equally
> well with one or the other, 

If using suspend-blockers, 

Please explain to me how:

- I will avoid the cpu going into some idle state for which the wakeup
latency is larger than my RT app fancies?

- to avoid some tasks from being serviced by the filesystems whilst
others are? (ionice on steroids).

- does my sporadic task (with strict bandwidth budget) not suffer
bandwidth inversion?


suspend blockers do a bit of each of that, but none of it in a usable
fashion.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
> From my reading of this thread, there's a lot of overlap between
> suspendblockers and constraints.  Many use cases are served equally
> well with one or the other, 

If using suspend-blockers, 

Please explain to me how:

- I will avoid the cpu going into some idle state for which the wakeup
latency is larger than my RT app fancies?

- to avoid some tasks from being serviced by the filesystems whilst
others are? (ionice on steroids).

- does my sporadic task (with strict bandwidth budget) not suffer
bandwidth inversion?


suspend blockers do a bit of each of that, but none of it in a usable
fashion.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Fri, May 28, 2010 at 08:16:20PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
> > From my reading of this thread, there's a lot of overlap between
> > suspendblockers and constraints.  Many use cases are served equally
> > well with one or the other, 

Oops, I apparently meant "many use cases *of suspendblockers* are served
equally well with one or the other."

> If using suspend-blockers, 
> Please explain to me how:
> - I will avoid the cpu going into some idle state for which the wakeup
> latency is larger than my RT app fancies?

...though I'd think you could do that by holding a suspendblocker, thus
preventing the CPU from going into any idle state at all.

There's four likely outcomes, corresponding to inclusion or non-inclusion
of suspend blockers and PM constraints in the kernel.  Both could coexist
in the same kernel, since a suspend blocker can be trivially expressed as
"an extreme PM constraint with other non-constraint-related semantics."

It's the "other non-constraint-related semantics" that seem to be the
contentious issue.  What can a suspend blocker do that a PM resource
constraint cannot do?  If that set contains at least one useful use case,
then we need either suspend blockers, or some other thing that provides
for the use case.

Lots of people want PM constraints, and I haven't seen anyone suggest
there should *not* be PM constraints in the kernel some day.  I've seen
a few "working and useful PM constraints aren't going to happen any time
soon" statements, and several "there's lots of stuff you still can't do
with PM constraints or suspend blockers" statements, but those aren't
arguments *against* PM constraints or *for* suspend blockers.

Re: [PATCH 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Fri, May 28, 2010 at 08:16:20PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
> > From my reading of this thread, there's a lot of overlap between
> > suspendblockers and constraints.  Many use cases are served equally
> > well with one or the other, 

Oops, I apparently meant "many use cases *of suspendblockers* are served
equally well with one or the other."

> If using suspend-blockers, 
> Please explain to me how:
> - I will avoid the cpu going into some idle state for which the wakeup
> latency is larger than my RT app fancies?

...though I'd think you could do that by holding a suspendblocker, thus
preventing the CPU from going into any idle state at all.

There's four likely outcomes, corresponding to inclusion or non-inclusion
of suspend blockers and PM constraints in the kernel.  Both could coexist
in the same kernel, since a suspend blocker can be trivially expressed as
"an extreme PM constraint with other non-constraint-related semantics."

It's the "other non-constraint-related semantics" that seem to be the
contentious issue.  What can a suspend blocker do that a PM resource
constraint cannot do?  If that set contains at least one useful use case,
then we need either suspend blockers, or some other thing that provides
for the use case.

Lots of people want PM constraints, and I haven't seen anyone suggest
there should *not* be PM constraints in the kernel some day.  I've seen
a few "working and useful PM constraints aren't going to happen any time
soon" statements, and several "there's lots of stuff you still can't do
with PM constraints or suspend blockers" statements, but those aren't
arguments *against* PM constraints or *for* suspend blockers.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote:
> > On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> > > On Fri, 28 May 2010 14:30:36 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > > > [Total kernel changes
> > > > > 
> > > > >         Ability to mark/unmark a scheduler control group as outside of
> > > > >         some parts of idle consideration. Generically useful and
> > > > >         localised. Group latency will do most jobs fine (Zygo is correct
> > > > >         it can't solve his backup case elegantly I think)
> > > > > 
> > > > >         Test in the idling logic to distinguish the case and only needed
> > > > >         for a single Android specific power module. Generically useful
> > > > >         and localised] 
> > > > 
> > > > I really don't like this..
> > > > 
> > > > Why can't we go with the previously suggested: make bad apps block on
> > > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> > > 
> > > Ok. Are you happy with the QoS being attached to a scheduler control
> > > group and the use of them to figure out what is what ?
> > 
> > Up to a point, but explicitly not running runnable tasks complicates the
> > task model significantly, and interacts with fun stuff like bandwidth
> > inheritance and priority/deadline inheritance like things -- a subject
> > you really don't want to complicate further.
> > 
> > We really want to do our utmost best to make applications block on
> > something without altering our task model.
> > 
> > If applications keep running despite being told repeatedly to cease, I
> > think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
> > SIGTERM before that) and got ample opportunity to block on something.
> > 
> > Traditional cpu resource management treats the CPU as an ever
> > replenished resource, breaking that assumption (not running runnable
> > tasks) puts us on very shaky ground indeed.
> 
> Also, I'm not quite sure why we would need cgroups to pull this off.
> 
> It seems most of the problems the suspend-blockers are trying to solve
> are due to the fact of not running runnable tasks. Not running runnable
> tasks can be seen as assigning tasks 0 bandwidth. Which is a situation
> extremely prone to all things inversion. Such a situation would require
> bandwidth inheritance to function at all, so possibly we can see
> suspend-blockers as a misguided implementation of that.

I think this is a matter of what is regarded as a "runnable task".  Some
tasks may not even be regarded as runnable in specific power conditions,
although otherwise they would be.

Consider updatedb or another file indexing ... thing on a laptop.  I certainly
don't want anything like this to run and drain my battery, even if it has
already been started when the machine was on AC power.  Now, of course,
I can kill it, but for that I need to notice that it's running and it presumably
might have done some job already and it would be wasteful to lose it.
It would be quite nice if that app was not regarded as runnable when the
system was on battery power.

In my view that's quite analogous to the Android situation, when they simply
don't want some tasks to be regarded as runnable in specific situations.

Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote:
> > On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
> > > On Fri, 28 May 2010 14:30:36 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
> > > > > [Total kernel changes
> > > > > 
> > > > >         Ability to mark/unmark a scheduler control group as outside of
> > > > >         some parts of idle consideration. Generically useful and
> > > > >         localised. Group latency will do most jobs fine (Zygo is correct
> > > > >         it can't solve his backup case elegantly I think)
> > > > > 
> > > > >         Test in the idling logic to distinguish the case and only needed
> > > > >         for a single Android specific power module. Generically useful
> > > > >         and localised] 
> > > > 
> > > > I really don't like this..
> > > > 
> > > > Why can't we go with the previously suggested: make bad apps block on
> > > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL
> > > 
> > > Ok. Are you happy with the QoS being attached to a scheduler control
> > > group and the use of them to figure out what is what ?
> > 
> > Up to a point, but explicitly not running runnable tasks complicates the
> > task model significantly, and interacts with fun stuff like bandwidth
> > inheritance and priority/deadline inheritance like things -- a subject
> > you really don't want to complicate further.
> > 
> > We really want to do our utmost best to make applications block on
> > something without altering our task model.
> > 
> > If applications keep running despite being told repeatedly to cease, I
> > think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and
> > SIGTERM before that) and got ample opportunity to block on something.
> > 
> > Traditional cpu resource management treats the CPU as an ever
> > replenished resource, breaking that assumption (not running runnable
> > tasks) puts us on very shaky ground indeed.
> 
> Also, I'm not quite sure why we would need cgroups to pull this off.
> 
> It seems most of the problems the suspend-blockers are trying to solve
> are due to the fact of not running runnable tasks. Not running runnable
> tasks can be seen as assigning tasks 0 bandwidth. Which is a situation
> extremely prone to all things inversion. Such a situation would require
> bandwidth inheritance to function at all, so possibly we can see
> suspend-blockers as a misguided implementation of that.

I think this is a matter of what is regarded as a "runnable task".  Some
tasks may not even be regarded as runnable in specific power conditions,
although otherwise they would be.

Consider updatedb or another file indexing ... thing on a laptop.  I certainly
don't want anything like this to run and drain my battery, even if it has
already been started when the machine was on AC power.  Now, of course,
I can kill it, but for that I need to notice that it's running and it presumably
might have done some job already and it would be wasteful to lose it.
It would be quite nice if that app was not regarded as runnable when the
system was on battery power.

In my view that's quite analogous to the Android situation, when they simply
don't want some tasks to be regarded as runnable in specific situations.

Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 9:31 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I think Arve's concern was the representation of the "I care, but only
>> a little" or "just low enough to ensure threads must run" level which
>> is what suspend blockers would map to (low enough to ensure we
>> shouldn't halt the world but not necessarily implying a hard latency
>> constraint beyond that).
>
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.
>
> More importantly it's policy. It's a please meet this constraint guide
> to the PM layer - not a you must do as say even if its stupid.

Huh?

>
>> > They fix a general problem in terms of a driver specific item. We end up
>> > making changes around the tree but we make everyone happy not just
>> > Android. Also we are isolating policy properly. The apps and drivers say
>> > "I have these needs", the power manager figures out how to meet them.
>>
>> That makes sense -- and as I've mentioned elsewhere, we're really not
>> super picky about naming -- if it turns out that
>> wakelocks/suspendblockers were shorthand for "request a qos constraint
>> that ensures that threads are running", we'll be able to get things
>> done just as well as we do now.
>
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)
>
>> > Where it gets ugly is if you start trying to have drivers giving an app a
>> > guarantee which the app then magically has to know to dispose of.
>>
>> Yeah -- which is something we've avoided in the existing model with
>> overlapping wakelocks during handoff between domains.
>
> I'm not sure avoided is the right description - its there in all its
> identical ugliness in wakelock magic
>
> If you treat QoS guarantees as a wakelock for your purposes (which is
> just fine, drivers and apps give you policy, you use it how you like)
> then you could write the paragraph below substituting the word
> 'guarantee' for 'wakelock' So in that sense the mess is the same because
> in both cases you are trying to suspend active tasks rather than asking
> the task to behave and then taking remedial action with offenders.
>
>> - input service is select()ing on input devices
>> - when select() returns it grabs a wakelock, reads events, passes them
>> on, releases the wakelock
>> - the event subsystem can then safely drop its "should be running
>> threads" constraint as soon as the last event is read because it has
>> no queues for userspace to drain, but the overlapping wakelock
>> prevents the system from immediately snapping back to sleep
>
> The conventional PC model is 'we don't go back into sleep proper fast
> enough for that race to occur'.

This is the same as saying these two threads don't run often enough to
need a mutex around their critical section. Just because you have not
been bitten by the race yet, does not mean it does not exist.

> It's hard to see how you change it. An

If each layer prevents suspend while it knows there are pending events
you don't have a race. Suspend blockers lets you do this.

> app->device "thank you for that event, I enjoyed it very much and have
> finished with it" message moves the underlying event management and QoS
> knowledge into he driver proper but doesn't really change the interface.
>
Yes you can do this, and it it how the android alarm driver works, but
we found the select()/poll(), block suspend, read event, process event
then unblock suspend sequence cleaner (especially for interfaces that
can return more than one event at a time). Kernel suspend blocker lets
you implement the alarm driver model, adding user-space suspend
blockers lets you implement the second.

>> > If you are prepared to exclude untrusted apps from perfectly reliable
>> > event reporting (ie from finger to application action) that doesn't seem
>> > to be a neccessity anyway.
>>
>> Currently in the Android userpace only trusted (system) apps can
>> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
>> trusted system service (which ensures the app has been granted
>> permission to do this and tracks usage for accountability to
>> user/developer).
>
> Clearly that would continue to work out.
>
> Alan
> [1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
> without that dreadful sense of urgency'
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 9:31 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I think Arve's concern was the representation of the "I care, but only
>> a little" or "just low enough to ensure threads must run" level which
>> is what suspend blockers would map to (low enough to ensure we
>> shouldn't halt the world but not necessarily implying a hard latency
>> constraint beyond that).
>
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.
>
> More importantly it's policy. It's a please meet this constraint guide
> to the PM layer - not a you must do as say even if its stupid.

Huh?

>
>> > They fix a general problem in terms of a driver specific item. We end up
>> > making changes around the tree but we make everyone happy not just
>> > Android. Also we are isolating policy properly. The apps and drivers say
>> > "I have these needs", the power manager figures out how to meet them.
>>
>> That makes sense -- and as I've mentioned elsewhere, we're really not
>> super picky about naming -- if it turns out that
>> wakelocks/suspendblockers were shorthand for "request a qos constraint
>> that ensures that threads are running", we'll be able to get things
>> done just as well as we do now.
>
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)
>
>> > Where it gets ugly is if you start trying to have drivers giving an app a
>> > guarantee which the app then magically has to know to dispose of.
>>
>> Yeah -- which is something we've avoided in the existing model with
>> overlapping wakelocks during handoff between domains.
>
> I'm not sure avoided is the right description - its there in all its
> identical ugliness in wakelock magic
>
> If you treat QoS guarantees as a wakelock for your purposes (which is
> just fine, drivers and apps give you policy, you use it how you like)
> then you could write the paragraph below substituting the word
> 'guarantee' for 'wakelock' So in that sense the mess is the same because
> in both cases you are trying to suspend active tasks rather than asking
> the task to behave and then taking remedial action with offenders.
>
>> - input service is select()ing on input devices
>> - when select() returns it grabs a wakelock, reads events, passes them
>> on, releases the wakelock
>> - the event subsystem can then safely drop its "should be running
>> threads" constraint as soon as the last event is read because it has
>> no queues for userspace to drain, but the overlapping wakelock
>> prevents the system from immediately snapping back to sleep
>
> The conventional PC model is 'we don't go back into sleep proper fast
> enough for that race to occur'.

This is the same as saying these two threads don't run often enough to
need a mutex around their critical section. Just because you have not
been bitten by the race yet, does not mean it does not exist.

> It's hard to see how you change it. An

If each layer prevents suspend while it knows there are pending events
you don't have a race. Suspend blockers lets you do this.

> app->device "thank you for that event, I enjoyed it very much and have
> finished with it" message moves the underlying event management and QoS
> knowledge into he driver proper but doesn't really change the interface.
>
Yes you can do this, and it it how the android alarm driver works, but
we found the select()/poll(), block suspend, read event, process event
then unblock suspend sequence cleaner (especially for interfaces that
can return more than one event at a time). Kernel suspend blocker lets
you implement the alarm driver model, adding user-space suspend
blockers lets you implement the second.

>> > If you are prepared to exclude untrusted apps from perfectly reliable
>> > event reporting (ie from finger to application action) that doesn't seem
>> > to be a neccessity anyway.
>>
>> Currently in the Android userpace only trusted (system) apps can
>> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
>> trusted system service (which ensures the app has been granted
>> permission to do this and tracks usage for accountability to
>> user/developer).
>
> Clearly that would continue to work out.
>
> Alan
> [1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
> without that dreadful sense of urgency'
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 9:31 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I think Arve's concern was the representation of the "I care, but only
>> a little" or "just low enough to ensure threads must run" level which
>> is what suspend blockers would map to (low enough to ensure we
>> shouldn't halt the world but not necessarily implying a hard latency
>> constraint beyond that).
>
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.
>
> More importantly it's policy. It's a please meet this constraint guide
> to the PM layer - not a you must do as say even if its stupid.

Huh?

>
>> > They fix a general problem in terms of a driver specific item. We end up
>> > making changes around the tree but we make everyone happy not just
>> > Android. Also we are isolating policy properly. The apps and drivers say
>> > "I have these needs", the power manager figures out how to meet them.
>>
>> That makes sense -- and as I've mentioned elsewhere, we're really not
>> super picky about naming -- if it turns out that
>> wakelocks/suspendblockers were shorthand for "request a qos constraint
>> that ensures that threads are running", we'll be able to get things
>> done just as well as we do now.
>
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)
>
>> > Where it gets ugly is if you start trying to have drivers giving an app a
>> > guarantee which the app then magically has to know to dispose of.
>>
>> Yeah -- which is something we've avoided in the existing model with
>> overlapping wakelocks during handoff between domains.
>
> I'm not sure avoided is the right description - its there in all its
> identical ugliness in wakelock magic
>
> If you treat QoS guarantees as a wakelock for your purposes (which is
> just fine, drivers and apps give you policy, you use it how you like)
> then you could write the paragraph below substituting the word
> 'guarantee' for 'wakelock' So in that sense the mess is the same because
> in both cases you are trying to suspend active tasks rather than asking
> the task to behave and then taking remedial action with offenders.
>
>> - input service is select()ing on input devices
>> - when select() returns it grabs a wakelock, reads events, passes them
>> on, releases the wakelock
>> - the event subsystem can then safely drop its "should be running
>> threads" constraint as soon as the last event is read because it has
>> no queues for userspace to drain, but the overlapping wakelock
>> prevents the system from immediately snapping back to sleep
>
> The conventional PC model is 'we don't go back into sleep proper fast
> enough for that race to occur'.

This is the same as saying these two threads don't run often enough to
need a mutex around their critical section. Just because you have not
been bitten by the race yet, does not mean it does not exist.

> It's hard to see how you change it. An

If each layer prevents suspend while it knows there are pending events
you don't have a race. Suspend blockers lets you do this.

> app->device "thank you for that event, I enjoyed it very much and have
> finished with it" message moves the underlying event management and QoS
> knowledge into he driver proper but doesn't really change the interface.
>
Yes you can do this, and it it how the android alarm driver works, but
we found the select()/poll(), block suspend, read event, process event
then unblock suspend sequence cleaner (especially for interfaces that
can return more than one event at a time). Kernel suspend blocker lets
you implement the alarm driver model, adding user-space suspend
blockers lets you implement the second.

>> > If you are prepared to exclude untrusted apps from perfectly reliable
>> > event reporting (ie from finger to application action) that doesn't seem
>> > to be a neccessity anyway.
>>
>> Currently in the Android userpace only trusted (system) apps can
>> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
>> trusted system service (which ensures the app has been granted
>> permission to do this and tracks usage for accountability to
>> user/developer).
>
> Clearly that would continue to work out.
>
> Alan
> [1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
> without that dreadful sense of urgency'
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
> > What happens if the user presses the button right before you set QoS
> > of 'user apps' to  QS_NONE?
> > To me it looks like this solution would result in this sequence which
> > may ignore the button press:
> >         Button pushed
> >         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> >         Set QoS of 'user apps' to QS_NONE 
> 
> I don't think we should change app QoS parameters, but change service
> provider parameters.
> 
> For instance, suppose the filesystem-IO QoS has 3 levels: 
>   High, Normal and Idle.
> 
> Then if we assign Idle to updatedb, we'll service it as long as the
> filesystem-server QoS has a higher level (High and Normal). When we
> change the filesystem-serves' QoS to idle, it finds there is nothing to
> keep it servicing stuff and it'll block pending requests, updatedb stops
> being runnable and we're good.

Yeah, that's what I was thinking.  It would be nice to have a mechanism that
would prevent tasks from being runnable in specific conditions (not necessarily
related to power management even).

Having reconsidered the suspend blockers idea I came to the conclusion that
in fact it was a workaround for three different problems.

The first one was that we couldn't power manage I/O devices at run time and
the only way to put them into low-power states was to carry out full system
suspend.  That's changed with the introduction of the runtime PM framework,
but the situation is still not ideal, because in general there's no connection
between the idle infrastructure and runtime PM.

This IMO is the second problem worked around by suspend blockers.
Namely, it generally would be nice to suspend I/O devices when CPUs are idle
for a sufficiently long time.  For this to work, there should be a way to
register a device with the idle framework so that it can tell the device's
driver to suspend the device when it makes sense.  Something like
<vague idea>idle_register_device(dev, t), where t means "suspend that
device after all CPUs have been idle for time t", so basically the idle
framework will only need to run pm_schedule_suspend(dev, t) for that device
right before idling the last CPU</vague idea>.

The third problem is exactly that on Android system there are (or at least
there may be) tasks that in specific situations should not be regarded as
runnable at all and currently there's no way to ensure they won't run other
than going to a full suspend.

If we could address these issues somehow, I think suspend blockers would not be
necessary for maximizing battery life (well, there are some technical details
like automatic going to full suspend when the CPUs and I/O have  been idle for
sufficiently long etc., but they all seem to be tractable).

[And there's a problem of periodic timers that trigger too often, but I think
that's just a general issue that need to be fixed anyway.]

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
> > What happens if the user presses the button right before you set QoS
> > of 'user apps' to  QS_NONE?
> > To me it looks like this solution would result in this sequence which
> > may ignore the button press:
> >         Button pushed
> >         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> >         Set QoS of 'user apps' to QS_NONE 
> 
> I don't think we should change app QoS parameters, but change service
> provider parameters.
> 
> For instance, suppose the filesystem-IO QoS has 3 levels: 
>   High, Normal and Idle.
> 
> Then if we assign Idle to updatedb, we'll service it as long as the
> filesystem-server QoS has a higher level (High and Normal). When we
> change the filesystem-serves' QoS to idle, it finds there is nothing to
> keep it servicing stuff and it'll block pending requests, updatedb stops
> being runnable and we're good.

Yeah, that's what I was thinking.  It would be nice to have a mechanism that
would prevent tasks from being runnable in specific conditions (not necessarily
related to power management even).

Having reconsidered the suspend blockers idea I came to the conclusion that
in fact it was a workaround for three different problems.

The first one was that we couldn't power manage I/O devices at run time and
the only way to put them into low-power states was to carry out full system
suspend.  That's changed with the introduction of the runtime PM framework,
but the situation is still not ideal, because in general there's no connection
between the idle infrastructure and runtime PM.

This IMO is the second problem worked around by suspend blockers.
Namely, it generally would be nice to suspend I/O devices when CPUs are idle
for a sufficiently long time.  For this to work, there should be a way to
register a device with the idle framework so that it can tell the device's
driver to suspend the device when it makes sense.  Something like
<vague idea>idle_register_device(dev, t), where t means "suspend that
device after all CPUs have been idle for time t", so basically the idle
framework will only need to run pm_schedule_suspend(dev, t) for that device
right before idling the last CPU</vague idea>.

The third problem is exactly that on Android system there are (or at least
there may be) tasks that in specific situations should not be regarded as
runnable at all and currently there's no way to ensure they won't run other
than going to a full suspend.

If we could address these issues somehow, I think suspend blockers would not be
necessary for maximizing battery life (well, there are some technical details
like automatic going to full suspend when the CPUs and I/O have  been idle for
sufficiently long etc., but they all seem to be tractable).

[And there's a problem of periodic timers that trigger too often, but I think
that's just a general issue that need to be fixed anyway.]

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> > Today "idle" means "no task running"
> > 
> > If you are prepared to rephrase that as "no task that matters is running"
> > what would need to answer ?
> 
> I'm not sure we need or want to go there.
> 
> Why not simply let upatedb block on its IO because its QoS policy tells
> us that its IO priority is idle. Therefore it will not avoid the IO
> device from going idle and indefinitely delaying servicing requests.
> 
> When updatedb blocks, the runqueue becomes empty and we gain goodness.
> 
> Or are we talking about the same thing?

There may be apps that don't actually do I/O that we may want to be treated
that way too.

Consider the following scenario.  I have a purely computational task that's
running on my laptop in the background (say it's a folding@home or something
similar), but I only want it to run when (a) the box is on AC power and (b)
when user interface is "active" (the latter would have to be defined precisely,
but for the purpose of this thought experiment let's assume we have such a
definition).  Then, I'd only like it to be regarded as runnable if (a) and (b)
both happen at the same time, but it can't block on I/O.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> > Today "idle" means "no task running"
> > 
> > If you are prepared to rephrase that as "no task that matters is running"
> > what would need to answer ?
> 
> I'm not sure we need or want to go there.
> 
> Why not simply let upatedb block on its IO because its QoS policy tells
> us that its IO priority is idle. Therefore it will not avoid the IO
> device from going idle and indefinitely delaying servicing requests.
> 
> When updatedb blocks, the runqueue becomes empty and we gain goodness.
> 
> Or are we talking about the same thing?

There may be apps that don't actually do I/O that we may want to be treated
that way too.

Consider the following scenario.  I have a purely computational task that's
running on my laptop in the background (say it's a folding@home or something
similar), but I only want it to run when (a) the box is on AC power and (b)
when user interface is "active" (the latter would have to be defined precisely,
but for the purpose of this thought experiment let's assume we have such a
definition).  Then, I'd only like it to be regarded as runnable if (a) and (b)
both happen at the same time, but it can't block on I/O.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
...
> > To integrate this with the current way of doing things, i gathered it
> > needs to be implemented as an idle-state that does the suspend()-call?
> >
> 
> I think it is better no not confuse this with idle. Since initiating
> suspend will cause the system to become not-idle, I don't think is is
> beneficial to initiate suspend from idle.

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy
    savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time
    such that it's worth suspending.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Friday 28 May 2010, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
...
> > To integrate this with the current way of doing things, i gathered it
> > needs to be implemented as an idle-state that does the suspend()-call?
> >
> 
> I think it is better no not confuse this with idle. Since initiating
> suspend will cause the system to become not-idle, I don't think is is
> beneficial to initiate suspend from idle.

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy
    savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time
    such that it's worth suspending.

Thanks,
Rafael

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Brian Swetland wrote:
>> How is it flawed?  Serious question.
>
> I would avoid repeating all the good arguments given so far, but to make it
> short:
>
> * I believe runtime PM is a much better starting point (at least for the
> type of HW targeted at mobile devices) because it mimics an always-on system
> toward userspace, which requires less disruption in the way apps are
> designed

I agree.

If I understand correctly, if we have a perfect user-space that only
does work when strictly needed and trying to do it in bursts, then we
would be reaching the lowest power state, and there would be no need
for suspend. The problem is that Android's user-space is pretty far
from that, so they said "let's segregate user-space and go to lower
power mode anyway".

If that's true, then this problem can be fixed in user-space, and in
fact, it already is on N900. Good behaving applications are
asynchronous, use g_timeout_add_seconds() to align bursts of work at
the same second intervals, and don't do polls directly, but use GLib's
mainloop. Same as in GNOME desktop. It seems there are other methods
to align multiple processes for longer periods of time, but that code
is closed and I can't find much information.

> * QoS is closer to the apps pov: fps if it is a media player or a game,
> transfer speed if it is a file manager, bandwidth if it is a network app,
> etc
> The app is required to express its opinion by using a format that it
> understands better and is less system dependent.
> Actually the kernel should only be concerned with 2 parameters at most for
> any given operation: latency and bandwidth/throughput

I think this information can be obtained dynamically while the
application is running, and perhaps the limits can be stored. It would
be pretty difficult for the applications to give this kind of
information because there are so many variables.

For example, an media player can tell you: this clip has 24 fps, but
if the user is moving the time slider, the fps would increase and drop
very rapidly, and how much depends at least on the container format
and type of seek.

A game or a telephony app could tell you "I need real-time priority"
but so much as giving the details of latency and bandwidth? I find
that very unlikely.

Cheers.

-- 
Felipe Contreras

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Brian Swetland wrote:
>> How is it flawed?  Serious question.
>
> I would avoid repeating all the good arguments given so far, but to make it
> short:
>
> * I believe runtime PM is a much better starting point (at least for the
> type of HW targeted at mobile devices) because it mimics an always-on system
> toward userspace, which requires less disruption in the way apps are
> designed

I agree.

If I understand correctly, if we have a perfect user-space that only
does work when strictly needed and trying to do it in bursts, then we
would be reaching the lowest power state, and there would be no need
for suspend. The problem is that Android's user-space is pretty far
from that, so they said "let's segregate user-space and go to lower
power mode anyway".

If that's true, then this problem can be fixed in user-space, and in
fact, it already is on N900. Good behaving applications are
asynchronous, use g_timeout_add_seconds() to align bursts of work at
the same second intervals, and don't do polls directly, but use GLib's
mainloop. Same as in GNOME desktop. It seems there are other methods
to align multiple processes for longer periods of time, but that code
is closed and I can't find much information.

> * QoS is closer to the apps pov: fps if it is a media player or a game,
> transfer speed if it is a file manager, bandwidth if it is a network app,
> etc
> The app is required to express its opinion by using a format that it
> understands better and is less system dependent.
> Actually the kernel should only be concerned with 2 parameters at most for
> any given operation: latency and bandwidth/throughput

I think this information can be obtained dynamically while the
application is running, and perhaps the limits can be stored. It would
be pretty difficult for the applications to give this kind of
information because there are so many variables.

For example, an media player can tell you: this clip has 24 fps, but
if the user is moving the time slider, the fps would increase and drop
very rapidly, and how much depends at least on the container format
and type of seek.

A game or a telephony app could tell you "I need real-time priority"
but so much as giving the details of latency and bandwidth? I find
that very unlikely.

Cheers.

-- 
Felipe Contreras
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.
>
> Again, Alan, Thomas and myself don't argue against that, what we do
> however argue against is suspend running apps as a form of power
> management.
>

You seem to argue that android is not allowed to use suspend because
the hardware we have shipped on can enter the same power state from
idle. From my point of view, since we need to support suspend on some
hardware we should be allowed to leverage this solution on the better
hardware platforms as well if it improves our battery life.

> If you were to read Alan's latest posts he clearly outlines how you can
> contain crappy apps.
>

I have not seen any suggestions for how to deal with all our
interprocess dependencies when pausing a subset of processes. Without
a solution to that we can only pause a subset of the processes we want
to pause.

> A combination of weakening QoS guarantees (delaying wakeups etc.)
> blocking on resources (delay servicing requests) and monitoring resource
> usage (despite all that its still not idle) and taking affirmative
> action (shoot it in the head).
>
> If we pose that a well behaved application is one that listens to the
> environment hints and idles when told to, we can let regular power
> management kick in and let deep idle states do their thing.
>
> If a bad application ignores those hints and manages to avoid getting
> blocked on denied resources, we can easily spot it and promote an
> attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM
> and SIGKILL, possibly coupled with a pop-up dialog -- much like we get
> today when we try to close a window and the app isn't responding.
>
> If we then also let the environment maintain a shitlist of crappy apps
> (those it had to take affirmative action against) and maybe set up a
> service that allows people to share their results, it provides an
> incentive to the app developers to fix their thing.
>
> How is this not working?
>

These solutions do not allow us to use suspend. They may get us closer
to the power consumption we get from suspend on the good hardware or
even surpass it, but we still need suspend on some hardware, and we
would get event better results by using these solutions in addition to
suspend compared to using them instead of suspend.

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.
>
> Again, Alan, Thomas and myself don't argue against that, what we do
> however argue against is suspend running apps as a form of power
> management.
>

You seem to argue that android is not allowed to use suspend because
the hardware we have shipped on can enter the same power state from
idle. From my point of view, since we need to support suspend on some
hardware we should be allowed to leverage this solution on the better
hardware platforms as well if it improves our battery life.

> If you were to read Alan's latest posts he clearly outlines how you can
> contain crappy apps.
>

I have not seen any suggestions for how to deal with all our
interprocess dependencies when pausing a subset of processes. Without
a solution to that we can only pause a subset of the processes we want
to pause.

> A combination of weakening QoS guarantees (delaying wakeups etc.)
> blocking on resources (delay servicing requests) and monitoring resource
> usage (despite all that its still not idle) and taking affirmative
> action (shoot it in the head).
>
> If we pose that a well behaved application is one that listens to the
> environment hints and idles when told to, we can let regular power
> management kick in and let deep idle states do their thing.
>
> If a bad application ignores those hints and manages to avoid getting
> blocked on denied resources, we can easily spot it and promote an
> attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM
> and SIGKILL, possibly coupled with a pop-up dialog -- much like we get
> today when we try to close a window and the app isn't responding.
>
> If we then also let the environment maintain a shitlist of crappy apps
> (those it had to take affirmative action against) and maybe set up a
> service that allows people to share their results, it provides an
> incentive to the app developers to fix their thing.
>
> How is this not working?
>

These solutions do not allow us to use suspend. They may get us closer
to the power consumption we get from suspend on the good hardware or
even surpass it, but we still need suspend on some hardware, and we
would get event better results by using these solutions in addition to
suspend compared to using them instead of suspend.

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
>> Keep in mind, though, that a solution which is acceptable for Android
>> has to include making sure that crappy applications don't cause the
>> battery to get drained.  There seem to be some people who seem
>> adamently against this requirement.
>
> Again, Alan, Thomas and myself don't argue against that, what we do
> however argue against is suspend running apps as a form of power
> management.
>

You seem to argue that android is not allowed to use suspend because
the hardware we have shipped on can enter the same power state from
idle. From my point of view, since we need to support suspend on some
hardware we should be allowed to leverage this solution on the better
hardware platforms as well if it improves our battery life.

> If you were to read Alan's latest posts he clearly outlines how you can
> contain crappy apps.
>

I have not seen any suggestions for how to deal with all our
interprocess dependencies when pausing a subset of processes. Without
a solution to that we can only pause a subset of the processes we want
to pause.

> A combination of weakening QoS guarantees (delaying wakeups etc.)
> blocking on resources (delay servicing requests) and monitoring resource
> usage (despite all that its still not idle) and taking affirmative
> action (shoot it in the head).
>
> If we pose that a well behaved application is one that listens to the
> environment hints and idles when told to, we can let regular power
> management kick in and let deep idle states do their thing.
>
> If a bad application ignores those hints and manages to avoid getting
> blocked on denied resources, we can easily spot it and promote an
> attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM
> and SIGKILL, possibly coupled with a pop-up dialog -- much like we get
> today when we try to close a window and the app isn't responding.
>
> If we then also let the environment maintain a shitlist of crappy apps
> (those it had to take affirmative action against) and maybe set up a
> service that allows people to share their results, it provides an
> incentive to the app developers to fix their thing.
>
> How is this not working?
>

These solutions do not allow us to use suspend. They may get us closer
to the power consumption we get from suspend on the good hardware or
even surpass it, but we still need suspend on some hardware, and we
would get event better results by using these solutions in addition to
suspend compared to using them instead of suspend.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Rafael J. Wysocki <rjw@sisk.pl>:
> On Friday 28 May 2010, Arve Hjønnevåg wrote:
>> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
>> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
>> > Thomas Gleixner <tglx@linutronix.de> wrote:
> ...
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> It is, if the following two conditions hold simultaneously:
>
> (a) Doing full system suspend is ultimately going to bring you more energy
>    savings than the (presumably lowest) idle state you're currently in.
>
> (b) You anticipate that the system will stay idle for a considerably long time
>    such that it's worth suspending.
>

I still don't think this matters. If you are waiting for in interrupt
that cannot wake you up from suspend, then idle is not an indicator
that it is safe to enter suspend. I also don't think you can avoid any
user-space suspend blockers by delaying suspend until the system goes
idle since any page fault could cause it to go idle. Therefore I don't
see a benefit in delaying suspend until idle when the last suspend
blocker is released (it would only mask possible race conditions).

-- 
Arve Hjønnevåg

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Rafael J. Wysocki <rjw@sisk.pl>:
> On Friday 28 May 2010, Arve Hjønnevåg wrote:
>> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
>> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
>> > Thomas Gleixner <tglx@linutronix.de> wrote:
> ...
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> It is, if the following two conditions hold simultaneously:
>
> (a) Doing full system suspend is ultimately going to bring you more energy
>    savings than the (presumably lowest) idle state you're currently in.
>
> (b) You anticipate that the system will stay idle for a considerably long time
>    such that it's worth suspending.
>

I still don't think this matters. If you are waiting for in interrupt
that cannot wake you up from suspend, then idle is not an indicator
that it is safe to enter suspend. I also don't think you can avoid any
user-space suspend blockers by delaying suspend until the system goes
idle since any page fault could cause it to go idle. Therefore I don't
see a benefit in delaying suspend until idle when the last suspend
blocker is released (it would only mask possible race conditions).

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/28 Rafael J. Wysocki <rjw@sisk.pl>:
> On Friday 28 May 2010, Arve Hjønnevåg wrote:
>> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@mickler.org> wrote:
>> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
>> > Thomas Gleixner <tglx@linutronix.de> wrote:
> ...
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> It is, if the following two conditions hold simultaneously:
>
> (a) Doing full system suspend is ultimately going to bring you more energy
>    savings than the (presumably lowest) idle state you're currently in.
>
> (b) You anticipate that the system will stay idle for a considerably long time
>    such that it's worth suspending.
>

I still don't think this matters. If you are waiting for in interrupt
that cannot wake you up from suspend, then idle is not an indicator
that it is safe to enter suspend. I also don't think you can avoid any
user-space suspend blockers by delaying suspend until the system goes
idle since any page fault could cause it to go idle. Therefore I don't
see a benefit in delaying suspend until idle when the last suspend
blocker is released (it would only mask possible race conditions).

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 1/8] PM: Opportunistic suspend support.

[mark gross]

On Thu, May 27, 2010 at 05:23:54PM +1000, Neil Brown wrote:
> On Wed, 26 May 2010 14:20:51 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> > 
> > > I fail to see why. In both cases the woken userspace will contact a
> > > central governing task, either the kernel or the userspace suspend
> > > manager, and inform it there is work to be done, and please don't
> > > suspend now.
> > 
> > Thinking about this, you're right - we don't have to wait, but that does 
> > result in another problem. Imagine we get two wakeup events 
> > approximately simultaneously. In the kernel-level universe the kernel 
> > knows when both have been handled. In the user-level universe, we may 
> > have one task schedule, bump the count, handle the event, drop the count 
> > and then we attempt a suspend again because the second event handler 
> > hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> > immediately bounce back up. That's kind of wasteful, although it'd be 
> > somewhat mitigated by checking that right at the top of suspend entry 
> > and returning -EAGAIN or similar.
> > 
> 
> (I'm coming a little late to this party, so excuse me if I say something that
> has already been covered however...)
> 
> The above triggers a sequence of thoughts which (When they settled down) look
> a bit like this.
> 
> At the hardware level, there is a thing that we could call a "suspend
> blocker".  It is an interrupt (presumably level-triggered) that causes the
> processor to come out of suspend, or not to go into it.
> 
> Maybe it makes sense to export a similar thing from the kernel to user-space.
> When any event happens that would wake the device (and drivers need to know
> about these already), it would present something to user-space to say that
> the event happened.
> 
> When user-space processes the event, it clears the event indicator.

we did I proposed making the suspend enabling a oneshot type of thing
and all sorts of weak arguments came spewing forth.  I honestly couldn't
tell if I was reading valid input or fanboy BS.

--mgross


> 
> When there are no more current event indicators, userspace is allowed to
> request a suspend.  Obviously this could fail as an event could happen at any
> moment, but the same is true when the kernel asks the device to suspend, an
> interrupt might happen immediately to stop it.  But in either case an event
> will be reported.  So when userspace requests a suspend and it fails, it
> will see events reported and so will wait for them to be handled.
> 
> I imagine a sysfs directory with files that appear when events are pending.
> We could have some separate mechanism for user-space processes to request
> that the suspend-daemon not suspend.  Then it suspends whenever there are no
> pending requests from user-space or from the kernel.
> 
> The advantage of this model of suspend-blockers is that it is a close
> analogue for something that already exists in hardware so it isn't really
> creating new concepts, just giving the Linux virtual-machine features that
> have proved themselves in physical machines.
> 
> The cost is that any wake-up event needs to not only be handled, but also
> explicitly acknowledged by clearing the relevant suspend-blocker (i.e.
> removing the file from sysfs, or whatever interface was ultimately chosen).
> I'm hoping that isn't a big cost.
> 
> NeilBrown
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[mark gross]

On Thu, May 27, 2010 at 05:23:54PM +1000, Neil Brown wrote:
> On Wed, 26 May 2010 14:20:51 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
> > 
> > > I fail to see why. In both cases the woken userspace will contact a
> > > central governing task, either the kernel or the userspace suspend
> > > manager, and inform it there is work to be done, and please don't
> > > suspend now.
> > 
> > Thinking about this, you're right - we don't have to wait, but that does 
> > result in another problem. Imagine we get two wakeup events 
> > approximately simultaneously. In the kernel-level universe the kernel 
> > knows when both have been handled. In the user-level universe, we may 
> > have one task schedule, bump the count, handle the event, drop the count 
> > and then we attempt a suspend again because the second event handler 
> > hasn't had an opportunity to run yet. We'll then attempt a suspend and 
> > immediately bounce back up. That's kind of wasteful, although it'd be 
> > somewhat mitigated by checking that right at the top of suspend entry 
> > and returning -EAGAIN or similar.
> > 
> 
> (I'm coming a little late to this party, so excuse me if I say something that
> has already been covered however...)
> 
> The above triggers a sequence of thoughts which (When they settled down) look
> a bit like this.
> 
> At the hardware level, there is a thing that we could call a "suspend
> blocker".  It is an interrupt (presumably level-triggered) that causes the
> processor to come out of suspend, or not to go into it.
> 
> Maybe it makes sense to export a similar thing from the kernel to user-space.
> When any event happens that would wake the device (and drivers need to know
> about these already), it would present something to user-space to say that
> the event happened.
> 
> When user-space processes the event, it clears the event indicator.

we did I proposed making the suspend enabling a oneshot type of thing
and all sorts of weak arguments came spewing forth.  I honestly couldn't
tell if I was reading valid input or fanboy BS.

--mgross


> 
> When there are no more current event indicators, userspace is allowed to
> request a suspend.  Obviously this could fail as an event could happen at any
> moment, but the same is true when the kernel asks the device to suspend, an
> interrupt might happen immediately to stop it.  But in either case an event
> will be reported.  So when userspace requests a suspend and it fails, it
> will see events reported and so will wait for them to be handled.
> 
> I imagine a sysfs directory with files that appear when events are pending.
> We could have some separate mechanism for user-space processes to request
> that the suspend-daemon not suspend.  Then it suspends whenever there are no
> pending requests from user-space or from the kernel.
> 
> The advantage of this model of suspend-blockers is that it is a close
> analogue for something that already exists in hardware so it isn't really
> creating new concepts, just giving the Linux virtual-machine features that
> have proved themselves in physical machines.
> 
> The cost is that any wake-up event needs to not only be handled, but also
> explicitly acknowledged by clearing the relevant suspend-blocker (i.e.
> removing the file from sysfs, or whatever interface was ultimately chosen).
> I'm hoping that isn't a big cost.
> 
> NeilBrown
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[mark gross]

On Thu, May 27, 2010 at 11:06:23AM -0400, Alan Stern wrote:
> If people don't mind, here is a greatly simplified summary of the 
> comments and objections I have seen so far on this thread:
> 
> 	The in-kernel suspend blocker implementation is okay, even
> 	beneficial.

Only if they only block.  You get into trouble when the in kernel
un-block opperation triggers an implicit suspend. 


> 
> 	Opportunistic suspends are okay.
> 
> 	The proposed userspace API is too Android-specific.
> 
> 	More kernel mechanisms are needed for expressing processes'
> 	latency requirements.

True.

--mgross

> 
> The last one is obviously a longer-term issue, so let's ignore it for
> now.  That leaves as the only point of contention the userspace
> suspend-blocker API.
> 
> The proposal I made a couple of days ago removes this API and leaves
> the other things (i.e., the in-kernel suspend blockers and
> opportunistic suspend) intact.  In place of the userspace
> kernel-blocker API, Android would have to implement a power manager
> process that would essentially juggle all the latency requirements in
> userspace.
> 
> Communication between the power manager process and the kernel would be 
> limited to adding a new "opportunistic" entry to /sys/power/state -- 
> something which could well be useful in its own right.  Even if this 
> API turns out not to be good, it's simple enough that it could be 
> removed pretty easily.
> 
> This answers Alan Cox's (and other's) desire not to implement a 
> questionable or special-purpose API.  And it also answers Thomas's 
> desire to make scheduling decisions based on latency requirements 
> (although the answer is simply to punt all these decisions out of the 
> kernel and into userspace -- which is reasonable for now since the 
> alternative would require a long-term kernel development effort).
> 
> Indeed, having a power manager thread may well turn out to be a useful
> thing -- but even if it doesn't, this scheme minimizes the damage while
> still allowing the Android platform to use a vanilla kernel with only
> limited modifications to their userspace.
> 
> Alan Stern
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/8] Suspend block api (version 8)

[mark gross]

On Thu, May 27, 2010 at 11:06:23AM -0400, Alan Stern wrote:
> If people don't mind, here is a greatly simplified summary of the 
> comments and objections I have seen so far on this thread:
> 
> 	The in-kernel suspend blocker implementation is okay, even
> 	beneficial.

Only if they only block.  You get into trouble when the in kernel
un-block opperation triggers an implicit suspend. 


> 
> 	Opportunistic suspends are okay.
> 
> 	The proposed userspace API is too Android-specific.
> 
> 	More kernel mechanisms are needed for expressing processes'
> 	latency requirements.

True.

--mgross

> 
> The last one is obviously a longer-term issue, so let's ignore it for
> now.  That leaves as the only point of contention the userspace
> suspend-blocker API.
> 
> The proposal I made a couple of days ago removes this API and leaves
> the other things (i.e., the in-kernel suspend blockers and
> opportunistic suspend) intact.  In place of the userspace
> kernel-blocker API, Android would have to implement a power manager
> process that would essentially juggle all the latency requirements in
> userspace.
> 
> Communication between the power manager process and the kernel would be 
> limited to adding a new "opportunistic" entry to /sys/power/state -- 
> something which could well be useful in its own right.  Even if this 
> API turns out not to be good, it's simple enough that it could be 
> removed pretty easily.
> 
> This answers Alan Cox's (and other's) desire not to implement a 
> questionable or special-purpose API.  And it also answers Thomas's 
> desire to make scheduling decisions based on latency requirements 
> (although the answer is simply to punt all these decisions out of the 
> kernel and into userspace -- which is reasonable for now since the 
> alternative would require a long-term kernel development effort).
> 
> Indeed, having a power manager thread may well turn out to be a useful
> thing -- but even if it doesn't, this scheme minimizes the damage while
> still allowing the Android platform to use a vanilla kernel with only
> limited modifications to their userspace.
> 
> Alan Stern
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 7:52 PM, mark gross <640e9920@gmail.com> wrote:
> On Thu, May 27, 2010 at 05:23:54PM +1000, Neil Brown wrote:
>> On Wed, 26 May 2010 14:20:51 +0100
>> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>>
>> > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
>> >
>> > > I fail to see why. In both cases the woken userspace will contact a
>> > > central governing task, either the kernel or the userspace suspend
>> > > manager, and inform it there is work to be done, and please don't
>> > > suspend now.
>> >
>> > Thinking about this, you're right - we don't have to wait, but that does
>> > result in another problem. Imagine we get two wakeup events
>> > approximately simultaneously. In the kernel-level universe the kernel
>> > knows when both have been handled. In the user-level universe, we may
>> > have one task schedule, bump the count, handle the event, drop the count
>> > and then we attempt a suspend again because the second event handler
>> > hasn't had an opportunity to run yet. We'll then attempt a suspend and
>> > immediately bounce back up. That's kind of wasteful, although it'd be
>> > somewhat mitigated by checking that right at the top of suspend entry
>> > and returning -EAGAIN or similar.
>> >
>>
>> (I'm coming a little late to this party, so excuse me if I say something that
>> has already been covered however...)
>>
>> The above triggers a sequence of thoughts which (When they settled down) look
>> a bit like this.
>>
>> At the hardware level, there is a thing that we could call a "suspend
>> blocker".  It is an interrupt (presumably level-triggered) that causes the
>> processor to come out of suspend, or not to go into it.
>>
>> Maybe it makes sense to export a similar thing from the kernel to user-space.
>> When any event happens that would wake the device (and drivers need to know
>> about these already), it would present something to user-space to say that
>> the event happened.
>>
>> When user-space processes the event, it clears the event indicator.
>
> we did I proposed making the suspend enabling a oneshot type of thing
> and all sorts of weak arguments came spewing forth.  I honestly couldn't
> tell if I was reading valid input or fanboy BS.
>

Can you be more specific? If you are talking about only letting
drivers abort suspend, not block it, then the main argument against
that is that you are forcing user-space to poll until the driver stops
aborting suspend (which according to people arguing against us using
suspend would make the power-manager a "bad" process). Or are you
talking about blocking the request from user-space until all other
suspend-blockers have been released and then doing a single suspend
cycle before returning. This would not be as bad, but it would force
the user-space power manager to be multi-threaded since it now would
have way to cancel the request. Either way, what problem are you
trying to solve by making it a one-shot request?

-- 
Arve Hjønnevåg

Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Arve Hjønnevåg]

On Fri, May 28, 2010 at 7:52 PM, mark gross <640e9920@gmail.com> wrote:
> On Thu, May 27, 2010 at 05:23:54PM +1000, Neil Brown wrote:
>> On Wed, 26 May 2010 14:20:51 +0100
>> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>>
>> > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote:
>> >
>> > > I fail to see why. In both cases the woken userspace will contact a
>> > > central governing task, either the kernel or the userspace suspend
>> > > manager, and inform it there is work to be done, and please don't
>> > > suspend now.
>> >
>> > Thinking about this, you're right - we don't have to wait, but that does
>> > result in another problem. Imagine we get two wakeup events
>> > approximately simultaneously. In the kernel-level universe the kernel
>> > knows when both have been handled. In the user-level universe, we may
>> > have one task schedule, bump the count, handle the event, drop the count
>> > and then we attempt a suspend again because the second event handler
>> > hasn't had an opportunity to run yet. We'll then attempt a suspend and
>> > immediately bounce back up. That's kind of wasteful, although it'd be
>> > somewhat mitigated by checking that right at the top of suspend entry
>> > and returning -EAGAIN or similar.
>> >
>>
>> (I'm coming a little late to this party, so excuse me if I say something that
>> has already been covered however...)
>>
>> The above triggers a sequence of thoughts which (When they settled down) look
>> a bit like this.
>>
>> At the hardware level, there is a thing that we could call a "suspend
>> blocker".  It is an interrupt (presumably level-triggered) that causes the
>> processor to come out of suspend, or not to go into it.
>>
>> Maybe it makes sense to export a similar thing from the kernel to user-space.
>> When any event happens that would wake the device (and drivers need to know
>> about these already), it would present something to user-space to say that
>> the event happened.
>>
>> When user-space processes the event, it clears the event indicator.
>
> we did I proposed making the suspend enabling a oneshot type of thing
> and all sorts of weak arguments came spewing forth.  I honestly couldn't
> tell if I was reading valid input or fanboy BS.
>

Can you be more specific? If you are talking about only letting
drivers abort suspend, not block it, then the main argument against
that is that you are forcing user-space to poll until the driver stops
aborting suspend (which according to people arguing against us using
suspend would make the power-manager a "bad" process). Or are you
talking about blocking the request from user-space until all other
suspend-blockers have been released and then doing a single suspend
cycle before returning. This would not be as bad, but it would force
the user-space power manager to be multi-threaded since it now would
have way to cancel the request. Either way, what problem are you
trying to solve by making it a one-shot request?

-- 
Arve Hjønnevåg

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 23:44 +0200, Rafael J. Wysocki wrote:
> Consider updatedb or another file indexing ... thing on a laptop.  I certainly
> don't want anything like this to run and drain my battery, even if it has
> already been started when the machine was on AC power.  Now, of course,
> I can kill it, but for that I need to notice that it's running and it presumably
> might have done some job already and it would be wasteful to lose it.
> It would be quite nice if that app was not regarded as runnable when the
> system was on battery power. 

How will a ionice on steriods that will defer servicing IO when the IO
system QoS limit doesn't meet the updatedb process's level is too low,
not solve this?

In that case the updatedb process will simply block on IO, will hence
not be runnable and thus not drain your battery.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 23:44 +0200, Rafael J. Wysocki wrote:
> Consider updatedb or another file indexing ... thing on a laptop.  I certainly
> don't want anything like this to run and drain my battery, even if it has
> already been started when the machine was on AC power.  Now, of course,
> I can kill it, but for that I need to notice that it's running and it presumably
> might have done some job already and it would be wasteful to lose it.
> It would be quite nice if that app was not regarded as runnable when the
> system was on battery power. 

How will a ionice on steriods that will defer servicing IO when the IO
system QoS limit doesn't meet the updatedb process's level is too low,
not solve this?

In that case the updatedb process will simply block on IO, will hence
not be runnable and thus not drain your battery.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-05-29 at 00:18 +0200, Rafael J. Wysocki wrote:
> On Friday 28 May 2010, Peter Zijlstra wrote:
> > On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> > > Today "idle" means "no task running"
> > > 
> > > If you are prepared to rephrase that as "no task that matters is running"
> > > what would need to answer ?
> > 
> > I'm not sure we need or want to go there.
> > 
> > Why not simply let upatedb block on its IO because its QoS policy tells
> > us that its IO priority is idle. Therefore it will not avoid the IO
> > device from going idle and indefinitely delaying servicing requests.
> > 
> > When updatedb blocks, the runqueue becomes empty and we gain goodness.
> > 
> > Or are we talking about the same thing?
> 
> There may be apps that don't actually do I/O that we may want to be treated
> that way too.
> 
> Consider the following scenario.  I have a purely computational task that's
> running on my laptop in the background (say it's a folding@home or something
> similar), but I only want it to run when (a) the box is on AC power and (b)
> when user interface is "active" (the latter would have to be defined precisely,
> but for the purpose of this thought experiment let's assume we have such a
> definition).  Then, I'd only like it to be regarded as runnable if (a) and (b)
> both happen at the same time, but it can't block on I/O.

Well, both folding@home and Seti will need to do some IO in order to get
new data and report results, although the computational task might
indeed take quite a while before it does so.

Such tasks should listen to general environment hints, we already have
battery power state exposed, make it use that information. The user
interface is active can be gotten from X.

The thing is, if its a well behaved app and listens to the environment
hints, it will work as you want (could be done by policy knobs
all-round).

The only problem is dealing with apps that don't listen, those are
considered bad/buggy and hence we don't particularly care if they don't
function properly.

For long-running computational tasks we will send a progression of
SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL if they keep violating
policy.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-05-29 at 00:18 +0200, Rafael J. Wysocki wrote:
> On Friday 28 May 2010, Peter Zijlstra wrote:
> > On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
> > > Today "idle" means "no task running"
> > > 
> > > If you are prepared to rephrase that as "no task that matters is running"
> > > what would need to answer ?
> > 
> > I'm not sure we need or want to go there.
> > 
> > Why not simply let upatedb block on its IO because its QoS policy tells
> > us that its IO priority is idle. Therefore it will not avoid the IO
> > device from going idle and indefinitely delaying servicing requests.
> > 
> > When updatedb blocks, the runqueue becomes empty and we gain goodness.
> > 
> > Or are we talking about the same thing?
> 
> There may be apps that don't actually do I/O that we may want to be treated
> that way too.
> 
> Consider the following scenario.  I have a purely computational task that's
> running on my laptop in the background (say it's a folding@home or something
> similar), but I only want it to run when (a) the box is on AC power and (b)
> when user interface is "active" (the latter would have to be defined precisely,
> but for the purpose of this thought experiment let's assume we have such a
> definition).  Then, I'd only like it to be regarded as runnable if (a) and (b)
> both happen at the same time, but it can't block on I/O.

Well, both folding@home and Seti will need to do some IO in order to get
new data and report results, although the computational task might
indeed take quite a while before it does so.

Such tasks should listen to general environment hints, we already have
battery power state exposed, make it use that information. The user
interface is active can be gotten from X.

The thing is, if its a well behaved app and listens to the environment
hints, it will work as you want (could be done by policy knobs
all-round).

The only problem is dealing with apps that don't listen, those are
considered bad/buggy and hence we don't particularly care if they don't
function properly.

For long-running computational tasks we will send a progression of
SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL if they keep violating
policy.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
> >> Keep in mind, though, that a solution which is acceptable for Android
> >> has to include making sure that crappy applications don't cause the
> >> battery to get drained.  There seem to be some people who seem
> >> adamently against this requirement.
> >
> > Again, Alan, Thomas and myself don't argue against that, what we do
> > however argue against is suspend running apps as a form of power
> > management.
> >
> 
> You seem to argue that android is not allowed to use suspend because
> the hardware we have shipped on can enter the same power state from
> idle. From my point of view, since we need to support suspend on some
> hardware we should be allowed to leverage this solution on the better
> hardware platforms as well if it improves our battery life.

Correct, I strongly oppose using suspend. Not running runnable tasks is
not a sane solution.

If current hardware can't cope, too friggin bad, get better hardware.

But the truth is, all your OMAP phones really can deal with it.

> I have not seen any suggestions for how to deal with all our
> interprocess dependencies when pausing a subset of processes. Without
> a solution to that we can only pause a subset of the processes we want
> to pause.

Do not 'pause' processes and you don't have the problem, make them stop
on their own accord or kill them if they dont listen.. who cares about
ill-behaved apps anyway?

But really, if you want a more detailed answer, you need to provide more
detail on these problems.

If you want to allow an untrusted app to provide a dependency for a
trusted app, you've lost and I don't care.

Trusted apps should be well behaved, otherwise there really is no point.

> These solutions do not allow us to use suspend. They may get us closer
> to the power consumption we get from suspend on the good hardware or
> even surpass it, but we still need suspend on some hardware, and we
> would get event better results by using these solutions in addition to
> suspend compared to using them instead of suspend.

Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.

You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.

The only abstraction that really makes sense in that view is idle
states.

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
> >> Keep in mind, though, that a solution which is acceptable for Android
> >> has to include making sure that crappy applications don't cause the
> >> battery to get drained.  There seem to be some people who seem
> >> adamently against this requirement.
> >
> > Again, Alan, Thomas and myself don't argue against that, what we do
> > however argue against is suspend running apps as a form of power
> > management.
> >
> 
> You seem to argue that android is not allowed to use suspend because
> the hardware we have shipped on can enter the same power state from
> idle. From my point of view, since we need to support suspend on some
> hardware we should be allowed to leverage this solution on the better
> hardware platforms as well if it improves our battery life.

Correct, I strongly oppose using suspend. Not running runnable tasks is
not a sane solution.

If current hardware can't cope, too friggin bad, get better hardware.

But the truth is, all your OMAP phones really can deal with it.

> I have not seen any suggestions for how to deal with all our
> interprocess dependencies when pausing a subset of processes. Without
> a solution to that we can only pause a subset of the processes we want
> to pause.

Do not 'pause' processes and you don't have the problem, make them stop
on their own accord or kill them if they dont listen.. who cares about
ill-behaved apps anyway?

But really, if you want a more detailed answer, you need to provide more
detail on these problems.

If you want to allow an untrusted app to provide a dependency for a
trusted app, you've lost and I don't care.

Trusted apps should be well behaved, otherwise there really is no point.

> These solutions do not allow us to use suspend. They may get us closer
> to the power consumption we get from suspend on the good hardware or
> even surpass it, but we still need suspend on some hardware, and we
> would get event better results by using these solutions in addition to
> suspend compared to using them instead of suspend.

Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.

You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.

The only abstraction that really makes sense in that view is idle
states.


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, 2010-05-28 at 00:31 -0400, tytso@mit.edu wrote:
> >> Keep in mind, though, that a solution which is acceptable for Android
> >> has to include making sure that crappy applications don't cause the
> >> battery to get drained.  There seem to be some people who seem
> >> adamently against this requirement.
> >
> > Again, Alan, Thomas and myself don't argue against that, what we do
> > however argue against is suspend running apps as a form of power
> > management.
> >
> 
> You seem to argue that android is not allowed to use suspend because
> the hardware we have shipped on can enter the same power state from
> idle. From my point of view, since we need to support suspend on some
> hardware we should be allowed to leverage this solution on the better
> hardware platforms as well if it improves our battery life.

Correct, I strongly oppose using suspend. Not running runnable tasks is
not a sane solution.

If current hardware can't cope, too friggin bad, get better hardware.

But the truth is, all your OMAP phones really can deal with it.

> I have not seen any suggestions for how to deal with all our
> interprocess dependencies when pausing a subset of processes. Without
> a solution to that we can only pause a subset of the processes we want
> to pause.

Do not 'pause' processes and you don't have the problem, make them stop
on their own accord or kill them if they dont listen.. who cares about
ill-behaved apps anyway?

But really, if you want a more detailed answer, you need to provide more
detail on these problems.

If you want to allow an untrusted app to provide a dependency for a
trusted app, you've lost and I don't care.

Trusted apps should be well behaved, otherwise there really is no point.

> These solutions do not allow us to use suspend. They may get us closer
> to the power consumption we get from suspend on the good hardware or
> even surpass it, but we still need suspend on some hardware, and we
> would get event better results by using these solutions in addition to
> suspend compared to using them instead of suspend.

Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.

You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.

The only abstraction that really makes sense in that view is idle
states.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 02:42:35 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> > ext Brian Swetland wrote:
> >> How is it flawed?  Serious question.
> >
> > I would avoid repeating all the good arguments given so far, but to make it
> > short:
> >
> > * I believe runtime PM is a much better starting point (at least for the
> > type of HW targeted at mobile devices) because it mimics an always-on system
> > toward userspace, which requires less disruption in the way apps are
> > designed
> 
> I agree.
> 
> If I understand correctly, if we have a perfect user-space that only
> does work when strictly needed and trying to do it in bursts, then we
> would be reaching the lowest power state, and there would be no need
> for suspend. The problem is that Android's user-space is pretty far
> from that, so they said "let's segregate user-space and go to lower
> power mode anyway".

This has already been mentioned (who knew?): Android doesn't
want to depend on userspace for this.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 02:42:35 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> > ext Brian Swetland wrote:
> >> How is it flawed?  Serious question.
> >
> > I would avoid repeating all the good arguments given so far, but to make it
> > short:
> >
> > * I believe runtime PM is a much better starting point (at least for the
> > type of HW targeted at mobile devices) because it mimics an always-on system
> > toward userspace, which requires less disruption in the way apps are
> > designed
> 
> I agree.
> 
> If I understand correctly, if we have a perfect user-space that only
> does work when strictly needed and trying to do it in bursts, then we
> would be reaching the lowest power state, and there would be no need
> for suspend. The problem is that Android's user-space is pretty far
> from that, so they said "let's segregate user-space and go to lower
> power mode anyway".

This has already been mentioned (who knew?): Android doesn't
want to depend on userspace for this.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Ok lets try and produce something more concrete. The control groups may
> be the wrong tool but we've got several such tools already
>
>
> Kernel involved
> ----------------
> acquire:                mark myself important (into cgroup important)
> acquire(timeout)        ditto, plus app timer/timeout handler
> release:                mark myself unimportant (into cgroup downtrodden)

May we somehow live without acquire(timeout)? This is the feature that
can screw up a lot of things with very complicated debugging options.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/28 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Ok lets try and produce something more concrete. The control groups may
> be the wrong tool but we've got several such tools already
>
>
> Kernel involved
> ----------------
> acquire:                mark myself important (into cgroup important)
> acquire(timeout)        ditto, plus app timer/timeout handler
> release:                mark myself unimportant (into cgroup downtrodden)

May we somehow live without acquire(timeout)? This is the feature that
can screw up a lot of things with very complicated debugging options.

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Fri, May 28, 2010 at 2:52 PM, Brian Swetland <swetland@google.com> wrote:
> I am quite willing to state that on both MSM and OMAP based Android
> platforms, we've found that the suspend blocker model allows us to
> obtain a lower average power draw than if we don't use it -- Mike Chan
> provided some numbers earlier in another thread in the trivial device
> idle case, the win is of course much larger in the case of several
> poorly behaved apps being active.

Without the clear description of the experiments, that statement
proves just nothing other than your applications work better with your
model, but I would expect that to be so without any experiments at
all.

~Vitaly

Re: [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Fri, May 28, 2010 at 2:52 PM, Brian Swetland <swetland@google.com> wrote:
> I am quite willing to state that on both MSM and OMAP based Android
> platforms, we've found that the suspend blocker model allows us to
> obtain a lower average power draw than if we don't use it -- Mike Chan
> provided some numbers earlier in another thread in the trivial device
> idle case, the win is of course much larger in the case of several
> poorly behaved apps being active.

Without the clear description of the experiments, that statement
proves just nothing other than your applications work better with your
model, but I would expect that to be so without any experiments at
all.

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 10:28:19 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Sat, 29 May 2010 02:42:35 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> > > ext Brian Swetland wrote:
> > >> How is it flawed?  Serious question.
> > >
> > > I would avoid repeating all the good arguments given so far, but to make it
> > > short:
> > >
> > > * I believe runtime PM is a much better starting point (at least for the
> > > type of HW targeted at mobile devices) because it mimics an always-on system
> > > toward userspace, which requires less disruption in the way apps are
> > > designed
> > 
> > I agree.
> > 
> > If I understand correctly, if we have a perfect user-space that only
> > does work when strictly needed and trying to do it in bursts, then we
> > would be reaching the lowest power state, and there would be no need
> > for suspend. The problem is that Android's user-space is pretty far
> > from that, so they said "let's segregate user-space and go to lower
> > power mode anyway".
> 
> This has already been mentioned (who knew?): Android doesn't
> want to depend on userspace for this.

there is an implicit "all of userspace" in there, btw.. 

> 
> Cheers,
> Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 10:28:19 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Sat, 29 May 2010 02:42:35 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> > > ext Brian Swetland wrote:
> > >> How is it flawed?  Serious question.
> > >
> > > I would avoid repeating all the good arguments given so far, but to make it
> > > short:
> > >
> > > * I believe runtime PM is a much better starting point (at least for the
> > > type of HW targeted at mobile devices) because it mimics an always-on system
> > > toward userspace, which requires less disruption in the way apps are
> > > designed
> > 
> > I agree.
> > 
> > If I understand correctly, if we have a perfect user-space that only
> > does work when strictly needed and trying to do it in bursts, then we
> > would be reaching the lowest power state, and there would be no need
> > for suspend. The problem is that Android's user-space is pretty far
> > from that, so they said "let's segregate user-space and go to lower
> > power mode anyway".
> 
> This has already been mentioned (who knew?): Android doesn't
> want to depend on userspace for this.

there is an implicit "all of userspace" in there, btw.. 

> 
> Cheers,
> Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 10:28:19 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Sat, 29 May 2010 02:42:35 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> > > ext Brian Swetland wrote:
> > >> How is it flawed?  Serious question.
> > >
> > > I would avoid repeating all the good arguments given so far, but to make it
> > > short:
> > >
> > > * I believe runtime PM is a much better starting point (at least for the
> > > type of HW targeted at mobile devices) because it mimics an always-on system
> > > toward userspace, which requires less disruption in the way apps are
> > > designed
> > 
> > I agree.
> > 
> > If I understand correctly, if we have a perfect user-space that only
> > does work when strictly needed and trying to do it in bursts, then we
> > would be reaching the lowest power state, and there would be no need
> > for suspend. The problem is that Android's user-space is pretty far
> > from that, so they said "let's segregate user-space and go to lower
> > power mode anyway".
> 
> This has already been mentioned (who knew?): Android doesn't
> want to depend on userspace for this.

there is an implicit "all of userspace" in there, btw.. 

> 
> Cheers,
> Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 00:11:32 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> 
> Having reconsidered the suspend blockers idea I came to the conclusion that
> in fact it was a workaround for three different problems.

But it is also a change of paradigm. The scheduler should strive to
have the system idle as long as possible to conserve battery. And
everything that does not serve the purpose of the device has to be
considered as not worth running, except if there are other
purpose-fullfilling tasks to run anyway.

 > 
> Thanks,
> Rafael

cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 00:11:32 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> 
> Having reconsidered the suspend blockers idea I came to the conclusion that
> in fact it was a workaround for three different problems.

But it is also a change of paradigm. The scheduler should strive to
have the system idle as long as possible to conserve battery. And
everything that does not serve the purpose of the device has to be
considered as not worth running, except if there are other
purpose-fullfilling tasks to run anyway.

 > 
> Thanks,
> Rafael

cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote:
> On Sat, 29 May 2010 00:11:32 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > 
> > Having reconsidered the suspend blockers idea I came to the conclusion that
> > in fact it was a workaround for three different problems.
> 
> But it is also a change of paradigm. The scheduler should strive to
> have the system idle as long as possible to conserve battery. And
> everything that does not serve the purpose of the device has to be
> considered as not worth running, except if there are other
> purpose-fullfilling tasks to run anyway.

No the purpose of the scheduler is to run tasks when they are runnable.
Not to second guess whatever caused them to become runnable.

If you start to randomly not run tasks, the inversion chaos that ensues
is terrible. You can apply the regular means of alleviating that and
that entails adding *-inheritance to all blockable resources. The -rt
patch set is doing that in part.

You really need to make applications not want to run and block on their
own volition (in a resource free point) and otherwise make them block on
something forcefully and disregard any malfunctioning that would result
from that, and in extreme cases terminate (releasing all resources).

But really Android shouldn't even need kernel support to do all this,
since its hosted on this massive middle-ware that intercepts everything,
called a Java Virtual Machine.

Now, all I'm interested in is providing interfaces from the kernel where
needed, so that userspace can be optimally frugal with power usage, and
can monitor/contain badly behaving tasks.

If Android is so set in its ways that they don't want to adopt (like
saying Android requires suspend for power management) then they can go
their own merry way and I'm not interested anymore (it would be a shame
though).

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote:
> On Sat, 29 May 2010 00:11:32 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > 
> > Having reconsidered the suspend blockers idea I came to the conclusion that
> > in fact it was a workaround for three different problems.
> 
> But it is also a change of paradigm. The scheduler should strive to
> have the system idle as long as possible to conserve battery. And
> everything that does not serve the purpose of the device has to be
> considered as not worth running, except if there are other
> purpose-fullfilling tasks to run anyway.

No the purpose of the scheduler is to run tasks when they are runnable.
Not to second guess whatever caused them to become runnable.

If you start to randomly not run tasks, the inversion chaos that ensues
is terrible. You can apply the regular means of alleviating that and
that entails adding *-inheritance to all blockable resources. The -rt
patch set is doing that in part.

You really need to make applications not want to run and block on their
own volition (in a resource free point) and otherwise make them block on
something forcefully and disregard any malfunctioning that would result
from that, and in extreme cases terminate (releasing all resources).

But really Android shouldn't even need kernel support to do all this,
since its hosted on this massive middle-ware that intercepts everything,
called a Java Virtual Machine.

Now, all I'm interested in is providing interfaces from the kernel where
needed, so that userspace can be optimally frugal with power usage, and
can monitor/contain badly behaving tasks.

If Android is so set in its ways that they don't want to adopt (like
saying Android requires suspend for power management) then they can go
their own merry way and I'm not interested anymore (it would be a shame
though).

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 12:42:37 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote:
> > On Sat, 29 May 2010 00:11:32 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > 
> > > Having reconsidered the suspend blockers idea I came to the conclusion that
> > > in fact it was a workaround for three different problems.
> > 
> > But it is also a change of paradigm. The scheduler should strive to
> > have the system idle as long as possible to conserve battery. And
> > everything that does not serve the purpose of the device has to be
> > considered as not worth running, except if there are other
> > purpose-fullfilling tasks to run anyway.
> 
> No the purpose of the scheduler is to run tasks when they are runnable.
> Not to second guess whatever caused them to become runnable.
> 
> If you start to randomly not run tasks, the inversion chaos that ensues
> is terrible. You can apply the regular means of alleviating that and
> that entails adding *-inheritance to all blockable resources. The -rt
> patch set is doing that in part.

Yes. In the scheduler it becomes a hard problem. But if
you have a clear definition of "purpose" (I mean, after all it is a
phone) and you can annotate this in a way that makes sense. (Suspend
blockers?) Then stopping the scheduler and suspend the device is at
least an easily understandable, maybe naive, approach.

> 
> You really need to make applications not want to run and block on their
> own volition (in a resource free point) and otherwise make them block on
> something forcefully and disregard any malfunctioning that would result
> from that, and in extreme cases terminate (releasing all resources).

I can see why this would be the best solution. But it would also be just
dodging the problem, wouldn't it?
 
> But really Android shouldn't even need kernel support to do all this,
> since its hosted on this massive middle-ware that intercepts everything,
> called a Java Virtual Machine.

Here also, dodging the problem. 

Maybe there is no good solution for this. And maybe it even is not a
generic problem. Suspend blockers block suspend. So that is what they
do. And they have a userspace API (which of course has to be
acceptable and not be borken). And they are optional. 

But having a way in the drivers to annotate some kind of constraints
seems to be a worthwile change in all cases. So this at least should go
in. 

And while there are differing opinions about the android approach
(feature vs misfeature) of suspending all the time, i think this is
addressed by having them configurable. 

Also the fear that userspace becomes infected with platform knowledge
is, in my eyes, only a secondary problem, because it is confined to
the android framework. The android framework guarantess applications
that they run as long as the user interacts with the device.
Applications have to deal with suspend in every case. So no special
knowledge needs to be there.

> Now, all I'm interested in is providing interfaces from the kernel where
> needed, so that userspace can be optimally frugal with power usage, and
> can monitor/contain badly behaving tasks.
> 

I think this is a sensible approach.

Cheers,
Flo

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 29 May 2010 12:42:37 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote:
> > On Sat, 29 May 2010 00:11:32 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > 
> > > Having reconsidered the suspend blockers idea I came to the conclusion that
> > > in fact it was a workaround for three different problems.
> > 
> > But it is also a change of paradigm. The scheduler should strive to
> > have the system idle as long as possible to conserve battery. And
> > everything that does not serve the purpose of the device has to be
> > considered as not worth running, except if there are other
> > purpose-fullfilling tasks to run anyway.
> 
> No the purpose of the scheduler is to run tasks when they are runnable.
> Not to second guess whatever caused them to become runnable.
> 
> If you start to randomly not run tasks, the inversion chaos that ensues
> is terrible. You can apply the regular means of alleviating that and
> that entails adding *-inheritance to all blockable resources. The -rt
> patch set is doing that in part.

Yes. In the scheduler it becomes a hard problem. But if
you have a clear definition of "purpose" (I mean, after all it is a
phone) and you can annotate this in a way that makes sense. (Suspend
blockers?) Then stopping the scheduler and suspend the device is at
least an easily understandable, maybe naive, approach.

> 
> You really need to make applications not want to run and block on their
> own volition (in a resource free point) and otherwise make them block on
> something forcefully and disregard any malfunctioning that would result
> from that, and in extreme cases terminate (releasing all resources).

I can see why this would be the best solution. But it would also be just
dodging the problem, wouldn't it?
 
> But really Android shouldn't even need kernel support to do all this,
> since its hosted on this massive middle-ware that intercepts everything,
> called a Java Virtual Machine.

Here also, dodging the problem. 

Maybe there is no good solution for this. And maybe it even is not a
generic problem. Suspend blockers block suspend. So that is what they
do. And they have a userspace API (which of course has to be
acceptable and not be borken). And they are optional. 

But having a way in the drivers to annotate some kind of constraints
seems to be a worthwile change in all cases. So this at least should go
in. 

And while there are differing opinions about the android approach
(feature vs misfeature) of suspending all the time, i think this is
addressed by having them configurable. 

Also the fear that userspace becomes infected with platform knowledge
is, in my eyes, only a secondary problem, because it is confined to
the android framework. The android framework guarantess applications
that they run as long as the user interacts with the device.
Applications have to deal with suspend in every case. So no special
knowledge needs to be there.

> Now, all I'm interested in is providing interfaces from the kernel where
> needed, so that userspace can be optimally frugal with power usage, and
> can monitor/contain badly behaving tasks.
> 

I think this is a sensible approach.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Sat, 29 May 2010, Florian Mickler wrote:

> On Sat, 29 May 2010 12:42:37 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:

> > Now, all I'm interested in is providing interfaces from the kernel where
> > needed, so that userspace can be optimally frugal with power usage, and
> > can monitor/contain badly behaving tasks.
> > 
> 
> I think this is a sensible approach.

Here is an attempt to satisfy everyone as much as possible.  But first 
an explicit disclaimer: When I say "suspend", I mean it as in 
"suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode.

In place of in-kernel suspend blockers, there will be a new type of QoS 
constraint -- call it QOS_EVENTUALLY.  It's a very weak constraint, 
compatible with all cpuidle modes in which runnable threads are allowed 
to run (which is all of them), but not compatible with suspend.

The Android people want debugging and accountability.  So in the most 
objectionable part of this proposal, we add a new way of registering 
QoS constraints: monitored constraints.  The "monitored" implies that:

	The constraint has a name, which can be used for debugging
	and accounting;

	The kernel maintains statistics on the constraint's use and
	makes them available to userspace; and

	The PM core is notified whenever the number of active monitored
	constraints drops to 0.

There is no /sys/power/policy file.  In place of opportunistic suspend,
we have "QoS-based suspend".  This is initiated by userspace writing
"qos" to /sys/power/state, and it is very much like suspend-to-RAM.
However a QoS-based suspend fails immediately if there are any active
normal QoS constraints incompatible with system suspend, in other
words, any constraints requiring a throughput > 0 or an interrupt
latency shorter than the time required for a suspend-to-RAM/resume
cycle.

If no such constraints are active, the QoS-based suspend blocks in an
interruptible wait until the number of active QOS_EVENTUALLY
constraints drops to 0.  When that happens, it carries out a normal
suspend-to-RAM -- except that it checks along the way to make sure that
no new QoS constraints are activated while the suspend is in progress.  
If they are, the PM core backs out and fails the QoS-based suspend.

Userspace suspend blockers don't exist at all, as far as the kernel is 
concerned.  In their place, the Android runs a power-manager program 
that receives IPC requests from other processes when they need to 
prevent the system from suspending or allow it to suspend.  The power 
manager's main loop looks like this:

	for (;;) {
		while (any IPC requests remain)
			handle them;
		if (any processes need to prevent suspend)
			sleep;
		else
			write "qos" to /sys/power/state;
	}

The idea is that receipt of a new IPC request will cause a signal to be 
sent, interrupting the sleep or the "qos" write.

There remains a question as to which kernel drivers should create 
monitored QOS_EVENTUALLY constraints.  Perhaps userspace could be 
allowed to specify this (I don't know how).  In any case, this is a 
relatively minor point.

The advantages of this scheme are that this does everything the Android
people need, and it does it in a way that's entirely compatible with 
pure QoS/cpuidle-based power management.  It even starts along the path
of making suspend-to-RAM just another kind of dynamic power state.

If people such as Peter still want to complain that using
suspend-to-RAM in Android phones isn't a good way to do power
management, that's okay -- it's the designers' decision to program
their phones the way they want.  At least the kernel can give them the
ability to do so in a way that doesn't compromise everybody else.

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Sat, 29 May 2010, Florian Mickler wrote:

> On Sat, 29 May 2010 12:42:37 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:

> > Now, all I'm interested in is providing interfaces from the kernel where
> > needed, so that userspace can be optimally frugal with power usage, and
> > can monitor/contain badly behaving tasks.
> > 
> 
> I think this is a sensible approach.

Here is an attempt to satisfy everyone as much as possible.  But first 
an explicit disclaimer: When I say "suspend", I mean it as in 
"suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode.

In place of in-kernel suspend blockers, there will be a new type of QoS 
constraint -- call it QOS_EVENTUALLY.  It's a very weak constraint, 
compatible with all cpuidle modes in which runnable threads are allowed 
to run (which is all of them), but not compatible with suspend.

The Android people want debugging and accountability.  So in the most 
objectionable part of this proposal, we add a new way of registering 
QoS constraints: monitored constraints.  The "monitored" implies that:

	The constraint has a name, which can be used for debugging
	and accounting;

	The kernel maintains statistics on the constraint's use and
	makes them available to userspace; and

	The PM core is notified whenever the number of active monitored
	constraints drops to 0.

There is no /sys/power/policy file.  In place of opportunistic suspend,
we have "QoS-based suspend".  This is initiated by userspace writing
"qos" to /sys/power/state, and it is very much like suspend-to-RAM.
However a QoS-based suspend fails immediately if there are any active
normal QoS constraints incompatible with system suspend, in other
words, any constraints requiring a throughput > 0 or an interrupt
latency shorter than the time required for a suspend-to-RAM/resume
cycle.

If no such constraints are active, the QoS-based suspend blocks in an
interruptible wait until the number of active QOS_EVENTUALLY
constraints drops to 0.  When that happens, it carries out a normal
suspend-to-RAM -- except that it checks along the way to make sure that
no new QoS constraints are activated while the suspend is in progress.  
If they are, the PM core backs out and fails the QoS-based suspend.

Userspace suspend blockers don't exist at all, as far as the kernel is 
concerned.  In their place, the Android runs a power-manager program 
that receives IPC requests from other processes when they need to 
prevent the system from suspending or allow it to suspend.  The power 
manager's main loop looks like this:

	for (;;) {
		while (any IPC requests remain)
			handle them;
		if (any processes need to prevent suspend)
			sleep;
		else
			write "qos" to /sys/power/state;
	}

The idea is that receipt of a new IPC request will cause a signal to be 
sent, interrupting the sleep or the "qos" write.

There remains a question as to which kernel drivers should create 
monitored QOS_EVENTUALLY constraints.  Perhaps userspace could be 
allowed to specify this (I don't know how).  In any case, this is a 
relatively minor point.

The advantages of this scheme are that this does everything the Android
people need, and it does it in a way that's entirely compatible with 
pure QoS/cpuidle-based power management.  It even starts along the path
of making suspend-to-RAM just another kind of dynamic power state.

If people such as Peter still want to complain that using
suspend-to-RAM in Android phones isn't a good way to do power
management, that's okay -- it's the designers' decision to program
their phones the way they want.  At least the kernel can give them the
ability to do so in a way that doesn't compromise everybody else.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Sat, 29 May 2010, Peter Zijlstra wrote:

> Correct, I strongly oppose using suspend. Not running runnable tasks is
> not a sane solution.
> 
> If current hardware can't cope, too friggin bad, get better hardware.

Taken out of context, this statement suggests you believe that
x86-based laptops should not be allowed to suspend automatically when
their lids are closed, and that everybody should replace their
x86-based laptops with something better.

Is that really what you mean?

Alan Stern

Re: [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Sat, 29 May 2010, Peter Zijlstra wrote:

> Correct, I strongly oppose using suspend. Not running runnable tasks is
> not a sane solution.
> 
> If current hardware can't cope, too friggin bad, get better hardware.

Taken out of context, this statement suggests you believe that
x86-based laptops should not be allowed to suspend automatically when
their lids are closed, and that everybody should replace their
x86-based laptops with something better.

Is that really what you mean?

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Here is an attempt to satisfy everyone as much as possible.  But first
> an explicit disclaimer: When I say "suspend", I mean it as in
> "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode.
>
> In place of in-kernel suspend blockers, there will be a new type of QoS
> constraint -- call it QOS_EVENTUALLY.  It's a very weak constraint,
> compatible with all cpuidle modes in which runnable threads are allowed
> to run (which is all of them), but not compatible with suspend.
>
> The Android people want debugging and accountability.  So in the most
> objectionable part of this proposal, we add a new way of registering
> QoS constraints: monitored constraints.  The "monitored" implies that:
>
>        The constraint has a name, which can be used for debugging
>        and accounting;
>
>        The kernel maintains statistics on the constraint's use and
>        makes them available to userspace; and

The name/statistics could obviously be gated by CONFIG_QOS_STATS or
the like -- we'd want such a thing in our world and others may want to
enable it to debug other situations, but the default could easily
remain "no overhead".

>
>        The PM core is notified whenever the number of active monitored
>        constraints drops to 0.
>
> There is no /sys/power/policy file.  In place of opportunistic suspend,
> we have "QoS-based suspend".  This is initiated by userspace writing
> "qos" to /sys/power/state, and it is very much like suspend-to-RAM.
> However a QoS-based suspend fails immediately if there are any active
> normal QoS constraints incompatible with system suspend, in other
> words, any constraints requiring a throughput > 0 or an interrupt
> latency shorter than the time required for a suspend-to-RAM/resume
> cycle.
>
> If no such constraints are active, the QoS-based suspend blocks in an
> interruptible wait until the number of active QOS_EVENTUALLY
> constraints drops to 0.  When that happens, it carries out a normal
> suspend-to-RAM -- except that it checks along the way to make sure that
> no new QoS constraints are activated while the suspend is in progress.
> If they are, the PM core backs out and fails the QoS-based suspend.
>
> Userspace suspend blockers don't exist at all, as far as the kernel is
> concerned.  In their place, the Android runs a power-manager program
> that receives IPC requests from other processes when they need to
> prevent the system from suspending or allow it to suspend.  The power
> manager's main loop looks like this:
>
>        for (;;) {
>                while (any IPC requests remain)
>                        handle them;
>                if (any processes need to prevent suspend)
>                        sleep;
>                else
>                        write "qos" to /sys/power/state;
>        }

The issue with this approach is that if userspace wants to suspend
while a driver is holding a QOS_EVENTUALLY constraint, it's basically
going to spin constantly writing "qos" and failing.

Could we have write(powerstate_fd, "qos",3) block until all
QOS_EVENTUALLY constraints are lifted or the system successfully
suspends and resumes or a signal arrives?

> The idea is that receipt of a new IPC request will cause a signal to be
> sent, interrupting the sleep or the "qos" write.

Alternatively (to ipc), we could have a driver provide the same
suspendblock style interface to userspace and maps it to qos
constraints.  If it's something we maintain out-of-tree, no worries.
The kernel side api is the bit that's the headache to maintain
multiple versions of drivers with and without, after all.

> There remains a question as to which kernel drivers should create
> monitored QOS_EVENTUALLY constraints.  Perhaps userspace could be
> allowed to specify this (I don't know how).  In any case, this is a
> relatively minor point.
>
> The advantages of this scheme are that this does everything the Android
> people need, and it does it in a way that's entirely compatible with
> pure QoS/cpuidle-based power management.  It even starts along the path
> of making suspend-to-RAM just another kind of dynamic power state.
>
> If people such as Peter still want to complain that using
> suspend-to-RAM in Android phones isn't a good way to do power
> management, that's okay -- it's the designers' decision to program
> their phones the way they want.  At least the kernel can give them the
> ability to do so in a way that doesn't compromise everybody else.

I'm sure Arve will weigh in on this later, but from what I can see it
certainly seems like this model provides us with the functionality
we're looking for, provided the issue with
spinning-while-waiting-for-drivers-to-release-constraints is sorted
out.

Brian