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

[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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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:
> 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:
> 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)

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

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

[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: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)

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

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

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

[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: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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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: [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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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, 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Pavel Machek]

Hi!

(ok, so I'm little late to the party).

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

We'll need ACPI extensions, then (or very conservative
drivers). suspend blockers do *not* help here.

> since the latency is in the range of seconds, you'll never have a low 
> enough wakeup rate to hit it.

I did 'sleepy linux' prototype on PC, and yes I was able to get to
'once in 5 seconds' wakeup rate... good enough...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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: [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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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: [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)

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

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

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

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

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

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

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

[David Brownell]

> > > If "suspend" is the thing we are used to via
> /sys/power/state then the
> > > race will persist forever except for the suspend blocker workaround,

True, because device wakeups are enabled
by device.driver.suspend() methods, which are
invoked towards the end of the activities
triggered by writing /sys/power/state.

Now, there can be platforms (mostly embedded)
where the drivers adopt a policy that not only
do they keep their devices in as low a power
state as practical at all times, but they also
keep the hardware wakeup mechanisms enabled (they
may be needed to kick the hardware out of those
low power states) ...  That is, suspend() might be
superfluous (a NOP) in those platforms' drivers.

Such platforms might also be (non-ACPI) ones
where idle C-states and S3/STR have the same
power consumption ... but that would be a
platform-specific issue, not a generic thing
which all Linux implementations could rely on.

- Dave

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

[Alan Stern]

On Tue, 1 Jun 2010, Neil Brown wrote:

> > With wakeup events the problem isn't so bad.  Wakeup events are always
> > noticed, and if the system is designed properly they will either abort
> > a suspend-in-progress or else cause the system to resume as soon as the
> > suspend is complete.  (Linux is not yet properly designed in this
> > sense.)
> 
> This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
> processed by the driver just before suspend may not get all the way out to
> it's final destination (possibly in meat-space) until after some other event
> wakes the device.  It is not possible to guarantee full delivery of a wakeup
> event with Linux in its current state.  This is a bug.

That wasn't what I meant.  An important requirement is that a wakeup 
event received after the device has been suspended, but before the 
system suspend is complete, should cause the system suspend to abort.  
This is one of the things suspend blockers were meant to help with.  In 
theory it should already work correctly -- but it doesn't.  That's a 
real bug.

The other things you're talking about aren't really bugs.  That is,
they are things which the kernel _ought_ to do but it wasn't _intended_
to do.  They are misfeatures: failures of design, not failures of 
execution.

> I don't think I'm missing that.  Wakeup events are the only events of
> interest.  But wakeup events are more than just low-level hardware events.
> They are also the virtual events that are a direct consequence of the
> original hardware event.

This is a matter of semantics and it is highly debatable.

> A UART asserts 'data ready' which is routed to an IO interrupt line that
> wakes the device.  This is a wakeup event.

Yes.

> So are the bits that appear on the data line which represent the data
> So are the characters that appear on the serial port
> So is the "here is a message from the GSM processor" event
> So is the "there is a new TXT message" event
> So is the "'beep beep beep' out the speaker" event

None of those things can cause the system to wake up after it is
suspended.  Indeed, they can't happen at all if the CPU isn't running
(unless the GSM processor runs autonomously -- let's ignore such
details).  Hence it makes little sense to call them "wakeup" events.

> All these events are wakeup events, and should abort or instant-resume the
> system.  Currently only the first can be guaranteed to do this (... and maybe
> the second, depending on the details of the implementation).
> suspend-blocks effectively pass a lock from one event to the next to ensure
> that all of these event block the suspend.  There are various other ways to
> achieve the same thing, and I think it can be done with no significant change
> to the API.  But some how we need to allow all of these events to be
> linked wake-up events, not just the first one.

That's not entirely clear.  Yes, for Android's use case that's what you 
want.  But in other situations maybe you don't.  Consider the example 
of someone who closes the lid of their laptop and throws it in a 
backpack.  The computer should suspend immediately; it shouldn't be 
delayed by these "virtual wakeup" events.

Alan Stern

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

[Rafael J. Wysocki]

On Tuesday 01 June 2010, Alan Stern wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > With wakeup events the problem isn't so bad.  Wakeup events are always
> > > noticed, and if the system is designed properly they will either abort
> > > a suspend-in-progress or else cause the system to resume as soon as the
> > > suspend is complete.  (Linux is not yet properly designed in this
> > > sense.)
> > 
> > This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
> > processed by the driver just before suspend may not get all the way out to
> > it's final destination (possibly in meat-space) until after some other event
> > wakes the device.  It is not possible to guarantee full delivery of a wakeup
> > event with Linux in its current state.  This is a bug.
> 
> That wasn't what I meant.  An important requirement is that a wakeup 
> event received after the device has been suspended, but before the 
> system suspend is complete, should cause the system suspend to abort.  
> This is one of the things suspend blockers were meant to help with.  In 
> theory it should already work correctly -- but it doesn't.  That's a 
> real bug.
> 
> The other things you're talking about aren't really bugs.  That is,
> they are things which the kernel _ought_ to do but it wasn't _intended_
> to do.  They are misfeatures: failures of design, not failures of 
> execution.
> 
> > I don't think I'm missing that.  Wakeup events are the only events of
> > interest.  But wakeup events are more than just low-level hardware events.
> > They are also the virtual events that are a direct consequence of the
> > original hardware event.
> 
> This is a matter of semantics and it is highly debatable.
> 
> > A UART asserts 'data ready' which is routed to an IO interrupt line that
> > wakes the device.  This is a wakeup event.
> 
> Yes.
> 
> > So are the bits that appear on the data line which represent the data
> > So are the characters that appear on the serial port
> > So is the "here is a message from the GSM processor" event
> > So is the "there is a new TXT message" event
> > So is the "'beep beep beep' out the speaker" event
> 
> None of those things can cause the system to wake up after it is
> suspended.  Indeed, they can't happen at all if the CPU isn't running
> (unless the GSM processor runs autonomously -- let's ignore such
> details).  Hence it makes little sense to call them "wakeup" events.
> 
> > All these events are wakeup events, and should abort or instant-resume the
> > system.  Currently only the first can be guaranteed to do this (... and maybe
> > the second, depending on the details of the implementation).
> > suspend-blocks effectively pass a lock from one event to the next to ensure
> > that all of these event block the suspend.  There are various other ways to
> > achieve the same thing, and I think it can be done with no significant change
> > to the API.  But some how we need to allow all of these events to be
> > linked wake-up events, not just the first one.
> 
> That's not entirely clear.  Yes, for Android's use case that's what you 
> want.  But in other situations maybe you don't.  Consider the example 
> of someone who closes the lid of their laptop and throws it in a 
> backpack.  The computer should suspend immediately; it shouldn't be 
> delayed by these "virtual wakeup" events.

BTW, this is an important point.  We've already had some bug reports regarding
such unwanted wakeup events.

Rafael

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

[Neil Brown]

On Tue, 1 Jun 2010 10:47:49 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > With wakeup events the problem isn't so bad.  Wakeup events are always
> > > noticed, and if the system is designed properly they will either abort
> > > a suspend-in-progress or else cause the system to resume as soon as the
> > > suspend is complete.  (Linux is not yet properly designed in this
> > > sense.)
> > 
> > This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
> > processed by the driver just before suspend may not get all the way out to
> > it's final destination (possibly in meat-space) until after some other event
> > wakes the device.  It is not possible to guarantee full delivery of a wakeup
> > event with Linux in its current state.  This is a bug.
> 
> That wasn't what I meant.  An important requirement is that a wakeup 
> event received after the device has been suspended, but before the 
> system suspend is complete, should cause the system suspend to abort.  
> This is one of the things suspend blockers were meant to help with.  In 
> theory it should already work correctly -- but it doesn't.  That's a 
> real bug.
> 
> The other things you're talking about aren't really bugs.  That is,
> they are things which the kernel _ought_ to do but it wasn't _intended_
> to do.  They are misfeatures: failures of design, not failures of 
> execution.

A fairly subtle distinction, but I can accept it.  We are working with a
design failure.
But when a design failure results in a feature not being usable in a
race-free way, I would still call that failure of design a bug - a bug in the
design.

> 
> > I don't think I'm missing that.  Wakeup events are the only events of
> > interest.  But wakeup events are more than just low-level hardware events.
> > They are also the virtual events that are a direct consequence of the
> > original hardware event.
> 
> This is a matter of semantics and it is highly debatable.
> 
> > A UART asserts 'data ready' which is routed to an IO interrupt line that
> > wakes the device.  This is a wakeup event.
> 
> Yes.
> 
> > So are the bits that appear on the data line which represent the data
> > So are the characters that appear on the serial port
> > So is the "here is a message from the GSM processor" event
> > So is the "there is a new TXT message" event
> > So is the "'beep beep beep' out the speaker" event
> 
> None of those things can cause the system to wake up after it is
> suspended.  Indeed, they can't happen at all if the CPU isn't running
> (unless the GSM processor runs autonomously -- let's ignore such
> details).  Hence it makes little sense to call them "wakeup" events.
> 

I think we are seeing this very differently.  In my mind these are in one
sense all the same event, just represented in different ways.

One of the reasons that we have an OS is to support levels of abstraction.
A disk drives stores sectors, but I want to store files
A monitor displays pixels, but I want to display text
A network sends packets, but I want to send Email.

The OS (including but not only the kernel) handles the conversion.
It is still my Email that is going out over the network even though the
network card has no concept of 'email'.

Similarly the event of importance above in the notification that a TXT has
arrived.
At the lowest level, it appears as 'data-ready' on a UART.  At the highest
level is it sound-waves in the air.  But it is the same event.  And the role
of the OS is to allow me to treat it all as one event - one abstract concept.

Obviously the involvement of the kernel ends when the event reaches or
crosses the boundary to user-space, and user-space must be responsible for
taking it to the boundary to meat-space.
But the kernel needs to ensure that this holistic wake-up event can be
handled without racing with a suspend request.
If you just protect the lowest level representation of the event, but don't
allow the higher level representations to be protected, then it is a bit like
a filesystem that requires you to send SCSI commands to the disk drive if you
want to be sure your data is safe.

> > All these events are wakeup events, and should abort or instant-resume the
> > system.  Currently only the first can be guaranteed to do this (... and maybe
> > the second, depending on the details of the implementation).
> > suspend-blocks effectively pass a lock from one event to the next to ensure
> > that all of these event block the suspend.  There are various other ways to
> > achieve the same thing, and I think it can be done with no significant change
> > to the API.  But some how we need to allow all of these events to be
> > linked wake-up events, not just the first one.
> 
> That's not entirely clear.  Yes, for Android's use case that's what you 
> want.  But in other situations maybe you don't.  Consider the example 
> of someone who closes the lid of their laptop and throws it in a 
> backpack.  The computer should suspend immediately; it shouldn't be 
> delayed by these "virtual wakeup" events.

Completely agree.  Old behaviour must remain unchanged, new behaviour must be
explicitly requested.

At each level, it must be explicitly stated that an event is to be treated
like a wake-up event.  I believe that is already the case in drivers - they
need to explicitly configure the interrupt to cause a wake-from-suspend.

I've considered several possibilities for how user-space could explicitly say
that events are wake-event.  My current favourite is to use fcntl(F_SETOWN)
to request a signal be sent to the process that is initiating the suspend
when the relevant events are ready to be consumed by user-space.
This would work for events that come through the input system (button press)
or through the network, or rtc alarm events.  I suspect all potential
wake-events could be made to use this scheme, but I don't have an exhausting
list at present.

So a suspend request waits just long enough to close any race, checks if
there are signals pending, and proceeds with the suspend if there aren't.
The "just long enough" is a little tricky to measure, though the in-kernel
part of suspend-blockers presumably can be used to get that right.

If the suspending process hasn't requested the delivery of these signals, the
suspend will possibly pause to make sure that any events-in-transit in the
kernel have reached their in-kernel destination (milliseconds at most) and
then proceed with the suspend as normal.

So yes, there are different use cases and we should support all of them,
both "I shut the lid and my laptop really stays asleep" and "I never miss a
TXT because my phone went to sleep at a bad time".  The process that
initiates the suspend has a role in choosing what can wake it up.

Thanks,
NeilBrown

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

[Rafael J. Wysocki]

On Wednesday 02 June 2010, Neil Brown wrote:
> On Tue, 1 Jun 2010 10:47:49 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
...
> So yes, there are different use cases and we should support all of them,
> both "I shut the lid and my laptop really stays asleep" and "I never miss a
> TXT because my phone went to sleep at a bad time".  The process that
> initiates the suspend has a role in choosing what can wake it up.

You'd need to add some all new infrastructure for that, because right now
only hardware wakeup signals are regarded as (system) wakeup events
(they are either interrupts or things like PCI PMEs, possibly translated to
some platform signals like GPIOs or something).

I think I know how to prevent these hardware wakeup events from being lost
(such that the entire suspend will be aborted if one of them happens
during suspend), but for the handling of more generally defined wakeup
events we'd need to provide user space with information on what wakeup events
are available and how to enable and disable them, among other things.

Rafael

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: [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
_______________________________________________
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)

[Alan Stern]

On Sat, 29 May 2010, Brian Swetland wrote:

> On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@rowland.harvard.edu> wrote:

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

No, no.  If userspace wants to suspend while a driver is holding a 
QOS_EVENTUALLY constraint, the user process blocks in an interruptible 
wait state as described in the first paragraph above.

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

That is basically what I originally wrote.

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

Yep.  The idea is that all this userspace-oriented part should be
invisible to the vanilla kernel.

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

I'm more concerned about how the other kernel developers will react.

Alan Stern

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

[Alan Cox]

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

Yes - and you can then use alarm() or similar to do timeouts (or write
the timeout to the fd ?)

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

[Brian Swetland]

On Sat, May 29, 2010 at 8:03 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sat, 29 May 2010, Brian Swetland wrote:
>> On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > 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.
>>
>> 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.
>
> No, no.  If userspace wants to suspend while a driver is holding a
> QOS_EVENTUALLY constraint, the user process blocks in an interruptible
> wait state as described in the first paragraph above.

Oops -- I misread the first paragraph.  The behavior you described is
indeed what I would want.

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)

[Rafael J. Wysocki]

On Saturday 29 May 2010, Alan Stern wrote:
> 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.

This sounds reasonable to me.

Rafael

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

[Arve Hjønnevåg]

On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 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.
>
This sound just like another API rename. It will work, but given that
suspend blockers was the name least objectionable last time around,
I'm not sure what this would solve.

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

Why do you want to tie it to a specific state?

> However a QoS-based suspend fails immediately if there are any active

Fail or block? Your next paragraph said that it blocks for
QOS_EVENTUALLY, but if normal constraints fail, you are still stuck in
a retry loop.

> 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

How do you implement this?

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

What happen if the signal is right before (or even right after)
calling write "qos". How does the signal handler stop the 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
>
>



-- 
Arve Hjønnevåg

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

[Nigel Cunningham]

Hi.

I like the sound of this much better too, but...

On 30/05/10 08:13, Arve Hjønnevåg wrote:
> On Sat, May 29, 2010 at 7:10 AM, Alan Stern<stern@rowland.harvard.edu>  wrote:
>> 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.
>
> Why do you want to tie it to a specific state?

I do agree here. I would suggest that all /sys/power/state possibilities 
should have a qos- equivalent. You might not want to use any or all of 
them, but they should be available.

Regards,

Nigel

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

[Alan Stern]

On Sat, 29 May 2010, Arve Hjønnevåg wrote:

> > 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.
> >
> This sound just like another API rename. It will work, but given that
> suspend blockers was the name least objectionable last time around,
> I'm not sure what this would solve.

It's not just a rename.  By changing this into a QoS constraint, we 
make it more generally useful.  Instead of standing on its own, it 
becomes part of the PM-QOS framework.

> > 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.
> 
> Why do you want to tie it to a specific state?

I don't.  I suggested making it a veriant of suspend-to-RAM merely
because that's what you were using.  But Nigel's suggestion of having
"qos" variants of all the different suspend states makes sense.

> > However a QoS-based suspend fails immediately if there are any active
> 
> Fail or block? Your next paragraph said that it blocks for
> QOS_EVENTUALLY, but if normal constraints fail, you are still stuck in
> a retry loop.

Normal (i.e., non QOS_EVENTUALLY) constraints aren't part of the
Android use case, so it wasn't clear how they should be treated.  On
further thought, it probably makes more sense to block for them too
instead of failing immediately.

> > 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
> 
> How do you implement this?

I'm not sure what you mean.  The same way you implement any 
interruptible wait.

> >        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.
> 
> What happen if the signal is right before (or even right after)
> calling write "qos". How does the signal handler stop the write?

You're right, this is a serious problem.  The process would have to
give the kernel a signal mask to be used during the wait, as in ppoll
or pselect.  There ought to be a way to do this or something
equivalent.

Alan Stern

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

[Alan Stern]

On Sat, 29 May 2010, Alan Stern wrote:

> On Sat, 29 May 2010, Arve Hjønnevåg wrote:

> > >        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.
> > 
> > What happen if the signal is right before (or even right after)
> > calling write "qos". How does the signal handler stop the write?
> 
> You're right, this is a serious problem.  The process would have to
> give the kernel a signal mask to be used during the wait, as in ppoll
> or pselect.  There ought to be a way to do this or something
> equivalent.

Okay, here's a possible solution:

	char arg[20];

	signal_handler()
	{
		arg[0] = 0;
	}


	In the main loop:

	...
	mask signals;
	if (we decide to start a QoS-based suspend) {
		strcpy(arg, "qos");
		unmask signals;
		write arg to /sys/power/state;
	}

It's hacky but I think it will work.

A more straightforward approach is to give processes the ability to 
register their own QoS constraints.  This could be done via a custom 
driver as Brian suggested or by adding a new system call as Alan Cox 
suggested.  Then the power manager could be split into two threads, one 
of which handles IPC requests and manages QoS constraints, while the 
other repeatedly attempts to initiate QoS-based suspends.

Alan Stern

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

[Arve Hjønnevåg]

2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> On Sat, 29 May 2010, Arve Hjønnevåg wrote:
>
>> > 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.
>> >
>> This sound just like another API rename. It will work, but given that
>> suspend blockers was the name least objectionable last time around,
>> I'm not sure what this would solve.
>
> It's not just a rename.  By changing this into a QoS constraint, we
> make it more generally useful.  Instead of standing on its own, it
> becomes part of the PM-QOS framework.
>

We cannot use the existing pm-qos framework. It is not safe to call
from atomic context. Also, it does not have any state constraints, so
it iterates over every registered constraint each time one of them
changes. Nor does is currently provide any stats for debugging.

The original wakelock patchset supported a wakelock type so it could
be used to block more then suspend, but I had to remove this because
it "overlapped" with pm-qos. So, yes I do consider this just another
rename.

>> > 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.
>>
>> Why do you want to tie it to a specific state?
>
> I don't.  I suggested making it a veriant of suspend-to-RAM merely
> because that's what you were using.  But Nigel's suggestion of having
> "qos" variants of all the different suspend states makes sense.
>
>> > However a QoS-based suspend fails immediately if there are any active
>>
>> Fail or block? Your next paragraph said that it blocks for
>> QOS_EVENTUALLY, but if normal constraints fail, you are still stuck in
>> a retry loop.
>
> Normal (i.e., non QOS_EVENTUALLY) constraints aren't part of the
> Android use case, so it wasn't clear how they should be treated.  On
> further thought, it probably makes more sense to block for them too
> instead of failing immediately.
>
>> > 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
>>
>> How do you implement this?
>
> I'm not sure what you mean.  The same way you implement any
> interruptible wait.
>

I mean what should it wait on so that it gets interrupted by a
userspace ipc call. I guess you want to send a signal in addition to
the ipc. I still don't know why you want to do it this way though. It
seems much simpler to just return immedeately and allow the same
thread to cancel the request with another write.

>> >        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.
>>
>> What happen if the signal is right before (or even right after)
>> calling write "qos". How does the signal handler stop the write?
>
> You're right, this is a serious problem.  The process would have to
> give the kernel a signal mask to be used during the wait, as in ppoll
> or pselect.  There ought to be a way to do this or something
> equivalent.
>
> Alan Stern
>
>



-- 
Arve Hjønnevåg

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

[Alan Stern]

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

> >> This sound just like another API rename. It will work, but given that
> >> suspend blockers was the name least objectionable last time around,
> >> I'm not sure what this would solve.
> >
> > It's not just a rename.  By changing this into a QoS constraint, we
> > make it more generally useful.  Instead of standing on its own, it
> > becomes part of the PM-QOS framework.
> >
> 
> We cannot use the existing pm-qos framework. It is not safe to call
> from atomic context. Also, it does not have any state constraints, so
> it iterates over every registered constraint each time one of them
> changes. Nor does is currently provide any stats for debugging.
> 
> The original wakelock patchset supported a wakelock type so it could
> be used to block more then suspend, but I had to remove this because
> it "overlapped" with pm-qos. So, yes I do consider this just another
> rename.

You're missing the point.  The fact that wakelocks "overlapped" with 
pm-qos is _good_.  It means that you can implement what you need within 
the pm-qos framework, if you expand the framework's capabilities (add 
the ability to do things in atomic context, add the ability to collect 
stats for debugging, etc.).

Maybe this would require redesigning a large part of pm-qos.  I'm not
very familiar with it, so I don't know what would be involved.  Still,
it seems like a reasonable approach, given what you need to accomplish.

> >> > If no such constraints are active, the QoS-based suspend blocks in an
> >> > interruptible wait until the number of active QOS_EVENTUALLY
> >>
> >> How do you implement this?
> >
> > I'm not sure what you mean.  The same way you implement any
> > interruptible wait.
> >
> 
> I mean what should it wait on so that it gets interrupted by a
> userspace ipc call. I guess you want to send a signal in addition to
> the ipc.

If the IPC is carried out over a Unix socket, you can get SIGIO 
signals for free.  But yes, if necessary the client could send a signal 
along with its request.

> I still don't know why you want to do it this way though. It
> seems much simpler to just return immedeately and allow the same
> thread to cancel the request with another write.

I suggested doing it this way because it is as close as possible to the 
existing API.  A two-step submit/cancel approach would be a larger 
change -- but it certainly would work.  I have no objection to it.

The main idea behind this part of the proposal was to get rid of the
new userspace-suspend-blocker API (along with /sys/power/policy, which
Pavel objects to).  Equivalent functionality can be achieved by making
only small changes to the existing /sys/power/state interface (and
perhaps somewhat larger changes to the userspace daemon); the exact 
details of the changes aren't critical.

Alan Stern

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

[Rafael J. Wysocki]

On Monday 31 May 2010, Arve Hjønnevåg wrote:
> 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> >
> >> > 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.
> >> >
> >> This sound just like another API rename. It will work, but given that
> >> suspend blockers was the name least objectionable last time around,
> >> I'm not sure what this would solve.
> >
> > It's not just a rename.  By changing this into a QoS constraint, we
> > make it more generally useful.  Instead of standing on its own, it
> > becomes part of the PM-QOS framework.
> >
> 
> We cannot use the existing pm-qos framework. It is not safe to call
> from atomic context.

We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
PM QoS update fix that?

> Also, it does not have any state constraints, so it iterates over every
> registered constraint each time one of them changes.

That's fixable IMO.

> Nor does is currently provide any stats for debugging.

That's why Alan is proposing to add that.

> The original wakelock patchset supported a wakelock type so it could
> be used to block more then suspend, but I had to remove this because
> it "overlapped" with pm-qos. So, yes I do consider this just another
> rename.

It's an extension of an existing framework rather than an addition of a new
one, with entirely new API and so on.  Extending existing APIs is much
preferred to adding new ones, in general.

Rafael

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

[mark gross]

On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > >
> > >> > 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.
> > >> >
> > >> This sound just like another API rename. It will work, but given that
> > >> suspend blockers was the name least objectionable last time around,
> > >> I'm not sure what this would solve.
> > >
> > > It's not just a rename.  By changing this into a QoS constraint, we
> > > make it more generally useful.  Instead of standing on its own, it
> > > becomes part of the PM-QOS framework.
> > >
> > 
> > We cannot use the existing pm-qos framework. It is not safe to call
> > from atomic context.
> 
> We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> PM QoS update fix that?
>

I'm pretty sure it can be called in atomic context, and if its not I'm
sure we can fix that.  It can be called in atomic context.  I don't
think it was ever a problem to call it in atomic context.  The problem it
had was that crappy list of string compares.  Thats been fixed.

--mgross
 
> > Also, it does not have any state constraints, so it iterates over every
> > registered constraint each time one of them changes.
> 
> That's fixable IMO.
> 
> > Nor does is currently provide any stats for debugging.
> 
> That's why Alan is proposing to add that.
> 
> > The original wakelock patchset supported a wakelock type so it could
> > be used to block more then suspend, but I had to remove this because
> > it "overlapped" with pm-qos. So, yes I do consider this just another
> > rename.
> 
> It's an extension of an existing framework rather than an addition of a new
> one, with entirely new API and so on.  Extending existing APIs is much
> preferred to adding new ones, in general.
> 
> Rafael

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

[Florian Mickler]

On Mon, 31 May 2010 16:26:17 -0700
mark gross <640e9920@gmail.com> wrote:

> On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > > 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > > >
> > > >> > 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.
> > > >> >
> > > >> This sound just like another API rename. It will work, but given that
> > > >> suspend blockers was the name least objectionable last time around,
> > > >> I'm not sure what this would solve.
> > > >
> > > > It's not just a rename.  By changing this into a QoS constraint, we
> > > > make it more generally useful.  Instead of standing on its own, it
> > > > becomes part of the PM-QOS framework.
> > > >
> > > 
> > > We cannot use the existing pm-qos framework. It is not safe to call
> > > from atomic context.
> > 
> > We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> > PM QoS update fix that?
> >
> 
> I'm pretty sure it can be called in atomic context, and if its not I'm
> sure we can fix that.  It can be called in atomic context.  I don't
> think it was ever a problem to call it in atomic context.  The problem it
> had was that crappy list of string compares.  Thats been fixed.
> 
> --mgross
>  

Well, the register call uses kzalloc. Apart from that I
think we're good. 

The outstanding list traversals can be fixed also. (see below)

Cheers,
Flo

>From 66fdd76f8cc4be722dba3859ddadfe07e7a4b755 Mon Sep 17 00:00:00 2001
From: Florian Mickler <florian@mickler.org>
Date: Tue, 1 Jun 2010 09:04:26 +0200
Subject: [PATCH] pm_qos: remove unnecessary list-traversal

The new extreme_value is only depending on the old extreme_value and
the changing value.

Signed-off-by: Florian Mickler <florian@mickler.org>
---
 kernel/pm_qos_params.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/kernel/pm_qos_params.c b/kernel/pm_qos_params.c
index f42d3f7..6618e2c 100644
--- a/kernel/pm_qos_params.c
+++ b/kernel/pm_qos_params.c
@@ -136,6 +136,16 @@ static s32 min_compare(s32 v1, s32 v2)
 }
 
 
+static void update_target_val(int pm_qos_class, s32 val)
+{
+	s32 extreme_value;
+	s32 new_value;
+	extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+	new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
+	if (extreme_value != new_value)
+		atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+
 static void update_target(int pm_qos_class)
 {
 	s32 extreme_value;
@@ -227,8 +237,8 @@ struct pm_qos_request_list *pm_qos_add_request(int pm_qos_class, s32 value)
 		spin_lock_irqsave(&pm_qos_lock, flags);
 		list_add(&dep->list,
 			&pm_qos_array[pm_qos_class]->requests.list);
+		update_target_val(pm_qos_class,dep->value);
 		spin_unlock_irqrestore(&pm_qos_lock, flags);
-		update_target(pm_qos_class);
 	}
 
 	return dep;
@@ -249,23 +259,21 @@ void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
 		s32 new_value)
 {
 	unsigned long flags;
-	int pending_update = 0;
 	s32 temp;
 
 	if (pm_qos_req) { /*guard against callers passing in null */
+		int target = pm_qos_req->pm_qos_class;
 		spin_lock_irqsave(&pm_qos_lock, flags);
 		if (new_value == PM_QOS_DEFAULT_VALUE)
-			temp = pm_qos_array[pm_qos_req->pm_qos_class]->default_value;
+			temp = pm_qos_array[target]->default_value;
 		else
 			temp = new_value;
 
 		if (temp != pm_qos_req->value) {
-			pending_update = 1;
 			pm_qos_req->value = temp;
+			update_target_val(target,temp);
 		}
 		spin_unlock_irqrestore(&pm_qos_lock, flags);
-		if (pending_update)
-			update_target(pm_qos_req->pm_qos_class);
 	}
 }
 EXPORT_SYMBOL_GPL(pm_qos_update_request);
-- 
1.7.1

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

[mark gross]

On Mon, May 31, 2010 at 04:26:17PM -0700, mark gross wrote:
> On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > > 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > > >
> > > >> > 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.
> > > >> >
> > > >> This sound just like another API rename. It will work, but given that
> > > >> suspend blockers was the name least objectionable last time around,
> > > >> I'm not sure what this would solve.
> > > >
> > > > It's not just a rename.  By changing this into a QoS constraint, we
> > > > make it more generally useful.  Instead of standing on its own, it
> > > > becomes part of the PM-QOS framework.
> > > >
> > > 
> > > We cannot use the existing pm-qos framework. It is not safe to call
> > > from atomic context.
> > 
> > We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> > PM QoS update fix that?
> >
> 
> I'm pretty sure it can be called in atomic context, and if its not I'm
> sure we can fix that.  It can be called in atomic context.  I don't
> think it was ever a problem to call it in atomic context.  The problem it
> had was that crappy list of string compares.  Thats been fixed.
> 

um, the notifiers that are currently used may not be cool in atomic
context :(

--mgross



> --mgross
>  
> > > Also, it does not have any state constraints, so it iterates over every
> > > registered constraint each time one of them changes.
> > 
> > That's fixable IMO.
> > 
> > > Nor does is currently provide any stats for debugging.
> > 
> > That's why Alan is proposing to add that.
> > 
> > > The original wakelock patchset supported a wakelock type so it could
> > > be used to block more then suspend, but I had to remove this because
> > > it "overlapped" with pm-qos. So, yes I do consider this just another
> > > rename.
> > 
> > It's an extension of an existing framework rather than an addition of a new
> > one, with entirely new API and so on.  Extending existing APIs is much
> > preferred to adding new ones, in general.
> > 
> > Rafael

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

[mark gross]

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> On Mon, 31 May 2010 16:26:17 -0700
> mark gross <640e9920@gmail.com> wrote:
> 
> > On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> > > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > > > 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > > > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > > > >
> > > > >> > 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.
> > > > >> >
> > > > >> This sound just like another API rename. It will work, but given that
> > > > >> suspend blockers was the name least objectionable last time around,
> > > > >> I'm not sure what this would solve.
> > > > >
> > > > > It's not just a rename.  By changing this into a QoS constraint, we
> > > > > make it more generally useful.  Instead of standing on its own, it
> > > > > becomes part of the PM-QOS framework.
> > > > >
> > > > 
> > > > We cannot use the existing pm-qos framework. It is not safe to call
> > > > from atomic context.
> > > 
> > > We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> > > PM QoS update fix that?
> > >
> > 
> > I'm pretty sure it can be called in atomic context, and if its not I'm
> > sure we can fix that.  It can be called in atomic context.  I don't
> > think it was ever a problem to call it in atomic context.  The problem it
> > had was that crappy list of string compares.  Thats been fixed.
> > 
> > --mgross
> >  
> 
> Well, the register call uses kzalloc. Apart from that I
> think we're good. 
> 
> The outstanding list traversals can be fixed also. (see below)
> 
> Cheers,
> Flo
> 
> From 66fdd76f8cc4be722dba3859ddadfe07e7a4b755 Mon Sep 17 00:00:00 2001
> From: Florian Mickler <florian@mickler.org>
> Date: Tue, 1 Jun 2010 09:04:26 +0200
> Subject: [PATCH] pm_qos: remove unnecessary list-traversal
> 
> The new extreme_value is only depending on the old extreme_value and
> the changing value.
> 
> Signed-off-by: Florian Mickler <florian@mickler.org>
> ---
>  kernel/pm_qos_params.c |   20 ++++++++++++++------
>  1 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/pm_qos_params.c b/kernel/pm_qos_params.c
> index f42d3f7..6618e2c 100644
> --- a/kernel/pm_qos_params.c
> +++ b/kernel/pm_qos_params.c
> @@ -136,6 +136,16 @@ static s32 min_compare(s32 v1, s32 v2)
>  }
>  
>  
> +static void update_target_val(int pm_qos_class, s32 val)
> +{
> +	s32 extreme_value;
> +	s32 new_value;
> +	extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> +	new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> +	if (extreme_value != new_value)
> +		atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> +}
> +

Only works 1/2 the time, but I like the idea!  
It fails to get the righ answer when constraints are reduced.  But, this
idea is a good improvement i'll roll into the next pm_qos update!

thanks!

--mgross

>  static void update_target(int pm_qos_class)
>  {
>  	s32 extreme_value;
> @@ -227,8 +237,8 @@ struct pm_qos_request_list *pm_qos_add_request(int pm_qos_class, s32 value)
>  		spin_lock_irqsave(&pm_qos_lock, flags);
>  		list_add(&dep->list,
>  			&pm_qos_array[pm_qos_class]->requests.list);
> +		update_target_val(pm_qos_class,dep->value);
>  		spin_unlock_irqrestore(&pm_qos_lock, flags);
> -		update_target(pm_qos_class);
>  	}
>  
>  	return dep;
> @@ -249,23 +259,21 @@ void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
>  		s32 new_value)
>  {
>  	unsigned long flags;
> -	int pending_update = 0;
>  	s32 temp;
>  
>  	if (pm_qos_req) { /*guard against callers passing in null */
> +		int target = pm_qos_req->pm_qos_class;
>  		spin_lock_irqsave(&pm_qos_lock, flags);
>  		if (new_value == PM_QOS_DEFAULT_VALUE)
> -			temp = pm_qos_array[pm_qos_req->pm_qos_class]->default_value;
> +			temp = pm_qos_array[target]->default_value;
>  		else
>  			temp = new_value;
>  
>  		if (temp != pm_qos_req->value) {
> -			pending_update = 1;
>  			pm_qos_req->value = temp;
> +			update_target_val(target,temp);
>  		}
>  		spin_unlock_irqrestore(&pm_qos_lock, flags);
> -		if (pending_update)
> -			update_target(pm_qos_req->pm_qos_class);
>  	}
>  }
>  EXPORT_SYMBOL_GPL(pm_qos_update_request);
> -- 
> 1.7.1
> 

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

[Florian Mickler]

On Tue, 1 Jun 2010 07:05:19 -0700
mark gross <640e9920@gmail.com> wrote:

> 
> Only works 1/2 the time, but I like the idea!  
> It fails to get the righ answer when constraints are reduced.  But, this
> idea is a good improvement i'll roll into the next pm_qos update!
> 
> thanks!
> 
> --mgross

outch. shure. i had the binary block/unblock case in my mind. (where
the comparitor would be just the logical &&)

cheers,
Flo

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

[Florian Mickler]

On Tue, 1 Jun 2010 22:00:35 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Tue, 1 Jun 2010 07:05:19 -0700
> mark gross <640e9920@gmail.com> wrote:
> 
> > 
> > Only works 1/2 the time, but I like the idea!  
> > It fails to get the righ answer when constraints are reduced.  But, this
> > idea is a good improvement i'll roll into the next pm_qos update!
> > 
> > thanks!
> > 
> > --mgross
> 
> outch. shure. i had the binary block/unblock case in my mind. (where
> the comparitor would be just the logical &&)

And even there it wouldn't work in general. What about keeping the list
sorted? (Or using the rbtree implementation). Well, I'm getting some
sleep and tomorrow I will think about it some more. 

> cheers,
> Flo
> 

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

[Arve Hjønnevåg]

On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
...
>> +static void update_target_val(int pm_qos_class, s32 val)
>> +{
>> +     s32 extreme_value;
>> +     s32 new_value;
>> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
>> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
>> +     if (extreme_value != new_value)
>> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
>> +}
>> +
>
> Only works 1/2 the time, but I like the idea!
> It fails to get the righ answer when constraints are reduced.  But, this
> idea is a good improvement i'll roll into the next pm_qos update!
>

I think it would be a better idea to track your constraints with a
sorted data structure. That way you can to better than O(n) for both
directions. If you have a lot of constraints with the same value, it
may even be worthwhile to have a two stage structure where for
instance you use a rbtree for the unique values and list for identical
constraints.

-- 
Arve Hjønnevåg

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

[mark gross]

On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> ...
> >> +static void update_target_val(int pm_qos_class, s32 val)
> >> +{
> >> +     s32 extreme_value;
> >> +     s32 new_value;
> >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> >> +     if (extreme_value != new_value)
> >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> >> +}
> >> +
> >
> > Only works 1/2 the time, but I like the idea!
> > It fails to get the righ answer when constraints are reduced.  But, this
> > idea is a good improvement i'll roll into the next pm_qos update!
> >
> 
> I think it would be a better idea to track your constraints with a
> sorted data structure. That way you can to better than O(n) for both
> directions. If you have a lot of constraints with the same value, it
> may even be worthwhile to have a two stage structure where for
> instance you use a rbtree for the unique values and list for identical
> constraints.

I don't agree, we went through this tree vrs list discussion a few times
before in other areas of the kernel.  Wherever the list tended to be
short, a simple list wins.  However; we can try it, after we have some
metrics and stress test cases identified we can measure its effectivenes
against.

--mgross

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

[Arve Hjønnevåg]

2010/6/2 mark gross <640e9920@gmail.com>:
> On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
>> On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
>> > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
>> ...
>> >> +static void update_target_val(int pm_qos_class, s32 val)
>> >> +{
>> >> +     s32 extreme_value;
>> >> +     s32 new_value;
>> >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
>> >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
>> >> +     if (extreme_value != new_value)
>> >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
>> >> +}
>> >> +
>> >
>> > Only works 1/2 the time, but I like the idea!
>> > It fails to get the righ answer when constraints are reduced.  But, this
>> > idea is a good improvement i'll roll into the next pm_qos update!
>> >
>>
>> I think it would be a better idea to track your constraints with a
>> sorted data structure. That way you can to better than O(n) for both
>> directions. If you have a lot of constraints with the same value, it
>> may even be worthwhile to have a two stage structure where for
>> instance you use a rbtree for the unique values and list for identical
>> constraints.
>
> I don't agree, we went through this tree vrs list discussion a few times
> before in other areas of the kernel.  Wherever the list tended to be
> short, a simple list wins.  However; we can try it, after we have some
> metrics and stress test cases identified we can measure its effectivenes
> against.
>

The list is not short. You have all the inactive and active
constraints on the same list. If you change it to a two level list
though, the list of unique values (which is the list you have to walk)
may be short enough for a tree to be overkill.

-- 
Arve Hjønnevåg

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

[Rafael J. Wysocki]

On Wednesday 02 June 2010, mark gross wrote:
> On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> > On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> > > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> > ...
> > >> +static void update_target_val(int pm_qos_class, s32 val)
> > >> +{
> > >> +     s32 extreme_value;
> > >> +     s32 new_value;
> > >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> > >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> > >> +     if (extreme_value != new_value)
> > >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> > >> +}
> > >> +
> > >
> > > Only works 1/2 the time, but I like the idea!
> > > It fails to get the righ answer when constraints are reduced.  But, this
> > > idea is a good improvement i'll roll into the next pm_qos update!
> > >
> > 
> > I think it would be a better idea to track your constraints with a
> > sorted data structure. That way you can to better than O(n) for both
> > directions. If you have a lot of constraints with the same value, it
> > may even be worthwhile to have a two stage structure where for
> > instance you use a rbtree for the unique values and list for identical
> > constraints.
> 
> I don't agree, we went through this tree vrs list discussion a few times
> before in other areas of the kernel.  Wherever the list tended to be
> short, a simple list wins.  However; we can try it, after we have some
> metrics and stress test cases identified we can measure its effectivenes
> against.

How many different values are there to handle?

Rafael

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

[mark gross]

On Thu, Jun 03, 2010 at 12:03:49AM +0200, Rafael J. Wysocki wrote:
> On Wednesday 02 June 2010, mark gross wrote:
> > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> > > On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> > > > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> > > ...
> > > >> +static void update_target_val(int pm_qos_class, s32 val)
> > > >> +{
> > > >> +     s32 extreme_value;
> > > >> +     s32 new_value;
> > > >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> > > >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> > > >> +     if (extreme_value != new_value)
> > > >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> > > >> +}
> > > >> +
> > > >
> > > > Only works 1/2 the time, but I like the idea!
> > > > It fails to get the righ answer when constraints are reduced.  But, this
> > > > idea is a good improvement i'll roll into the next pm_qos update!
> > > >
> > > 
> > > I think it would be a better idea to track your constraints with a
> > > sorted data structure. That way you can to better than O(n) for both
> > > directions. If you have a lot of constraints with the same value, it
> > > may even be worthwhile to have a two stage structure where for
> > > instance you use a rbtree for the unique values and list for identical
> > > constraints.
> > 
> > I don't agree, we went through this tree vrs list discussion a few times
> > before in other areas of the kernel.  Wherever the list tended to be
> > short, a simple list wins.  However; we can try it, after we have some
> > metrics and stress test cases identified we can measure its effectivenes
> > against.
> 
> How many different values are there to handle?
>

for the current pm_qos users its tiny.  I've never heard of more than a
few < 10.  However; for the new "interactive" class to provide suspend
blocker functionality, I expect the number to be up to 20.

but realistically I bet we never get more than 10ish.

One constraint constraint request per module from isr to user mode.
Once in user mode there would be only a few (assuming Android user
space) I think just from the power HAL, input HAL, and the RIL.

Still a pretty small number I don't think we need to worry about scaling
as much as we need to worry about performance.

--mgross 

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

[Rafael J. Wysocki]

On Thursday 03 June 2010, mark gross wrote:
> On Thu, Jun 03, 2010 at 12:03:49AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday 02 June 2010, mark gross wrote:
> > > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> > > > On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> > > > > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> > > > ...
> > > > >> +static void update_target_val(int pm_qos_class, s32 val)
> > > > >> +{
> > > > >> +     s32 extreme_value;
> > > > >> +     s32 new_value;
> > > > >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> > > > >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> > > > >> +     if (extreme_value != new_value)
> > > > >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> > > > >> +}
> > > > >> +
> > > > >
> > > > > Only works 1/2 the time, but I like the idea!
> > > > > It fails to get the righ answer when constraints are reduced.  But, this
> > > > > idea is a good improvement i'll roll into the next pm_qos update!
> > > > >
> > > > 
> > > > I think it would be a better idea to track your constraints with a
> > > > sorted data structure. That way you can to better than O(n) for both
> > > > directions. If you have a lot of constraints with the same value, it
> > > > may even be worthwhile to have a two stage structure where for
> > > > instance you use a rbtree for the unique values and list for identical
> > > > constraints.
> > > 
> > > I don't agree, we went through this tree vrs list discussion a few times
> > > before in other areas of the kernel.  Wherever the list tended to be
> > > short, a simple list wins.  However; we can try it, after we have some
> > > metrics and stress test cases identified we can measure its effectivenes
> > > against.
> > 
> > How many different values are there to handle?
> >
> 
> for the current pm_qos users its tiny.  I've never heard of more than a
> few < 10.  However; for the new "interactive" class to provide suspend
> blocker functionality, I expect the number to be up to 20.
> 
> but realistically I bet we never get more than 10ish.
> 
> One constraint constraint request per module from isr to user mode.
> Once in user mode there would be only a few (assuming Android user
> space) I think just from the power HAL, input HAL, and the RIL.
> 
> Still a pretty small number I don't think we need to worry about scaling
> as much as we need to worry about performance.

In that case sorting the structure is rather not going to improve things, but
it might be worth using a hashtable or something similar.

Rafael

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

[mark gross]

On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> 2010/6/2 mark gross <640e9920@gmail.com>:
> > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hjønnevåg wrote:
> >> On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920@gmail.com> wrote:
> >> > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> >> ...
> >> >> +static void update_target_val(int pm_qos_class, s32 val)
> >> >> +{
> >> >> +     s32 extreme_value;
> >> >> +     s32 new_value;
> >> >> +     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
> >> >> +     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);
> >> >> +     if (extreme_value != new_value)
> >> >> +             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
> >> >> +}
> >> >> +
> >> >
> >> > Only works 1/2 the time, but I like the idea!
> >> > It fails to get the righ answer when constraints are reduced.  But, this
> >> > idea is a good improvement i'll roll into the next pm_qos update!
> >> >
> >>
> >> I think it would be a better idea to track your constraints with a
> >> sorted data structure. That way you can to better than O(n) for both
> >> directions. If you have a lot of constraints with the same value, it
> >> may even be worthwhile to have a two stage structure where for
> >> instance you use a rbtree for the unique values and list for identical
> >> constraints.
> >
> > I don't agree, we went through this tree vrs list discussion a few times
> > before in other areas of the kernel.  Wherever the list tended to be
> > short, a simple list wins.  However; we can try it, after we have some
> > metrics and stress test cases identified we can measure its effectivenes
> > against.
> >
> 
> The list is not short. You have all the inactive and active
> constraints on the same list. If you change it to a two level list
> though, the list of unique values (which is the list you have to walk)
> may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a
handfull.  However; one could go to a dual list (like the scheduler) and
move inactive nodes from an active to inactive list, or we could simply
remove them from the list uppon inactivity.  which would would well
after I change the api to have the client allocate the memory for the
nodes...  BUT, if your moving things in and out of a list a lot, I'm not
sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

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

[Brian Swetland]

On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
>>
>> The list is not short. You have all the inactive and active
>> constraints on the same list. If you change it to a two level list
>> though, the list of unique values (which is the list you have to walk)
>> may be short enough for a tree to be overkill.
>
> what have you seen in practice from the wake-lock stats?
>
> I'm having a hard time seeing where you could get more than just a
> handfull.  However; one could go to a dual list (like the scheduler) and
> move inactive nodes from an active to inactive list, or we could simply
> remove them from the list uppon inactivity.  which would would well
> after I change the api to have the client allocate the memory for the
> nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> sure the break even point where changing the structure helps.
>
> We'll need to try it.
>
> I think we will almost never see more than 10 list elements.
>
> --mgross
>
>

I see about 80 (based on the batteryinfo dump) on my Nexus One
(QSD8250, Android Froyo):

  Kernel Wake lock "event5-86": (nothing executed)
  Kernel Wake lock "PowerManagerService": 4m 27s 994ms  (453 times) realtime
  Kernel Wake lock "event4-92": 72ms  (10 times) realtime
  Kernel Wake lock "AudioHardwareQSDIn": (nothing executed)
  Kernel Wake lock "event4-87": (nothing executed)
  Kernel Wake lock "event5-82": (nothing executed)
  Kernel Wake lock "event2-87": (nothing executed)
  Kernel Wake lock "alarm_rtc": 21s 882ms  (186 times) realtime
  Kernel Wake lock "vdec_suspend": (nothing executed)
  Kernel Wake lock "event6-87": (nothing executed)
  Kernel Wake lock "event0-91": (nothing executed)
  Kernel Wake lock "SMD_DS": 30s 938ms  (53 times) realtime
  Kernel Wake lock "event6-91": (nothing executed)
  Kernel Wake lock "KeyEvents": 398ms  (3226 times) realtime
  Kernel Wake lock "qmi1": (nothing executed)
  Kernel Wake lock "mmc_delayed_work": (nothing executed)
  Kernel Wake lock "event3-82": (nothing executed)
  Kernel Wake lock "event3-92": 58ms  (6 times) realtime
  Kernel Wake lock "SMD_RPCCALL": 295ms  (1756 times) realtime
  Kernel Wake lock "SMD_DATA6": (nothing executed)
  Kernel Wake lock "audio_pcm_idle": 3s 99ms  (1 times) realtime
  Kernel Wake lock "serial-debug": (nothing executed)
  Kernel Wake lock "event6-82": (nothing executed)
  Kernel Wake lock "event3-86": (nothing executed)
  Kernel Wake lock "event2-82": (nothing executed)
  Kernel Wake lock "i2c": (nothing executed)
  Kernel Wake lock "event2-86": (nothing executed)
  Kernel Wake lock "event5-87": (nothing executed)
  Kernel Wake lock "event4-86": (nothing executed)
  Kernel Wake lock "event5-92": 4ms  (21 times) realtime
  Kernel Wake lock "rpc_server": (nothing executed)
  Kernel Wake lock "power-supply": 527ms  (8 times) realtime
  Kernel Wake lock "radio-interface": 10s 11ms  (10 times) realtime
  Kernel Wake lock "event6-86": (nothing executed)
  Kernel Wake lock "deleted_wake_locks": 203ms  (214 times) realtime
  Kernel Wake lock "qmi0": (nothing executed)
  Kernel Wake lock "event2-91": (nothing executed)
  Kernel Wake lock "event4-82": (nothing executed)
  Kernel Wake lock "event7-82": (nothing executed)
  Kernel Wake lock "dock": 27ms  (1 times) realtime
  Kernel Wake lock "SMD_DATA5": 1m 45s 121ms  (158 times) realtime
  Kernel Wake lock "event1-92": (nothing executed)
  Kernel Wake lock "gpio_kp": (nothing executed)
  Kernel Wake lock "event3-87": (nothing executed)
  Kernel Wake lock "event7-92": (nothing executed)
  Kernel Wake lock "msm_serial_hs_dma": (nothing executed)
  Kernel Wake lock "event5-91": (nothing executed)
  Kernel Wake lock "vbus_present": 517ms  (1 times) realtime
  Kernel Wake lock "alarm": 3s 229ms  (249 times) realtime
  Kernel Wake lock "event1-82": (nothing executed)
  Kernel Wake lock "venc_suspend": (nothing executed)
  Kernel Wake lock "event1-86": (nothing executed)
  Kernel Wake lock "AudioHardwareQSDOut": 3s 98ms  (1 times) realtime
  Kernel Wake lock "event0-87": (nothing executed)
  Kernel Wake lock "event2-92": 169ms  (687 times) realtime
  Kernel Wake lock "ds2784-battery": 12s 846ms  (158 times) realtime
  Kernel Wake lock "ApmCommandThread": 564ms  (2 times) realtime
  Kernel Wake lock "msmfb_idle_lock": 1s 495ms  (715 times) realtime
  Kernel Wake lock "headset": (nothing executed)
  Kernel Wake lock "kgsl": 26s 473ms  (123 times) realtime
  Kernel Wake lock "venc_idle": (nothing executed)
  Kernel Wake lock "event1-91": (nothing executed)
  Kernel Wake lock "s5k3e2fx": (nothing executed)
  Kernel Wake lock "usb_mass_storage": (nothing executed)
  Kernel Wake lock "unknown_wakeups": (nothing executed)
  Kernel Wake lock "vdec_idle": (nothing executed)
  Kernel Wake lock "audio_pcm_suspend": 3s 99ms  (1 times) realtime
  Kernel Wake lock "microp_i2c_present": (nothing executed)
  Kernel Wake lock "event4-91": (nothing executed)
  Kernel Wake lock "event6-92": 182ms  (86 times) realtime
  Kernel Wake lock "event0-82": (nothing executed)
  Kernel Wake lock "event0-92": 8ms  (37 times) realtime
  Kernel Wake lock "rpc_read": 112ms  (1540 times) realtime
  Kernel Wake lock "event0-86": (nothing executed)
  Kernel Wake lock "msm_serial_hs_rx": (nothing executed)
  Kernel Wake lock "qmi2": (nothing executed)
  Kernel Wake lock "event1-87": (nothing executed)
  Kernel Wake lock "msm_camera": (nothing executed)
  Kernel Wake lock "rpc-interface": 2ms  (1 times) realtime
  Kernel Wake lock "main": 1m 38s 314ms  (5 times) realtime
  Kernel Wake lock "gpio_input": (nothing executed)
  Kernel Wake lock "event3-91": (nothing executed)
  Kernel Wake lock "SMD_DATA7": (nothing executed)
_______________________________________________
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 Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> >>
> >> The list is not short. You have all the inactive and active
> >> constraints on the same list. If you change it to a two level list
> >> though, the list of unique values (which is the list you have to walk)
> >> may be short enough for a tree to be overkill.
> >
> > what have you seen in practice from the wake-lock stats?
> >
> > I'm having a hard time seeing where you could get more than just a
> > handfull.  However; one could go to a dual list (like the scheduler) and
> > move inactive nodes from an active to inactive list, or we could simply
> > remove them from the list uppon inactivity.  which would would well
> > after I change the api to have the client allocate the memory for the
> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> > sure the break even point where changing the structure helps.
> >
> > We'll need to try it.
> >
> > I think we will almost never see more than 10 list elements.
> >
> > --mgross
> >
> >
> 
> I see about 80 (based on the batteryinfo dump) on my Nexus One
> (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can
get away with not walking the list on every request update.  we can use
a counter, and the list will be for mostly for stats.
 
>   Kernel Wake lock "event5-86": (nothing executed)
>   Kernel Wake lock "PowerManagerService": 4m 27s 994ms  (453 times) realtime
>   Kernel Wake lock "event4-92": 72ms  (10 times) realtime
>   Kernel Wake lock "AudioHardwareQSDIn": (nothing executed)
>   Kernel Wake lock "event4-87": (nothing executed)
>   Kernel Wake lock "event5-82": (nothing executed)
>   Kernel Wake lock "event2-87": (nothing executed)
>   Kernel Wake lock "alarm_rtc": 21s 882ms  (186 times) realtime
>   Kernel Wake lock "vdec_suspend": (nothing executed)
>   Kernel Wake lock "event6-87": (nothing executed)
>   Kernel Wake lock "event0-91": (nothing executed)
>   Kernel Wake lock "SMD_DS": 30s 938ms  (53 times) realtime
>   Kernel Wake lock "event6-91": (nothing executed)
>   Kernel Wake lock "KeyEvents": 398ms  (3226 times) realtime
>   Kernel Wake lock "qmi1": (nothing executed)
>   Kernel Wake lock "mmc_delayed_work": (nothing executed)
>   Kernel Wake lock "event3-82": (nothing executed)
>   Kernel Wake lock "event3-92": 58ms  (6 times) realtime
>   Kernel Wake lock "SMD_RPCCALL": 295ms  (1756 times) realtime
>   Kernel Wake lock "SMD_DATA6": (nothing executed)
>   Kernel Wake lock "audio_pcm_idle": 3s 99ms  (1 times) realtime
>   Kernel Wake lock "serial-debug": (nothing executed)
>   Kernel Wake lock "event6-82": (nothing executed)
>   Kernel Wake lock "event3-86": (nothing executed)
>   Kernel Wake lock "event2-82": (nothing executed)
>   Kernel Wake lock "i2c": (nothing executed)
>   Kernel Wake lock "event2-86": (nothing executed)
>   Kernel Wake lock "event5-87": (nothing executed)
>   Kernel Wake lock "event4-86": (nothing executed)
>   Kernel Wake lock "event5-92": 4ms  (21 times) realtime
>   Kernel Wake lock "rpc_server": (nothing executed)
>   Kernel Wake lock "power-supply": 527ms  (8 times) realtime
>   Kernel Wake lock "radio-interface": 10s 11ms  (10 times) realtime
>   Kernel Wake lock "event6-86": (nothing executed)
>   Kernel Wake lock "deleted_wake_locks": 203ms  (214 times) realtime
>   Kernel Wake lock "qmi0": (nothing executed)
>   Kernel Wake lock "event2-91": (nothing executed)
>   Kernel Wake lock "event4-82": (nothing executed)
>   Kernel Wake lock "event7-82": (nothing executed)
>   Kernel Wake lock "dock": 27ms  (1 times) realtime
>   Kernel Wake lock "SMD_DATA5": 1m 45s 121ms  (158 times) realtime
>   Kernel Wake lock "event1-92": (nothing executed)
>   Kernel Wake lock "gpio_kp": (nothing executed)
>   Kernel Wake lock "event3-87": (nothing executed)
>   Kernel Wake lock "event7-92": (nothing executed)
>   Kernel Wake lock "msm_serial_hs_dma": (nothing executed)
>   Kernel Wake lock "event5-91": (nothing executed)
>   Kernel Wake lock "vbus_present": 517ms  (1 times) realtime
>   Kernel Wake lock "alarm": 3s 229ms  (249 times) realtime
>   Kernel Wake lock "event1-82": (nothing executed)
>   Kernel Wake lock "venc_suspend": (nothing executed)
>   Kernel Wake lock "event1-86": (nothing executed)
>   Kernel Wake lock "AudioHardwareQSDOut": 3s 98ms  (1 times) realtime
>   Kernel Wake lock "event0-87": (nothing executed)
>   Kernel Wake lock "event2-92": 169ms  (687 times) realtime
>   Kernel Wake lock "ds2784-battery": 12s 846ms  (158 times) realtime
>   Kernel Wake lock "ApmCommandThread": 564ms  (2 times) realtime
>   Kernel Wake lock "msmfb_idle_lock": 1s 495ms  (715 times) realtime
>   Kernel Wake lock "headset": (nothing executed)
>   Kernel Wake lock "kgsl": 26s 473ms  (123 times) realtime
>   Kernel Wake lock "venc_idle": (nothing executed)
>   Kernel Wake lock "event1-91": (nothing executed)
>   Kernel Wake lock "s5k3e2fx": (nothing executed)
>   Kernel Wake lock "usb_mass_storage": (nothing executed)
>   Kernel Wake lock "unknown_wakeups": (nothing executed)
>   Kernel Wake lock "vdec_idle": (nothing executed)
>   Kernel Wake lock "audio_pcm_suspend": 3s 99ms  (1 times) realtime
>   Kernel Wake lock "microp_i2c_present": (nothing executed)
>   Kernel Wake lock "event4-91": (nothing executed)
>   Kernel Wake lock "event6-92": 182ms  (86 times) realtime
>   Kernel Wake lock "event0-82": (nothing executed)
>   Kernel Wake lock "event0-92": 8ms  (37 times) realtime
>   Kernel Wake lock "rpc_read": 112ms  (1540 times) realtime
>   Kernel Wake lock "event0-86": (nothing executed)
>   Kernel Wake lock "msm_serial_hs_rx": (nothing executed)
>   Kernel Wake lock "qmi2": (nothing executed)
>   Kernel Wake lock "event1-87": (nothing executed)
>   Kernel Wake lock "msm_camera": (nothing executed)
>   Kernel Wake lock "rpc-interface": 2ms  (1 times) realtime
>   Kernel Wake lock "main": 1m 38s 314ms  (5 times) realtime
>   Kernel Wake lock "gpio_input": (nothing executed)
>   Kernel Wake lock "event3-91": (nothing executed)
>   Kernel Wake lock "SMD_DATA7": (nothing executed)

How much of this is portable to your next phone?  I bet it was a big
effort to get these right too.  FWIW I don't think most of these will
map into the moorestown port of android I'm working on.

This is why I really think a low power event framework would be cleaner
but, lets make everyone happy and expand pm_qos into a wake lock
re-implementation first.

--mgross

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

[Arve Hjønnevåg]

On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
>> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
>> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
>> >>
>> >> The list is not short. You have all the inactive and active
>> >> constraints on the same list. If you change it to a two level list
>> >> though, the list of unique values (which is the list you have to walk)
>> >> may be short enough for a tree to be overkill.
>> >
>> > what have you seen in practice from the wake-lock stats?
>> >
>> > I'm having a hard time seeing where you could get more than just a
>> > handfull.  However; one could go to a dual list (like the scheduler) and
>> > move inactive nodes from an active to inactive list, or we could simply
>> > remove them from the list uppon inactivity.  which would would well
>> > after I change the api to have the client allocate the memory for the
>> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
>> > sure the break even point where changing the structure helps.
>> >
>> > We'll need to try it.
>> >
>> > I think we will almost never see more than 10 list elements.
>> >
>> > --mgross
>> >
>> >
>>
>> I see about 80 (based on the batteryinfo dump) on my Nexus One
>> (QSD8250, Android Froyo):
>
> shucks.
>
> well I think for a pm_qos class that has boolean dynamic range we can
> get away with not walking the list on every request update.  we can use
> a counter, and the list will be for mostly for stats.
>

Did you give any thought to my suggestion to only use one entry per
unique value on the first level list and then use secondary lists of
identical values. That way if you only have two constraints values the
list you have to walk when updating a request will never have more
than two entries regardless of how many total request you have.

A request update then becomes something like this:
  if on primary list {
    unlink from primary list
    if secondary list is not empty
      get next secondary entry and add in same spot on primary list
  }
  unlink from secondary list
  find new spot on primary list
  if already there
    add to secondary list
  else
    add to primary list

-- 
Arve Hjønnevåg

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

[mark gross]

On Thu, Jun 03, 2010 at 12:10:03AM -0700, Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> >> >>
> >> >> The list is not short. You have all the inactive and active
> >> >> constraints on the same list. If you change it to a two level list
> >> >> though, the list of unique values (which is the list you have to walk)
> >> >> may be short enough for a tree to be overkill.
> >> >
> >> > what have you seen in practice from the wake-lock stats?
> >> >
> >> > I'm having a hard time seeing where you could get more than just a
> >> > handfull.  However; one could go to a dual list (like the scheduler) and
> >> > move inactive nodes from an active to inactive list, or we could simply
> >> > remove them from the list uppon inactivity.  which would would well
> >> > after I change the api to have the client allocate the memory for the
> >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> >> > sure the break even point where changing the structure helps.
> >> >
> >> > We'll need to try it.
> >> >
> >> > I think we will almost never see more than 10 list elements.
> >> >
> >> > --mgross
> >> >
> >> >
> >>
> >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> >> (QSD8250, Android Froyo):
> >
> > shucks.
> >
> > well I think for a pm_qos class that has boolean dynamic range we can
> > get away with not walking the list on every request update.  we can use
> > a counter, and the list will be for mostly for stats.
> >
> 
> Did you give any thought to my suggestion to only use one entry per
> unique value on the first level list and then use secondary lists of
> identical values. That way if you only have two constraints values the

I thought you where talking about a active + inactive queue.  Sorry, I
didn't get what you where talking about.

> list you have to walk when updating a request will never have more
> than two entries regardless of how many total request you have.
> 
> A request update then becomes something like this:
>   if on primary list {
>     unlink from primary list
>     if secondary list is not empty
>       get next secondary entry and add in same spot on primary list
>   }
>   unlink from secondary list
>   find new spot on primary list
>   if already there
>     add to secondary list
>   else
>     add to primary list
>

I'm still no getting how this will allow me to reduce any aggregated
constratint re-computation to a list walk of at most 2 nodes.  But, from
a more specific point of view are you saying:
change the request struct to be something like:
struct dual_list_constriaint {
	struct list primary;
	struct list secondar;
	s32 value;
	...
} 

then uppon constraint foo update:

if foo->primary not empty:
	remove foor from primary list
	if gsecondary is not empty:
		ordered insert of foo into secondary list 
		? ordered on constraint value?
		? Arn't the constraints boolean?
remove foo from secondary list
ordered search for insert point of foo into primary list
if foo in primary:
	insert foo into secondary list
else
	insert foo into primary list

ok I'm not getting it.
is this a fancy com-sci algorithm I should know about?

--mgross

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

[Florian Mickler]

On Thu, 3 Jun 2010 00:10:03 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:

> > well I think for a pm_qos class that has boolean dynamic range we can
> > get away with not walking the list on every request update.  we can use
> > a counter, and the list will be for mostly for stats.
> >
> 
> Did you give any thought to my suggestion to only use one entry per
> unique value on the first level list and then use secondary lists of
> identical values. That way if you only have two constraints values the
> list you have to walk when updating a request will never have more
> than two entries regardless of how many total request you have.
> 
> A request update then becomes something like this:
>   if on primary list {
>     unlink from primary list
>     if secondary list is not empty
>       get next secondary entry and add in same spot on primary list
>   }
>   unlink from secondary list
>   find new spot on primary list
>   if already there
>     add to secondary list
>   else
>     add to primary list
> 

Yes. I think that would be good. If we keep the primary list sorted,
then this becomes a nice priority queue implementation which does 
GetMax in constant time and Insert and Delete in logarithmic
complexity to the number of different values.

Cheers,
Flo

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

[Florian Mickler]

On Thu, 3 Jun 2010 06:24:49 -0700
mark gross <640e9920@gmail.com> wrote:

> On Thu, Jun 03, 2010 at 12:10:03AM -0700, Arve Hjønnevåg wrote:

> ok I'm not getting it.
> is this a fancy com-sci algorithm I should know about?
> 
> --mgross

I think you are at an advantage if you have studied fancy com-sci for
this? Here is an example:

say you have 5 constraints: 
qos1 with a value of 10
qos2 with 5
qos3 with 10
qos4 with 11

Now, you hash that list by the qos-values:

11    ---- 10 	----- 5 
|	   |  	      |
qos4	   qos3       qos2
	   |
	   qos1


To compute the maximum you just walk the "----" list.

To reduce qos4 from 11 to 5 you remove it from its "|" list and
prepend it to the corresponding "|" list.  (4 Pointer adjustments +
searching the "-----" list for the right place to insert.  

result:

10 ---- 5
|	|
qos3	qos4
|	|
qos1	qos2

Cheers,
Flo

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

[mark gross]

On Thu, Jun 03, 2010 at 04:30:49PM +0200, Florian Mickler wrote:
> On Thu, 3 Jun 2010 06:24:49 -0700
> mark gross <640e9920@gmail.com> wrote:
> 
> > On Thu, Jun 03, 2010 at 12:10:03AM -0700, Arve Hjønnevåg wrote:
> 
> > ok I'm not getting it.
> > is this a fancy com-sci algorithm I should know about?
> > 
> > --mgross
> 
> I think you are at an advantage if you have studied fancy com-sci for
> this? Here is an example:
> 
> say you have 5 constraints: 
> qos1 with a value of 10
> qos2 with 5
> qos3 with 10
> qos4 with 11
> 
> Now, you hash that list by the qos-values:
> 
> 11    ---- 10 	----- 5 
> |	   |  	      |
> qos4	   qos3       qos2
> 	   |
> 	   qos1
> 
> 
> To compute the maximum you just walk the "----" list.
> 
> To reduce qos4 from 11 to 5 you remove it from its "|" list and
> prepend it to the corresponding "|" list.  (4 Pointer adjustments +
> searching the "-----" list for the right place to insert.  
> 
> result:
> 
> 10 ---- 5
> |	|
> qos3	qos4
> |	|
> qos1	qos2
> 
> Cheers,

Oh!  ok, thats easy!

Thanks!!!

--mgross

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

[James Bottomley]

On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> >> >>
> >> >> The list is not short. You have all the inactive and active
> >> >> constraints on the same list. If you change it to a two level list
> >> >> though, the list of unique values (which is the list you have to walk)
> >> >> may be short enough for a tree to be overkill.
> >> >
> >> > what have you seen in practice from the wake-lock stats?
> >> >
> >> > I'm having a hard time seeing where you could get more than just a
> >> > handfull.  However; one could go to a dual list (like the scheduler) and
> >> > move inactive nodes from an active to inactive list, or we could simply
> >> > remove them from the list uppon inactivity.  which would would well
> >> > after I change the api to have the client allocate the memory for the
> >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> >> > sure the break even point where changing the structure helps.
> >> >
> >> > We'll need to try it.
> >> >
> >> > I think we will almost never see more than 10 list elements.
> >> >
> >> > --mgross
> >> >
> >> >
> >>
> >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> >> (QSD8250, Android Froyo):
> >
> > shucks.
> >
> > well I think for a pm_qos class that has boolean dynamic range we can
> > get away with not walking the list on every request update.  we can use
> > a counter, and the list will be for mostly for stats.
> >
> 
> Did you give any thought to my suggestion to only use one entry per
> unique value on the first level list and then use secondary lists of
> identical values. That way if you only have two constraints values the
> list you have to walk when updating a request will never have more
> than two entries regardless of how many total request you have.
> 
> A request update then becomes something like this:
>   if on primary list {
>     unlink from primary list
>     if secondary list is not empty
>       get next secondary entry and add in same spot on primary list
>   }
>   unlink from secondary list
>   find new spot on primary list
>   if already there
>     add to secondary list
>   else
>     add to primary list

This is just reinventing hash bucketed lists.  To get the benefits, all
we do is implement an N state constraint as backed by an N bucketed hash
list, which the kernel already has all the internal mechanics for.

James


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

[Florian Mickler]

On Thu, 03 Jun 2010 09:36:34 -0500
James Bottomley <James.Bottomley@suse.de> wrote:

> On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> > >> >>
> > >> >> The list is not short. You have all the inactive and active
> > >> >> constraints on the same list. If you change it to a two level list
> > >> >> though, the list of unique values (which is the list you have to walk)
> > >> >> may be short enough for a tree to be overkill.
> > >> >
> > >> > what have you seen in practice from the wake-lock stats?
> > >> >
> > >> > I'm having a hard time seeing where you could get more than just a
> > >> > handfull.  However; one could go to a dual list (like the scheduler) and
> > >> > move inactive nodes from an active to inactive list, or we could simply
> > >> > remove them from the list uppon inactivity.  which would would well
> > >> > after I change the api to have the client allocate the memory for the
> > >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> > >> > sure the break even point where changing the structure helps.
> > >> >
> > >> > We'll need to try it.
> > >> >
> > >> > I think we will almost never see more than 10 list elements.
> > >> >
> > >> > --mgross
> > >> >
> > >> >
> > >>
> > >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> > >> (QSD8250, Android Froyo):
> > >
> > > shucks.
> > >
> > > well I think for a pm_qos class that has boolean dynamic range we can
> > > get away with not walking the list on every request update.  we can use
> > > a counter, and the list will be for mostly for stats.
> > >
> > 
> > Did you give any thought to my suggestion to only use one entry per
> > unique value on the first level list and then use secondary lists of
> > identical values. That way if you only have two constraints values the
> > list you have to walk when updating a request will never have more
> > than two entries regardless of how many total request you have.
> > 
> > A request update then becomes something like this:
> >   if on primary list {
> >     unlink from primary list
> >     if secondary list is not empty
> >       get next secondary entry and add in same spot on primary list
> >   }
> >   unlink from secondary list
> >   find new spot on primary list
> >   if already there
> >     add to secondary list
> >   else
> >     add to primary list
> 
> This is just reinventing hash bucketed lists.  To get the benefits, all
> we do is implement an N state constraint as backed by an N bucketed hash
> list, which the kernel already has all the internal mechanics for.
> 
> James
>

http://www.itl.nist.gov/div897/sqg/dads/HTML/priorityque.html

So no reinvention. Just using a common scheme. 

Cheers,
Flo

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

[James Bottomley]

On Thu, 2010-06-03 at 17:17 +0200, Florian Mickler wrote:
> On Thu, 03 Jun 2010 09:36:34 -0500
> James Bottomley <James.Bottomley@suse.de> wrote:
> 
> > On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> > > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> > > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> > > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> > > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> > > >> >>
> > > >> >> The list is not short. You have all the inactive and active
> > > >> >> constraints on the same list. If you change it to a two level list
> > > >> >> though, the list of unique values (which is the list you have to walk)
> > > >> >> may be short enough for a tree to be overkill.
> > > >> >
> > > >> > what have you seen in practice from the wake-lock stats?
> > > >> >
> > > >> > I'm having a hard time seeing where you could get more than just a
> > > >> > handfull.  However; one could go to a dual list (like the scheduler) and
> > > >> > move inactive nodes from an active to inactive list, or we could simply
> > > >> > remove them from the list uppon inactivity.  which would would well
> > > >> > after I change the api to have the client allocate the memory for the
> > > >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> > > >> > sure the break even point where changing the structure helps.
> > > >> >
> > > >> > We'll need to try it.
> > > >> >
> > > >> > I think we will almost never see more than 10 list elements.
> > > >> >
> > > >> > --mgross
> > > >> >
> > > >> >
> > > >>
> > > >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> > > >> (QSD8250, Android Froyo):
> > > >
> > > > shucks.
> > > >
> > > > well I think for a pm_qos class that has boolean dynamic range we can
> > > > get away with not walking the list on every request update.  we can use
> > > > a counter, and the list will be for mostly for stats.
> > > >
> > > 
> > > Did you give any thought to my suggestion to only use one entry per
> > > unique value on the first level list and then use secondary lists of
> > > identical values. That way if you only have two constraints values the
> > > list you have to walk when updating a request will never have more
> > > than two entries regardless of how many total request you have.
> > > 
> > > A request update then becomes something like this:
> > >   if on primary list {
> > >     unlink from primary list
> > >     if secondary list is not empty
> > >       get next secondary entry and add in same spot on primary list
> > >   }
> > >   unlink from secondary list
> > >   find new spot on primary list
> > >   if already there
> > >     add to secondary list
> > >   else
> > >     add to primary list
> > 
> > This is just reinventing hash bucketed lists.  To get the benefits, all
> > we do is implement an N state constraint as backed by an N bucketed hash
> > list, which the kernel already has all the internal mechanics for.
> > 
> > James
> >
> 
> http://www.itl.nist.gov/div897/sqg/dads/HTML/priorityque.html
> 
> So no reinvention. Just using a common scheme. 

By reinvention I meant open coding a common pattern for which the kernel
already has an API.  (Whether we go with hash buckets or plists).

James


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

[Florian Mickler]

On Thu, 03 Jun 2010 10:29:52 -0500
James Bottomley <James.Bottomley@suse.de> wrote:


> > So no reinvention. Just using a common scheme. 
> 
> By reinvention I meant open coding a common pattern for which the kernel
> already has an API.  (Whether we go with hash buckets or plists).
> 
> James
> 

Ah, plists.h! Thanks for the pointer.

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

[Rafael J. Wysocki]

On Thursday 03 June 2010, James Bottomley wrote:
> On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> > >> >>
> > >> >> The list is not short. You have all the inactive and active
> > >> >> constraints on the same list. If you change it to a two level list
> > >> >> though, the list of unique values (which is the list you have to walk)
> > >> >> may be short enough for a tree to be overkill.
> > >> >
> > >> > what have you seen in practice from the wake-lock stats?
> > >> >
> > >> > I'm having a hard time seeing where you could get more than just a
> > >> > handfull.  However; one could go to a dual list (like the scheduler) and
> > >> > move inactive nodes from an active to inactive list, or we could simply
> > >> > remove them from the list uppon inactivity.  which would would well
> > >> > after I change the api to have the client allocate the memory for the
> > >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> > >> > sure the break even point where changing the structure helps.
> > >> >
> > >> > We'll need to try it.
> > >> >
> > >> > I think we will almost never see more than 10 list elements.
> > >> >
> > >> > --mgross
> > >> >
> > >> >
> > >>
> > >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> > >> (QSD8250, Android Froyo):
> > >
> > > shucks.
> > >
> > > well I think for a pm_qos class that has boolean dynamic range we can
> > > get away with not walking the list on every request update.  we can use
> > > a counter, and the list will be for mostly for stats.
> > >
> > 
> > Did you give any thought to my suggestion to only use one entry per
> > unique value on the first level list and then use secondary lists of
> > identical values. That way if you only have two constraints values the
> > list you have to walk when updating a request will never have more
> > than two entries regardless of how many total request you have.
> > 
> > A request update then becomes something like this:
> >   if on primary list {
> >     unlink from primary list
> >     if secondary list is not empty
> >       get next secondary entry and add in same spot on primary list
> >   }
> >   unlink from secondary list
> >   find new spot on primary list
> >   if already there
> >     add to secondary list
> >   else
> >     add to primary list
> 
> This is just reinventing hash bucketed lists.  To get the benefits, all
> we do is implement an N state constraint as backed by an N bucketed hash
> list, which the kernel already has all the internal mechanics for.

Agreed.

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)

[Arve Hjønnevåg]

On Thu, Jun 3, 2010 at 2:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday 03 June 2010, James Bottomley wrote:
>> On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
>> > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
>> > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
>> > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
>> > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
>> > >> >>
>> > >> >> The list is not short. You have all the inactive and active
>> > >> >> constraints on the same list. If you change it to a two level list
>> > >> >> though, the list of unique values (which is the list you have to walk)
>> > >> >> may be short enough for a tree to be overkill.
>> > >> >
>> > >> > what have you seen in practice from the wake-lock stats?
>> > >> >
>> > >> > I'm having a hard time seeing where you could get more than just a
>> > >> > handfull.  However; one could go to a dual list (like the scheduler) and
>> > >> > move inactive nodes from an active to inactive list, or we could simply
>> > >> > remove them from the list uppon inactivity.  which would would well
>> > >> > after I change the api to have the client allocate the memory for the
>> > >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
>> > >> > sure the break even point where changing the structure helps.
>> > >> >
>> > >> > We'll need to try it.
>> > >> >
>> > >> > I think we will almost never see more than 10 list elements.
>> > >> >
>> > >> > --mgross
>> > >> >
>> > >> >
>> > >>
>> > >> I see about 80 (based on the batteryinfo dump) on my Nexus One
>> > >> (QSD8250, Android Froyo):
>> > >
>> > > shucks.
>> > >
>> > > well I think for a pm_qos class that has boolean dynamic range we can
>> > > get away with not walking the list on every request update.  we can use
>> > > a counter, and the list will be for mostly for stats.
>> > >
>> >
>> > Did you give any thought to my suggestion to only use one entry per
>> > unique value on the first level list and then use secondary lists of
>> > identical values. That way if you only have two constraints values the
>> > list you have to walk when updating a request will never have more
>> > than two entries regardless of how many total request you have.
>> >
>> > A request update then becomes something like this:
>> >   if on primary list {
>> >     unlink from primary list
>> >     if secondary list is not empty
>> >       get next secondary entry and add in same spot on primary list
>> >   }
>> >   unlink from secondary list
>> >   find new spot on primary list
>> >   if already there
>> >     add to secondary list
>> >   else
>> >     add to primary list
>>
>> This is just reinventing hash bucketed lists.  To get the benefits, all
>> we do is implement an N state constraint as backed by an N bucketed hash
>> list, which the kernel already has all the internal mechanics for.
>
> Agreed.
>

No, a hash is used for quick lookup of a specific value, not to find
an extreme value. It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together. If we
want to have constraints that autoexpire, then keeping the secondary
lists separate allows the same optimization as I did for
wakelock/suspend_blocker timeouts where no timer is active if an
(equal or stricter) non-expiring constraint is active.

-- 
Arve Hjønnevåg

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

[Florian Mickler]

On Thu, 3 Jun 2010 21:07:07 -0700
Arve Hjønnevåg <arve@android.com> wrote:

> On Thu, Jun 3, 2010 at 2:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Thursday 03 June 2010, James Bottomley wrote:
> >> On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> >> > A request update then becomes something like this:
> >> >   if on primary list {
> >> >     unlink from primary list
> >> >     if secondary list is not empty
> >> >       get next secondary entry and add in same spot on primary list
> >> >   }
> >> >   unlink from secondary list
> >> >   find new spot on primary list
> >> >   if already there
> >> >     add to secondary list
> >> >   else
> >> >     add to primary list
> >>
> >> This is just reinventing hash bucketed lists.  To get the benefits, all
> >> we do is implement an N state constraint as backed by an N bucketed hash
> >> list, which the kernel already has all the internal mechanics for.
> >
> > Agreed.
> >
> 
> No, a hash is used for quick lookup of a specific value, not to find
> an extreme value. It is however extremely similar to plists. The only
> difference is that plists link all the secondary lists together. If we
> want to have constraints that autoexpire, then keeping the secondary
> lists separate allows the same optimization as I did for
> wakelock/suspend_blocker timeouts where no timer is active if an
> (equal or stricter) non-expiring constraint is active.

Can you give an example for the optimization or elaborate about the
negative effect of linking the secondary lists together? I don't
understand right now.

Would be hlist from list.h better? (I think that is what James is
referring to?) That is a (single-linked-)list of double-linked-lists. 

Cheers,
Flo

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

[James Bottomley]

On Thu, 2010-06-03 at 21:07 -0700, Arve Hjønnevåg wrote:
> On Thu, Jun 3, 2010 at 2:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Thursday 03 June 2010, James Bottomley wrote:
> >> On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote:
> >> > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920@gmail.com> wrote:
> >> > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote:
> >> > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920@gmail.com> wrote:
> >> > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote:
> >> > >> >>
> >> > >> >> The list is not short. You have all the inactive and active
> >> > >> >> constraints on the same list. If you change it to a two level list
> >> > >> >> though, the list of unique values (which is the list you have to walk)
> >> > >> >> may be short enough for a tree to be overkill.
> >> > >> >
> >> > >> > what have you seen in practice from the wake-lock stats?
> >> > >> >
> >> > >> > I'm having a hard time seeing where you could get more than just a
> >> > >> > handfull.  However; one could go to a dual list (like the scheduler) and
> >> > >> > move inactive nodes from an active to inactive list, or we could simply
> >> > >> > remove them from the list uppon inactivity.  which would would well
> >> > >> > after I change the api to have the client allocate the memory for the
> >> > >> > nodes...  BUT, if your moving things in and out of a list a lot, I'm not
> >> > >> > sure the break even point where changing the structure helps.
> >> > >> >
> >> > >> > We'll need to try it.
> >> > >> >
> >> > >> > I think we will almost never see more than 10 list elements.
> >> > >> >
> >> > >> > --mgross
> >> > >> >
> >> > >> >
> >> > >>
> >> > >> I see about 80 (based on the batteryinfo dump) on my Nexus One
> >> > >> (QSD8250, Android Froyo):
> >> > >
> >> > > shucks.
> >> > >
> >> > > well I think for a pm_qos class that has boolean dynamic range we can
> >> > > get away with not walking the list on every request update.  we can use
> >> > > a counter, and the list will be for mostly for stats.
> >> > >
> >> >
> >> > Did you give any thought to my suggestion to only use one entry per
> >> > unique value on the first level list and then use secondary lists of
> >> > identical values. That way if you only have two constraints values the
> >> > list you have to walk when updating a request will never have more
> >> > than two entries regardless of how many total request you have.
> >> >
> >> > A request update then becomes something like this:
> >> >   if on primary list {
> >> >     unlink from primary list
> >> >     if secondary list is not empty
> >> >       get next secondary entry and add in same spot on primary list
> >> >   }
> >> >   unlink from secondary list
> >> >   find new spot on primary list
> >> >   if already there
> >> >     add to secondary list
> >> >   else
> >> >     add to primary list
> >>
> >> This is just reinventing hash bucketed lists.  To get the benefits, all
> >> we do is implement an N state constraint as backed by an N bucketed hash
> >> list, which the kernel already has all the internal mechanics for.
> >
> > Agreed.
> >
> 
> No, a hash is used for quick lookup of a specific value, not to find
> an extreme value.

If you only have N possible values an N bucket hash list is rather
efficient (provided N is small).  But I would agree that knowing what N
is represents an API change, and since plists can do this without
changing the API, they're better.

>  It is however extremely similar to plists. The only
> difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

>  If we
> want to have constraints that autoexpire, then keeping the secondary
> lists separate allows the same optimization as I did for
> wakelock/suspend_blocker timeouts where no timer is active if an
> (equal or stricter) non-expiring constraint is active.

But this is a future discussion and not part of the patch.  The way open
source works is that we sort out the best implementation for the current
conditions.  If the implementation has to change because of future
stuff, then we change it when the future stuff comes along.  Changing
implementations is easy (they don't have any externally visible impact).
Changing the in-kernel API is slightly harder, but easily doable.  It's
only changing the user visible ABI that we worry about and try not to
do.

James


_______________________________________________
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-06-02 at 20:18 -0700, mark gross wrote:
> However; one could go to a dual list (like the scheduler) and
> move inactive nodes from an active to inactive list, 

/me suggests you take a new look at the scheduler, those lists
disappeared more than 10 releases ago. We use RB-trees these days.

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

[mark gross]

On Thu, Jun 03, 2010 at 10:04:29AM +0200, Peter Zijlstra wrote:
> On Wed, 2010-06-02 at 20:18 -0700, mark gross wrote:
> > However; one could go to a dual list (like the scheduler) and
> > move inactive nodes from an active to inactive list, 
> 
> /me suggests you take a new look at the scheduler, those lists
> disappeared more than 10 releases ago. We use RB-trees these days.

your dating me ;)

I haven't taken a hard look at the scheduler for a while.

/me hides.

--mgross

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

[mark gross]

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:
> On Mon, 31 May 2010 16:26:17 -0700
> mark gross <640e9920@gmail.com> wrote:
> 
> > On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> > > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > > > 2010/5/29 Alan Stern <stern@rowland.harvard.edu>:
> > > > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > > > >
> > > > >> > 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.
> > > > >> >
> > > > >> This sound just like another API rename. It will work, but given that
> > > > >> suspend blockers was the name least objectionable last time around,
> > > > >> I'm not sure what this would solve.
> > > > >
> > > > > It's not just a rename.  By changing this into a QoS constraint, we
> > > > > make it more generally useful.  Instead of standing on its own, it
> > > > > becomes part of the PM-QOS framework.
> > > > >
> > > > 
> > > > We cannot use the existing pm-qos framework. It is not safe to call
> > > > from atomic context.
> > > 
> > > We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> > > PM QoS update fix that?
> > >
> > 
> > I'm pretty sure it can be called in atomic context, and if its not I'm
> > sure we can fix that.  It can be called in atomic context.  I don't
> > think it was ever a problem to call it in atomic context.  The problem it
> > had was that crappy list of string compares.  Thats been fixed.
> > 
> > --mgross
> >  
> 
> Well, the register call uses kzalloc. Apart from that I
> think we're good. 

registering shouldn't need to be called in atomic context.  Its the
update_request that needs to be callible form atomic context.

--mgross

 

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: [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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

[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 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: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)

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

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

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

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

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

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

[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: [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 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)

[Igor Stoppa]

ext Felipe Contreras wrote:

> I think this information can be obtained dynamically while the
> application is running,

yes, that was the idea

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

I doubt that belongs to typical QoS. Maybe the target could be to be 
able to decode a sequence of i-frames?
> 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.
>   

from my gaming days the games were still evaluated in fps ... maybe i 
made the wrong assumption?

A telephony app should still be able to tell if it's dropping audio frames.

In all cases there should be some device independent limit - like: what 
is the sort of degradation that is considered acceptable by the typical 
user?

Tuning might be offered, but at least this should set some sane set of 
defaults.

igor

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

[Felipe Contreras]

On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Felipe Contreras wrote:
>
>> I think this information can be obtained dynamically while the
>> application is running,
>
> yes, that was the idea
>
>>  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.
>>
>
> I doubt that belongs to typical QoS. Maybe the target could be to be able to
> decode a sequence of i-frames?

I'm not sure what you mean. I-frames comes usually one per second, so
if you only decode I-frames, your experience would be really bad.
Moreover, you don't know beforehand when an I-frame is coming, only
when it's there, and some clips can have only one I-frame at the
beginning.

>> 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.
>>
>
> from my gaming days the games were still evaluated in fps ... maybe i made
> the wrong assumption?

Yes, the more fps, the better, but you calculate that by counting the
amount of frames rendered over a period of time; you know the fps
*after* the fact.

> A telephony app should still be able to tell if it's dropping audio frames.

Yes, which could be unrelated to PM, like bad network conditions, but
yeah, it should also be able to tell if the problem is with the
application itself (audio decoder too slow).

> In all cases there should be some device independent limit - like: what is
> the sort of degradation that is considered acceptable by the typical user?

It is easy to tell after the PM actions have been made, as in "wait!
I'm not able to perform gimme more power!". But I don't see how that
could be done _before_ the PM actions are done.

From all the QoS proposals I have seen here, and considering that some
people said that suspend blockers could be a specific case of QOS, I
don't think people have been considering QoS as something to state
_after_.

> Tuning might be offered, but at least this should set some sane set of
> defaults.

Huh? Defaults in what units, based on what, and when and how to update?

Cheers.

-- 
Felipe Contreras
_______________________________________________
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)

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

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

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

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

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

[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: [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)

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

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

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

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

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

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

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

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

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

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

[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: [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)

[James Bottomley]

On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> 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.

Look, this is getting into the realms of a pointless semantic quibble.
The problem is that untrusted tasks need to be forcibly suspended when
they have no legitimate work to do and the user hasn't authorised them
to continue even if the scheduler sees them as runnable.  Whether that's
achieved by suspending the entire system or forcibly idling the tasks
(using blocking states or freezers or something) so the scheduler can
suspend from idle is something to be discussed, but the net result is
that we have to stop a certain set of tasks in such a way that they can
still receive certain external events ... semantically, this is
equivalent to not running runnable tasks in my book. (Perhaps this whole
thing is because the word runnable means different things ... I'm
thinking a task that would consume power ... are you thinking in the
scheduler R state?)

Realistically, the main thing we need to do is stop timers posted
against the task (which is likely polling in a main loop, that being the
usual form of easy to write but power crazy app behaviour) from waking
the task and bringing the system out of suspend (whether from idle or
forced).

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

That's rubbish and you know it.  We do software workarounds for hardware
problems all the time ... try doing a git grep -i errata in arch x86, or
imagine a USB subsystem that only supported sane standards conforming
devices: that would have an almost zero intersect with the current USB
device market.

The job of the kernel is to accommodate hardware as best it can ...
sometimes it might not be able to, but most of the time it does a pretty
good job.

The facts are that C states and S states are different and are entered
differently.  For some omap hardware, the power consumption in the
lowest C state (with all the ancillary power control) is the same as S3,
that's fine, suspend from idle works as well as suspend to ram modulo
bad apps. For quite a lot of MSM hardware, the lowest C state power
consumption is quite a bit above S3.  It's not acceptable to tell those
people "tough, your battery runs out in 30 minutes because you bought
the wrong hardware".  We have to figure out how to get to S3 ... whether
this is from idle or some other mechanism is again a discussion point,
but not doing it is not an option.

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

Strange, that's not what I heard as the possible solution.  I thought he
was advocating expressing the kernel side of suspend blockers as QoS
constraints.  Once we have QoS constraints correctly done in the kernel,
userspace still has to express its requirements.  If the requirements
are static, then they can be done from policy files or in some other
static way but if they're dynamic, they'll still have to be in the
applications ... in about the same places the android wakelocks are.

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

I don't think anyone disagrees with this. As long as we find a long term
solution that satisfies the android case, everyone will be happy.

> The only abstraction that really makes sense in that view is idle
> states.

James


_______________________________________________
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 Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > not a sane solution.
> 
> Look, this is getting into the realms of a pointless semantic quibble.
> The problem is that untrusted tasks need to be forcibly suspended when
> they have no legitimate work to do and the user hasn't authorised them
> to continue even if the scheduler sees them as runnable.  Whether that's
> achieved by suspending the entire system or forcibly idling the tasks
> (using blocking states or freezers or something) so the scheduler can
> suspend from idle is something to be discussed,

So what happens if you task is CPU bound and gets suspended and is
holding a resource (lock, whatever) that is required by someone else
that didn't get suspended?

That's the classic inversion problem, and is caused by not running
runnable tasks.

>  but the net result is
> that we have to stop a certain set of tasks in such a way that they can
> still receive certain external events ... semantically, this is
> equivalent to not running runnable tasks in my book.

Why would be care about external events? Clearly these apps are ill
behaved, otherwise they would have listened to the environment telling
them to idle.

Why would you try to let buggy apps work as intended instead of break
them as hard as possible? Such policy promotes crappy code since people
get away with it.

>  (Perhaps this whole
> thing is because the word runnable means different things ... I'm
> thinking a task that would consume power ... are you thinking in the
> scheduler R state?)

Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.

> Realistically, the main thing we need to do is stop timers posted
> against the task (which is likely polling in a main loop, that being the
> usual form of easy to write but power crazy app behaviour) from waking
> the task and bringing the system out of suspend (whether from idle or
> forced).

Sure, that same main loop will probably receive a message along the
lines of, 'hey, screen is off, we ought to go sleep'. If after that it
doesn't listen, and more serious messages don't get responded to, simply
kill the thing.

Again, there is no reason what so ever to tolerate broken apps, it only
promotes crappy apps.

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

[Peter Zijlstra]

On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > 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.
> 
> That's rubbish and you know it.  We do software workarounds for hardware
> problems all the time ... try doing a git grep -i errata in arch x86, or
> imagine a USB subsystem that only supported sane standards conforming
> devices: that would have an almost zero intersect with the current USB
> device market.
> 
> The job of the kernel is to accommodate hardware as best it can ...
> sometimes it might not be able to, but most of the time it does a pretty
> good job.

Sure, and if x86 could wake from S3 on a keypress/mouse movement etc..
you could use S3 as idle state.. not sure people would love the
wakeup-latency, but that's a QoS matter.

But if there simply are no suitable wakeup sources from an idle state
(S3 really is nothing more than a hardware idle state) then it might not
be suitable for transparent idle modes and no amount of software hackery
will solve that.

So what I'm saying is, if your hardware can't generate the needed wakeup
events, the auto-suspend stuff won't work either. If it can it can be
implemented as a regular idle mode.

> The facts are that C states and S states are different and are entered
> differently.  For some omap hardware, the power consumption in the
> lowest C state (with all the ancillary power control) is the same as S3,
> that's fine, suspend from idle works as well as suspend to ram modulo
> bad apps. For quite a lot of MSM hardware, the lowest C state power
> consumption is quite a bit above S3. 

Wth is MSM?

But really, why can't existing hardware get shipped with existing hacks,
and for future hardware that does behave we have a proper solution?

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

[Peter Zijlstra]

On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > 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.
> 
> Strange, that's not what I heard as the possible solution.  

<20100527232043.784d5c72@lxorguk.ukuu.org.uk>
<20100528101755.7b5f6b8a@lxorguk.ukuu.org.uk>

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

[Thomas Gleixner]

On Sat, 29 May 2010, James Bottomley wrote:
> The job of the kernel is to accommodate hardware as best it can ...
> sometimes it might not be able to, but most of the time it does a pretty
> good job.
> 
> The facts are that C states and S states are different and are entered
> differently. 

That's an x86'ism which is going away. And that's really completely
irrelevant for the mobile device space. Can we please stop trying to
fix todays x86 based laptop problems? They are simply not fixable.

> For some omap hardware, the power consumption in the
> lowest C state (with all the ancillary power control) is the same as S3,
> that's fine, suspend from idle works as well as suspend to ram modulo
> bad apps. For quite a lot of MSM hardware, the lowest C state power
> consumption is quite a bit above S3.  It's not acceptable to tell those
> people "tough, your battery runs out in 30 minutes because you bought
> the wrong hardware".  We have to figure out how to get to S3 ... whether
> this is from idle or some other mechanism is again a discussion point,
> but not doing it is not an option.

If you'd have read the answers from Alan carefully, then you'd have
noticed that even x86 hardware is getting to the point where OMAP is
today. i.e. support of transparent suspend from idle. If that wouldn't
happen then x86 would be simply unusable for mobile devices. It's that
easy. And we really do _NOT_ care about the existing laptop hardware
which does not provide that because it's a lost case. Not only due to
the missing (or just disabled) wakeup sources, also due to the fact
that you cannot do sensible power management by completely disabling
clock and/or power of unused devices in the chipset. There is a damn
good reason why the mobile space is _NOT_ x86 based at the moment.

Thanks,

	tglx

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

[Florian Mickler]

On Sat, 29 May 2010 20:12:14 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> > 
> > Look, this is getting into the realms of a pointless semantic quibble.
> > The problem is that untrusted tasks need to be forcibly suspended when
> > they have no legitimate work to do and the user hasn't authorised them
> > to continue even if the scheduler sees them as runnable.  Whether that's
> > achieved by suspending the entire system or forcibly idling the tasks
> > (using blocking states or freezers or something) so the scheduler can
> > suspend from idle is something to be discussed,
> 
> So what happens if you task is CPU bound and gets suspended and is
> holding a resource (lock, whatever) that is required by someone else
> that didn't get suspended?
> 
> That's the classic inversion problem, and is caused by not running
> runnable tasks.

The trick with the approach currently discussed (i.e.
opportunistic suspend, if you missed it): We suspend the whole machine.

And I really think, this is the only way to do it. It is a big hammer,
shure. But if you can pull it of... 

> 
> >  but the net result is
> > that we have to stop a certain set of tasks in such a way that they can
> > still receive certain external events ... semantically, this is
> > equivalent to not running runnable tasks in my book.
> 
> Why would be care about external events? Clearly these apps are ill
> behaved, otherwise they would have listened to the environment telling
> them to idle.
> 
> Why would you try to let buggy apps work as intended instead of break
> them as hard as possible? Such policy promotes crappy code since people
> get away with it.

If I have a simple shell script then I don't wanna jump through
hoops just to please your fragile kernel. 

And before you judge code that does not behave to work with YOUR buggy
kernel, i would think twice. This cuts both ways. Just because the
problem is too hard for you, this does not excuse forcing crappy
kernels on other people. 

I think you have a point in that it is _in general_ not easily
possible to solve. But for this case this is clearly a simple, to the
point and working solution for android based phones. 

"Der Wurm muss dem Fisch schmecken, nicht dem Angler." 

> 
> >  (Perhaps this whole
> > thing is because the word runnable means different things ... I'm
> > thinking a task that would consume power ... are you thinking in the
> > scheduler R state?)
> 
> Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.
> 
> > Realistically, the main thing we need to do is stop timers posted
> > against the task (which is likely polling in a main loop, that being the
> > usual form of easy to write but power crazy app behaviour) from waking
> > the task and bringing the system out of suspend (whether from idle or
> > forced).
> 
> Sure, that same main loop will probably receive a message along the
> lines of, 'hey, screen is off, we ought to go sleep'. If after that it
> doesn't listen, and more serious messages don't get responded to, simply
> kill the thing.

I think this would be a possibility. And maybe even sane. But I also
think this has nothing to do with suspend_blockers. They block
suspend. You know?   

> 
> Again, there is no reason what so ever to tolerate broken apps, it only
> promotes crappy apps.
> 

This simple doesn't solve the problem.

Cheers,
Flo 

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

[Florian Mickler]

On Mon, 31 May 2010 22:12:19 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Sat, 29 May 2010 20:12:14 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > Why would you try to let buggy apps work as intended instead of break
> > them as hard as possible? Such policy promotes crappy code since people
> > get away with it.
> 
> If I have a simple shell script then I don't wanna jump through
> hoops just to please your fragile kernel. 

Also why should that code on one device kill my uptime and on the
other machine (my wall-plugged desktop) work just well? That doesn't
sound right.

Clearly opportunistic suspend is a workaround for battery-driven devices
and no general solution. But it is not specific to android. At least
not inherently. It could be useful for any embedded or mobile device
where you can clearly distinguish important functions from convenience
functions.

I really can't understand the whole _fundamental_ opposition to this
design choice. 

Cheers,
Flo

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

[Florian Mickler]

Hi, again!

My two mails were probably a bit pointless and not helping to
find a solution. 

There are notable and useful approaches mentioned by Peter to the
mitigation problem. It's just that it's not the one and only way to
think about this.

Just rants,
Flo 

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

[Felipe Contreras]

On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian@mickler.org> wrote:
> On Mon, 31 May 2010 22:12:19 +0200
> Florian Mickler <florian@mickler.org> wrote:
>> If I have a simple shell script then I don't wanna jump through
>> hoops just to please your fragile kernel.
>
> Also why should that code on one device kill my uptime and on the
> other machine (my wall-plugged desktop) work just well? That doesn't
> sound right.

Sounds perfectly right to me; one code runs perfectly fine on one
machine, and on the other doesn't even compile. Well, sure, it wasn't
written with that use-case in mind.

> Clearly opportunistic suspend is a workaround for battery-driven devices
> and no general solution. But it is not specific to android. At least
> not inherently. It could be useful for any embedded or mobile device
> where you can clearly distinguish important functions from convenience
> functions.

Yes, it could, but why go for the hacky solution when we know how to
achieve the ideal one?

> I really can't understand the whole _fundamental_ opposition to this
> design choice.

Nobody is using it, except Android. Nobody will use it, except Android.

I have seen recent proposals that don't require changing the whole
user-space. That might actually be used by other players.

-- 
Felipe Contreras

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

[Rafael J. Wysocki]

On Saturday 05 June 2010, Felipe Contreras wrote:
> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian@mickler.org> wrote:
> > On Mon, 31 May 2010 22:12:19 +0200
> > Florian Mickler <florian@mickler.org> wrote:
> >> If I have a simple shell script then I don't wanna jump through
> >> hoops just to please your fragile kernel.
> >
> > Also why should that code on one device kill my uptime and on the
> > other machine (my wall-plugged desktop) work just well? That doesn't
> > sound right.
> 
> Sounds perfectly right to me; one code runs perfectly fine on one
> machine, and on the other doesn't even compile. Well, sure, it wasn't
> written with that use-case in mind.
> 
> > Clearly opportunistic suspend is a workaround for battery-driven devices
> > and no general solution. But it is not specific to android. At least
> > not inherently. It could be useful for any embedded or mobile device
> > where you can clearly distinguish important functions from convenience
> > functions.
> 
> Yes, it could, but why go for the hacky solution when we know how to
> achieve the ideal one?
> 
> > I really can't understand the whole _fundamental_ opposition to this
> > design choice.
> 
> Nobody is using it, except Android. Nobody will use it, except Android.

That's like saying "Android is not a legitimate user of the kernel".  Is that
you wanted to say?

> I have seen recent proposals that don't require changing the whole
> user-space. That might actually be used by other players.

Sure, an approach benefitting more platforms than just Android would be better,
but saying that the kernel shouldn't address the Android's specific needs as a
rule if no one else has those needs too is quite too far reaching to me.

Rafael

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

[Peter Zijlstra]

On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
> 
> > I have seen recent proposals that don't require changing the whole
> > user-space. That might actually be used by other players.
> 
> Sure, an approach benefitting more platforms than just Android would be better,
> but saying that the kernel shouldn't address the Android's specific needs as a
> rule if no one else has those needs too is quite too far reaching to me. 

Well, if the android people keep rejecting all sensible approaches to
power savings except their suspend blocker mess, then I don't see why we
should support their ill designed mess.

We should strive to provide an interface that can be used by all
interested parties to conserve power; if Android really is the only
possible user of the interface then I don't see any reason at all to
merge it, they might as well keep it in their private tree.

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

[Rafael J. Wysocki]

On Saturday 05 June 2010, Peter Zijlstra wrote:
> On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
> > 
> > > I have seen recent proposals that don't require changing the whole
> > > user-space. That might actually be used by other players.
> > 
> > Sure, an approach benefitting more platforms than just Android would be better,
> > but saying that the kernel shouldn't address the Android's specific needs as a
> > rule if no one else has those needs too is quite too far reaching to me. 
> 
> Well, if the android people keep rejecting all sensible approaches to
> power savings except their suspend blocker mess, then I don't see why we
> should support their ill designed mess.

Well, I certainly would like the Android people to be more appreciative of our
ideas if they expect reciprocity.

> We should strive to provide an interface that can be used by all
> interested parties to conserve power; if Android really is the only
> possible user of the interface then I don't see any reason at all to
> merge it, they might as well keep it in their private tree.

There is a number of kernel users that depend on Android user space
(phone vendors using Android on their hardware, but providing their own
drivers), so I don't think we really can identify Android with Google in that
respect.

Rafael

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

[Peter Zijlstra]

On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote:
> 
> There is a number of kernel users that depend on Android user space
> (phone vendors using Android on their hardware, but providing their own
> drivers), so I don't think we really can identify Android with Google in that
> respect.

I don't see why we can't merge the platform code and drivers without
suspend blockers. Google can patch them back in on their side if they
want to.

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

[Felipe Contreras]

On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday 05 June 2010, Felipe Contreras wrote:
>> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian@mickler.org> wrote:
>> > On Mon, 31 May 2010 22:12:19 +0200
>> > Florian Mickler <florian@mickler.org> wrote:
>> >> If I have a simple shell script then I don't wanna jump through
>> >> hoops just to please your fragile kernel.
>> >
>> > Also why should that code on one device kill my uptime and on the
>> > other machine (my wall-plugged desktop) work just well? That doesn't
>> > sound right.
>>
>> Sounds perfectly right to me; one code runs perfectly fine on one
>> machine, and on the other doesn't even compile. Well, sure, it wasn't
>> written with that use-case in mind.
>>
>> > Clearly opportunistic suspend is a workaround for battery-driven devices
>> > and no general solution. But it is not specific to android. At least
>> > not inherently. It could be useful for any embedded or mobile device
>> > where you can clearly distinguish important functions from convenience
>> > functions.
>>
>> Yes, it could, but why go for the hacky solution when we know how to
>> achieve the ideal one?
>>
>> > I really can't understand the whole _fundamental_ opposition to this
>> > design choice.
>>
>> Nobody is using it, except Android. Nobody will use it, except Android.
>
> That's like saying "Android is not a legitimate user of the kernel".  Is that
> you wanted to say?

Read the context: opportunistic suspend, which is considered a
workaround, which requires new user-space API for suspend blockers,
might be remotely considered for inclusion *if* it indeed solves a
problem for battery-driven devices, which other parties also
experience and could benefit from this solution.

The answer: no, it doesn't: only Android user-space will benefit from it.

>> I have seen recent proposals that don't require changing the whole
>> user-space. That might actually be used by other players.
>
> Sure, an approach benefitting more platforms than just Android would be better,
> but saying that the kernel shouldn't address the Android's specific needs as a
> rule if no one else has those needs too is quite too far reaching to me.

There are no Android specific needs, why should certain user-space
ecosystem need certain API that somehow *nobody* else does? I think in
this huge thread it has become obvious that people are reluctant to
this idea... whatever problem Android user-space presents (I don't
think there's any), it can be solved for "he rest of the world" too,
and such generic solution is worth exploring.

-- 
Felipe Contreras
_______________________________________________
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)

[James Bottomley]

On Sat, 2010-05-29 at 20:12 +0200, Peter Zijlstra wrote:
> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> > 
> > Look, this is getting into the realms of a pointless semantic quibble.
> > The problem is that untrusted tasks need to be forcibly suspended when
> > they have no legitimate work to do and the user hasn't authorised them
> > to continue even if the scheduler sees them as runnable.  Whether that's
> > achieved by suspending the entire system or forcibly idling the tasks
> > (using blocking states or freezers or something) so the scheduler can
> > suspend from idle is something to be discussed,
> 
> So what happens if you task is CPU bound and gets suspended and is
> holding a resource (lock, whatever) that is required by someone else
> that didn't get suspended?
> 
> That's the classic inversion problem, and is caused by not running
> runnable tasks.

OK ... but if the options are running and S3 for the entire platform,
then all tasks get suspended and this isn't a problem.  This is why the
current wakelock implementation on the android platform works flawlessly
today.

Inversion only becomes a problem if tasks get individually idled, so you
can see that, from the android point of view, we're creating a problem
which their implementation doesn't have.

In this view, S3 suspend does look elegant: it solves the inversion
problem by suspending everything, it controls rogue applications' power
consumption and it gets certain hardware into a lower power state than
is possible from suspend from idle.

The inelegance of the S3 suspend solution is the requirement to use
these suspend blockers through kernel and user space to get the whole
thing up again to respond to an event, which is an inelegance suspend
from idle doesn't have.

> >  but the net result is
> > that we have to stop a certain set of tasks in such a way that they can
> > still receive certain external events ... semantically, this is
> > equivalent to not running runnable tasks in my book.
> 
> Why would be care about external events? Clearly these apps are ill
> behaved, otherwise they would have listened to the environment telling
> them to idle.

That's not a correct characterisation.  Badly behaved apps from a power
point of view can do useful things for the user.  The object is to
contain the badness while still getting useful stuff done.

> Why would you try to let buggy apps work as intended instead of break
> them as hard as possible? Such policy promotes crappy code since people
> get away with it.
> 
> >  (Perhaps this whole
> > thing is because the word runnable means different things ... I'm
> > thinking a task that would consume power ... are you thinking in the
> > scheduler R state?)
> 
> Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.
> 
> > Realistically, the main thing we need to do is stop timers posted
> > against the task (which is likely polling in a main loop, that being the
> > usual form of easy to write but power crazy app behaviour) from waking
> > the task and bringing the system out of suspend (whether from idle or
> > forced).
> 
> Sure, that same main loop will probably receive a message along the
> lines of, 'hey, screen is off, we ought to go sleep'. If after that it
> doesn't listen, and more serious messages don't get responded to, simply
> kill the thing.
> 
> Again, there is no reason what so ever to tolerate broken apps, it only
> promotes crappy apps.

Actually, no, if this were a correct view, we wouldn't have the huge x86
hardware work around problem because we'd just be able to tell
manufacturers of shoddy or badly standards compliant stuff where to
stick it.

The great strength of the x86 commodity platform revolution was the fact
that the hardware became cheap, plentiful and outside the ambit of a
single walled garden manufacturer.  It's great weakness is integration
problems and shoddy hardware.  We tolerate the weakness because the
strength vastly outweighs it: and toleration to us in the kernel means
driver work arounds ... it also means that if a device doesn't work with
the kernel, we get blamed (rather than the manufacturer).

By the same token, the revolution in smart phones is driven in quite a
large part by the provision of third party applications.  This commodity
app view is almost the direct software analogue of the commodity
platform view that has been so successful in hardware; Therefore, fair
play seems to demand that we don't draw a hard line for software
applications that we wouldn't draw for hardware devices.

James

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

[Rafael J. Wysocki]

On Saturday 29 May 2010, Peter Zijlstra wrote:
> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> > 
> > Look, this is getting into the realms of a pointless semantic quibble.
> > The problem is that untrusted tasks need to be forcibly suspended when
> > they have no legitimate work to do and the user hasn't authorised them
> > to continue even if the scheduler sees them as runnable.  Whether that's
> > achieved by suspending the entire system or forcibly idling the tasks
> > (using blocking states or freezers or something) so the scheduler can
> > suspend from idle is something to be discussed,
> 
> So what happens if you task is CPU bound and gets suspended and is
> holding a resource (lock, whatever) that is required by someone else
> that didn't get suspended?
> 
> That's the classic inversion problem, and is caused by not running
> runnable tasks.

That, among other things, is why suspend uses the freezer which guarantees
that nothing like this will happen.

> >  but the net result is
> > that we have to stop a certain set of tasks in such a way that they can
> > still receive certain external events ... semantically, this is
> > equivalent to not running runnable tasks in my book.
> 
> Why would be care about external events? Clearly these apps are ill
> behaved, otherwise they would have listened to the environment telling
> them to idle.
> 
> Why would you try to let buggy apps work as intended instead of break
> them as hard as possible? Such policy promotes crappy code since people
> get away with it.

Yeah, and that's why Windows owns desktop market. ;-)

> >  (Perhaps this whole
> > thing is because the word runnable means different things ... I'm
> > thinking a task that would consume power ... are you thinking in the
> > scheduler R state?)
> 
> Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.
> 
> > Realistically, the main thing we need to do is stop timers posted
> > against the task (which is likely polling in a main loop, that being the
> > usual form of easy to write but power crazy app behaviour) from waking
> > the task and bringing the system out of suspend (whether from idle or
> > forced).
> 
> Sure, that same main loop will probably receive a message along the
> lines of, 'hey, screen is off, we ought to go sleep'. If after that it
> doesn't listen, and more serious messages don't get responded to, simply
> kill the thing.
> 
> Again, there is no reason what so ever to tolerate broken apps, it only
> promotes crappy apps.

Do you realistically think that by hurting the _user_ you will make the
_developer_ write better code?  No, really.

If the user likes the app very much (or depends on it or whatever makes him
use it), he will rather switch the platform to one that allows him to run that
app without _visible_ problems than complain to the developer, because _the_
_user_ _doesn't_ _realize_ that the app is broken.  From the user's
perspective, the platform that has problems with the app is broken, because
the app apparently runs without problems on concurrent platforms.

The whole "no reason to tolerate broken apps" midset is simply misguided IMO,
because it's based on unrealistic assumptions.  That's because in general users
only need the platform for running apps they like (or need or whatever).  If
they can't run apps they like on a given platform, or it is too painful to them
to run their apps on it, they will rather switch to another platform than stop
using the apps.

Thanks,
Rafael

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

[Felipe Contreras]

On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Do you realistically think that by hurting the _user_ you will make the
> _developer_ write better code?  No, really.

As an application writer, if my users complain that their battery is
being drained (as it happened), they stop using it, and other people
see there are problems, so they stop using it, if people get angry
about it they will vote it down.

New users will see it has low score; they will not install it. That's
a network effect.

Having users is the quintessential reason people write code.

> If the user likes the app very much (or depends on it or whatever makes him
> use it), he will rather switch the platform to one that allows him to run that
> app without _visible_ problems than complain to the developer, because _the_
> _user_ _doesn't_ _realize_ that the app is broken.  From the user's
> perspective, the platform that has problems with the app is broken, because
> the app apparently runs without problems on concurrent platforms.

Yeah, right. I don't think anybody has every bought an iPhone because
of Tweetie. People care how the applications run on their phones, not
how their phone's platform runs their favorite application, in fact,
most probably it became their favorite application because it was
running great on their phone, and they wouldn't expect it to run on
phones with other platforms. Either applications run on S60, iPhone
OS, Android, or Maemo, but not in a combination of those. And if their
certain app that runs on multiple platforms, and the user actually
knows that (probably a geek), then he knows he can't expect it to work
exactly the same.

> The whole "no reason to tolerate broken apps" midset is simply misguided IMO,
> because it's based on unrealistic assumptions.  That's because in general users
> only need the platform for running apps they like (or need or whatever).  If
> they can't run apps they like on a given platform, or it is too painful to them
> to run their apps on it, they will rather switch to another platform than stop
> using the apps.

You seriously think people switch high-end phones just to run their
favorite apps? It's much cheaper to switch apps, and that's what users
do.

-- 
Felipe Contreras
_______________________________________________
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)

[Florian Mickler]

On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Do you realistically think that by hurting the _user_ you will make the
> > _developer_ write better code?  No, really.
> 
> As an application writer, if my users complain that their battery is
> being drained (as it happened), they stop using it, and other people
> see there are problems, so they stop using it, if people get angry
> about it they will vote it down.
> 
> New users will see it has low score; they will not install it. That's
> a network effect.
> 
> Having users is the quintessential reason people write code.
> 

That is nice. But how does it impact the problem that suspend blockers
solve? And why do suspend blockers interfere with that?

Cheers,
Flo

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

[Felipe Contreras]

On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler <florian@mickler.org> wrote:
> On Sat, 5 Jun 2010 20:16:33 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> New users will see it has low score; they will not install it. That's
>> a network effect.
>>
>> Having users is the quintessential reason people write code.
>
> That is nice. But how does it impact the problem that suspend blockers
> solve? And why do suspend blockers interfere with that?

It doesn't, I don't know why people keep bringing this argument, I
just though it should not be left open as a valid one.

I should have mentioned that this is indeed irrelevant.

-- 
Felipe Contreras

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

[Florian Mickler]

On Sat, 5 Jun 2010 22:56:45 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler <florian@mickler.org> wrote:
> > On Sat, 5 Jun 2010 20:16:33 +0300
> > Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >> New users will see it has low score; they will not install it. That's
> >> a network effect.
> >>
> >> Having users is the quintessential reason people write code.
> >
> > That is nice. But how does it impact the problem that suspend blockers
> > solve? And why do suspend blockers interfere with that?
> 
> It doesn't, I don't know why people keep bringing this argument, I
> just though it should not be left open as a valid one.
> 
> I should have mentioned that this is indeed irrelevant.
> 

Uh! I found out how this is relevant to the suspend blockers case.
Because not having users means that the bugs don't get fixed.
Whereas in the suspend blockers case the users can use the app and get
the bugs fixed. 

Cheers,
Flo

p.s.: I really wished you would focus more on solving the
problem and not on dismissing it.

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

[James Bottomley]

On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote:
> On Sat, 29 May 2010, James Bottomley wrote:
> > The job of the kernel is to accommodate hardware as best it can ...
> > sometimes it might not be able to, but most of the time it does a pretty
> > good job.
> > 
> > The facts are that C states and S states are different and are entered
> > differently. 
> 
> That's an x86'ism which is going away. And that's really completely
> irrelevant for the mobile device space. Can we please stop trying to
> fix todays x86 based laptop problems? They are simply not fixable.

You're the one mentioning x86, not me.  I already explained that some
MSM hardware (the G1 for example) has lower power consumption in S3
(which I'm using as an ACPI shorthand for suspend to ram) than any
suspend from idle C state.  The fact that current x86 hardware has the
same problem may be true, but it's not entirely relevant.

> > For some omap hardware, the power consumption in the
> > lowest C state (with all the ancillary power control) is the same as S3,
> > that's fine, suspend from idle works as well as suspend to ram modulo
> > bad apps. For quite a lot of MSM hardware, the lowest C state power
> > consumption is quite a bit above S3.  It's not acceptable to tell those
> > people "tough, your battery runs out in 30 minutes because you bought
> > the wrong hardware".  We have to figure out how to get to S3 ... whether
> > this is from idle or some other mechanism is again a discussion point,
> > but not doing it is not an option.
> 
> If you'd have read the answers from Alan carefully, then you'd have
> noticed that even x86 hardware is getting to the point where OMAP is
> today. i.e. support of transparent suspend from idle. If that wouldn't
> happen then x86 would be simply unusable for mobile devices. It's that
> easy. And we really do _NOT_ care about the existing laptop hardware
> which does not provide that because it's a lost case. Not only due to
> the missing (or just disabled) wakeup sources, also due to the fact
> that you cannot do sensible power management by completely disabling
> clock and/or power of unused devices in the chipset. There is a damn
> good reason why the mobile space is _NOT_ x86 based at the moment.

So not at all interested in x86 at the moment.

For MSM hardware, it looks possible to unify the S and C states by doing
suspend to ram from idle but I'm not sure how much work that is.

James

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

[Thomas Gleixner]

On Mon, 31 May 2010, James Bottomley wrote:
> 
> For MSM hardware, it looks possible to unify the S and C states by doing
> suspend to ram from idle but I'm not sure how much work that is.

On ARM, it's not rocket science and we have in tree support for this
already (OMAP). I have done the same thing on a Samsung part as a
prove of concept two years ago and it's really easy as the hardware is
sane. Hint: It's designed for mobile devices :)

Thanks,

	tglx

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

[Thomas Gleixner]

On Mon, 31 May 2010, James Bottomley wrote:

> On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote:
> > On Sat, 29 May 2010, James Bottomley wrote:
> > > The job of the kernel is to accommodate hardware as best it can ...
> > > sometimes it might not be able to, but most of the time it does a pretty
> > > good job.
> > > 
> > > The facts are that C states and S states are different and are entered
> > > differently. 
> > 
> > That's an x86'ism which is going away. And that's really completely
> > irrelevant for the mobile device space. Can we please stop trying to
> > fix todays x86 based laptop problems? They are simply not fixable.
> 
> You're the one mentioning x86, not me.  I already explained that some
> MSM hardware (the G1 for example) has lower power consumption in S3
> (which I'm using as an ACPI shorthand for suspend to ram) than any
> suspend from idle C state.

Those machines can go from idle into S2RAM just fine w/o touching the
/sys/power/state S2RAM mechanism.

It's just a deeper "C" state, really.

The confusion is that S3 is considered to be a complete different
mechanism - which is true for PC style x86 - but not relevant for
hardware which is sane from the PM point of view.

Now some people think, that suspend blockers are a cure for the
existing x86/ACPI/BIOS mess, which cannot go to S3 from idle, but
that's simply not feasible.

Thanks,

	tglx

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

[Arve Hjønnevåg]

On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 31 May 2010, James Bottomley wrote:
>>
>> For MSM hardware, it looks possible to unify the S and C states by doing
>> suspend to ram from idle but I'm not sure how much work that is.
>
> On ARM, it's not rocket science and we have in tree support for this
> already (OMAP). I have done the same thing on a Samsung part as a
> prove of concept two years ago and it's really easy as the hardware is
> sane. Hint: It's designed for mobile devices :)
>

We already enter the same power state from idle and suspend on msm. In
the absence of misbehaving apps, the difference in power consumption
is entirely caused by periodic timers in the user-space framework
_and_ kernel. It only takes a few timers triggering per second (I
think 3 if they do no work) to double the average power consumption on
the G1 if the radio is off. We originally added wakelocks because the
hardware we had at the time had much lower power consumption in
suspend then idle, but we still use suspend because it saves power.

-- 
Arve Hjønnevåg

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1432 bytes --]


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

> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 31 May 2010, James Bottomley wrote:
> >>
> >> For MSM hardware, it looks possible to unify the S and C states by doing
> >> suspend to ram from idle but I'm not sure how much work that is.
> >
> > On ARM, it's not rocket science and we have in tree support for this
> > already (OMAP). I have done the same thing on a Samsung part as a
> > prove of concept two years ago and it's really easy as the hardware is
> > sane. Hint: It's designed for mobile devices :)
> >
> 
> We already enter the same power state from idle and suspend on msm. In
> the absence of misbehaving apps, the difference in power consumption
> is entirely caused by periodic timers in the user-space framework
> _and_ kernel. It only takes a few timers triggering per second (I
> think 3 if they do no work) to double the average power consumption on
> the G1 if the radio is off. We originally added wakelocks because the
> hardware we had at the time had much lower power consumption in
> suspend then idle, but we still use suspend because it saves power.

So how do you differentiate between timers which _should_ fire and
those you do not care about ?

We have mechanisms in place to defer timers so the wakeups are
minimized. If that's not enough we need to revisit.

Thanks,

	tglx


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Arve Hjønnevåg]

2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
>
> On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>
>> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Mon, 31 May 2010, James Bottomley wrote:
>> >>
>> >> For MSM hardware, it looks possible to unify the S and C states by doing
>> >> suspend to ram from idle but I'm not sure how much work that is.
>> >
>> > On ARM, it's not rocket science and we have in tree support for this
>> > already (OMAP). I have done the same thing on a Samsung part as a
>> > prove of concept two years ago and it's really easy as the hardware is
>> > sane. Hint: It's designed for mobile devices :)
>> >
>>
>> We already enter the same power state from idle and suspend on msm. In
>> the absence of misbehaving apps, the difference in power consumption
>> is entirely caused by periodic timers in the user-space framework
>> _and_ kernel. It only takes a few timers triggering per second (I
>> think 3 if they do no work) to double the average power consumption on
>> the G1 if the radio is off. We originally added wakelocks because the
>> hardware we had at the time had much lower power consumption in
>> suspend then idle, but we still use suspend because it saves power.
>
> So how do you differentiate between timers which _should_ fire and
> those you do not care about ?
>

Only alarms are allowed to fire while suspended.

> We have mechanisms in place to defer timers so the wakeups are
> minimized. If that's not enough we need to revisit.
>

Deferring the the timers forever without stopping the clock can cause
problems. Our user space code has a lot of timeouts that will trigger
an error if an app does not respond in time. Freezing everything and
stopping the clock while suspended is a lot simpler than trying to
stop individual timers and processes from running.


-- 
Arve Hjønnevåg

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2257 bytes --]

On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
> >
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> > On Mon, 31 May 2010, James Bottomley wrote:
> >> >>
> >> >> For MSM hardware, it looks possible to unify the S and C states by doing
> >> >> suspend to ram from idle but I'm not sure how much work that is.
> >> >
> >> > On ARM, it's not rocket science and we have in tree support for this
> >> > already (OMAP). I have done the same thing on a Samsung part as a
> >> > prove of concept two years ago and it's really easy as the hardware is
> >> > sane. Hint: It's designed for mobile devices :)
> >> >
> >>
> >> We already enter the same power state from idle and suspend on msm. In
> >> the absence of misbehaving apps, the difference in power consumption
> >> is entirely caused by periodic timers in the user-space framework
> >> _and_ kernel. It only takes a few timers triggering per second (I
> >> think 3 if they do no work) to double the average power consumption on
> >> the G1 if the radio is off. We originally added wakelocks because the
> >> hardware we had at the time had much lower power consumption in
> >> suspend then idle, but we still use suspend because it saves power.
> >
> > So how do you differentiate between timers which _should_ fire and
> > those you do not care about ?
> >
> 
> Only alarms are allowed to fire while suspended.
> 
> > We have mechanisms in place to defer timers so the wakeups are
> > minimized. If that's not enough we need to revisit.
> >
> 
> Deferring the the timers forever without stopping the clock can cause
> problems. Our user space code has a lot of timeouts that will trigger
> an error if an app does not respond in time. Freezing everything and
> stopping the clock while suspended is a lot simpler than trying to
> stop individual timers and processes from running.

And resume updates timekeeping to account for the slept time. So the
only way to get away with that is to sleep under a second or just
ignoring the update by avoiding the access to rtc. 

So how do you keep timekeeping happy ?

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Arve Hjønnevåg]

2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
> On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
>> >
>> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> >> > On Mon, 31 May 2010, James Bottomley wrote:
>> >> >>
>> >> >> For MSM hardware, it looks possible to unify the S and C states by doing
>> >> >> suspend to ram from idle but I'm not sure how much work that is.
>> >> >
>> >> > On ARM, it's not rocket science and we have in tree support for this
>> >> > already (OMAP). I have done the same thing on a Samsung part as a
>> >> > prove of concept two years ago and it's really easy as the hardware is
>> >> > sane. Hint: It's designed for mobile devices :)
>> >> >
>> >>
>> >> We already enter the same power state from idle and suspend on msm. In
>> >> the absence of misbehaving apps, the difference in power consumption
>> >> is entirely caused by periodic timers in the user-space framework
>> >> _and_ kernel. It only takes a few timers triggering per second (I
>> >> think 3 if they do no work) to double the average power consumption on
>> >> the G1 if the radio is off. We originally added wakelocks because the
>> >> hardware we had at the time had much lower power consumption in
>> >> suspend then idle, but we still use suspend because it saves power.
>> >
>> > So how do you differentiate between timers which _should_ fire and
>> > those you do not care about ?
>> >
>>
>> Only alarms are allowed to fire while suspended.
>>
>> > We have mechanisms in place to defer timers so the wakeups are
>> > minimized. If that's not enough we need to revisit.
>> >
>>
>> Deferring the the timers forever without stopping the clock can cause
>> problems. Our user space code has a lot of timeouts that will trigger
>> an error if an app does not respond in time. Freezing everything and
>> stopping the clock while suspended is a lot simpler than trying to
>> stop individual timers and processes from running.
>
> And resume updates timekeeping to account for the slept time. So the

No, for the monotonic clock it does the opposite. The hardware clock
is read on resume and the offset is set so the monotonic clock gets
the same value as it had when suspend was called.

> only way to get away with that is to sleep under a second or just
> ignoring the update by avoiding the access to rtc.
>
> So how do you keep timekeeping happy ?
>

-- 
Arve Hjønnevåg

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 843 bytes --]

On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >> Deferring the the timers forever without stopping the clock can cause
> >> problems. Our user space code has a lot of timeouts that will trigger
> >> an error if an app does not respond in time. Freezing everything and
> >> stopping the clock while suspended is a lot simpler than trying to
> >> stop individual timers and processes from running.
> >
> > And resume updates timekeeping to account for the slept time. So the
> 
> No, for the monotonic clock it does the opposite. The hardware clock
> is read on resume and the offset is set so the monotonic clock gets
> the same value as it had when suspend was called.

Grr, yes. Misread the code. -ENOTENOUGHCOFFEE

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Matthew Garrett]

On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:

> You're the one mentioning x86, not me.  I already explained that some
> MSM hardware (the G1 for example) has lower power consumption in S3
> (which I'm using as an ACPI shorthand for suspend to ram) than any
> suspend from idle C state.  The fact that current x86 hardware has the
> same problem may be true, but it's not entirely relevant.

As long as you can set a wakeup timer, an S state is just a C state with 
side effects. The significant one is that entering an S state stops the 
process scheduler and any in-kernel timers. I don't think Google care at 
all about whether suspend is entered through an explicit transition or 
something hooked into cpuidle - the relevant issue is that they want to 
be able to express a set of constraints that lets them control whether 
or not the scheduler keeps on scheduling, and which doesn't let them 
lose wakeup events in the process.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[James Bottomley]

On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> 
> > You're the one mentioning x86, not me.  I already explained that some
> > MSM hardware (the G1 for example) has lower power consumption in S3
> > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > suspend from idle C state.  The fact that current x86 hardware has the
> > same problem may be true, but it's not entirely relevant.
> 
> As long as you can set a wakeup timer, an S state is just a C state with 
> side effects. The significant one is that entering an S state stops the 
> process scheduler and any in-kernel timers. I don't think Google care at 
> all about whether suspend is entered through an explicit transition or 
> something hooked into cpuidle - the relevant issue is that they want to 
> be able to express a set of constraints that lets them control whether 
> or not the scheduler keeps on scheduling, and which doesn't let them 
> lose wakeup events in the process.

Exactly, so my understanding of where we currently are is:

     1. pm_qos will be updated to be able to express the android suspend
        blockers as interactivity constraints (exact name TBD, but
        probably /dev/cpu_interactivity)
     2. pm_qos will be updated to be callable from atomic context
     3. pm_qos will be updated to export statistics initially closely
        matching what suspend blockers provides (simple update of the rw
        interface?)

After this is done, the current android suspend block patch becomes a
re-expression in kernel space in terms of pm_qos, with the current
userspace wakelocks being adapted by the android framework into pm_qos
requirements expressed to /dev/cpu_interactivity (or whatever name is
chosen).  Then opportunistic suspend is either a small add-on kernel
patch they have in their tree to suspend when the interactivity
constraint goes to NONE, or it could be done entirely by a userspace
process.  Long term this could migrate to the freezer and suspend from
idle approach as the various problem timers get fixed.

I think the big unresolved issue is the stats extension.  For android,
we need just a name written along with the value, so we have something
to hang the stats off ... current pm_qos userspace users just write a
value, so the name would be optional.  From the kernel, we probably just
need an additional API that takes a stats name or NULL if none
(pm_qos_add_request_named()?).  Then reading the stats could be done by
implementing a fops read routine on the misc device.

Did I miss anything?

James

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

[David Brownell]

--- On Tue, 6/1/10, James Bottomley <James.Bottomley@suse.de> wrote:

> > As long as you can set a wakeup timer, an S state is just a C state with 
> > side effects.

I've seen similar statements on this endless
thread before; they're not quite true...


> > The significant one is that entering an
> > S state stops the process scheduler and
> > any in-kernel timers.

There's a structural difference too, related
to peripheral device activity and power states.

Specifically, peripherals can be active in C
states (erforming I/O, maybe with DMA etc) and
 will in general not be in lowest power states
(PCI etc).  Whereas entry to ACPI S-states
involves calling the AML code to put those
peripherals into lowest power modes ... ones
they can't in general enter at run time.  (An
additional task of that bytecode is to activate
any wakeup logic, which again is not generally
functional in except in S-states).


The point being perhaps more that ACPI doesn't
map well to the more power-efficient architectures
(often built on ARM) ... hardware vendors provide
all kinds of PM hooks, and Linux can choose between
them so it's more power-miserly than if it tried
to emulate an ACPI based platform.

I've seen some Linux systems which put DRAM into
self-refresh during certain idle modes, for example,
not just during suspend-to-RAM, if it's known that
no DMA is active.  (Why not save that power if it's
safe?)  Likewise, disable some oscillators and PLLs
if they're not needed (the clock API allows that to
be done regardless of "C-states" etc).

The notion of "suspend" gets introduced on such
systems primarily to match the ACPI-ish models  that
exist ... rather than because they necessarily make
good matches for the hardware.  Which has left a
puzzle:  how and why to use such "suspend" models?

Maybe that's underlying some of the pushback for
the notion of automagic entry to "suspend" states.

- Dave

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

[Rafael J. Wysocki]

On Tuesday 01 June 2010, James Bottomley wrote:
> On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > 
> > > You're the one mentioning x86, not me.  I already explained that some
> > > MSM hardware (the G1 for example) has lower power consumption in S3
> > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > > suspend from idle C state.  The fact that current x86 hardware has the
> > > same problem may be true, but it's not entirely relevant.
> > 
> > As long as you can set a wakeup timer, an S state is just a C state with 
> > side effects. The significant one is that entering an S state stops the 
> > process scheduler and any in-kernel timers. I don't think Google care at 
> > all about whether suspend is entered through an explicit transition or 
> > something hooked into cpuidle - the relevant issue is that they want to 
> > be able to express a set of constraints that lets them control whether 
> > or not the scheduler keeps on scheduling, and which doesn't let them 
> > lose wakeup events in the process.
> 
> Exactly, so my understanding of where we currently are is:

Thanks for the recap.

>      1. pm_qos will be updated to be able to express the android suspend
>         blockers as interactivity constraints (exact name TBD, but
>         probably /dev/cpu_interactivity)

I think that's not been decided yet precisely enough.  I saw a few ideas
here and there in the thread, but which of them are we going to follow?

>      2. pm_qos will be updated to be callable from atomic context
>      3. pm_qos will be updated to export statistics initially closely
>         matching what suspend blockers provides (simple update of the rw
>         interface?)
> 
> After this is done, the current android suspend block patch becomes a
> re-expression in kernel space in terms of pm_qos, with the current
> userspace wakelocks being adapted by the android framework into pm_qos
> requirements expressed to /dev/cpu_interactivity (or whatever name is
> chosen).  Then opportunistic suspend is either a small add-on kernel
> patch they have in their tree to suspend when the interactivity
> constraint goes to NONE, or it could be done entirely by a userspace
> process.  Long term this could migrate to the freezer and suspend from
> idle approach as the various problem timers get fixed.
> 
> I think the big unresolved issue is the stats extension.  For android,
> we need just a name written along with the value, so we have something
> to hang the stats off ... current pm_qos userspace users just write a
> value, so the name would be optional.  From the kernel, we probably just
> need an additional API that takes a stats name or NULL if none
> (pm_qos_add_request_named()?).  Then reading the stats could be done by
> implementing a fops read routine on the misc device.

Is the original idea of having that information in debugfs objectionable?

Rafael

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

[James Bottomley]

On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
> On Tuesday 01 June 2010, James Bottomley wrote:
> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > > 
> > > > You're the one mentioning x86, not me.  I already explained that some
> > > > MSM hardware (the G1 for example) has lower power consumption in S3
> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > > > suspend from idle C state.  The fact that current x86 hardware has the
> > > > same problem may be true, but it's not entirely relevant.
> > > 
> > > As long as you can set a wakeup timer, an S state is just a C state with 
> > > side effects. The significant one is that entering an S state stops the 
> > > process scheduler and any in-kernel timers. I don't think Google care at 
> > > all about whether suspend is entered through an explicit transition or 
> > > something hooked into cpuidle - the relevant issue is that they want to 
> > > be able to express a set of constraints that lets them control whether 
> > > or not the scheduler keeps on scheduling, and which doesn't let them 
> > > lose wakeup events in the process.
> > 
> > Exactly, so my understanding of where we currently are is:
> 
> Thanks for the recap.
> 
> >      1. pm_qos will be updated to be able to express the android suspend
> >         blockers as interactivity constraints (exact name TBD, but
> >         probably /dev/cpu_interactivity)
>
> I think that's not been decided yet precisely enough.  I saw a few ideas
> here and there in the thread, but which of them are we going to follow?

Well, android only needs two states (block and don't block), so that
gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
describe these, but if all we're arguing over is the define name, that's
progress.

The other piece they need is the suspend block name, which comes with
the stats API, and finally we need to decide what the actual constraint
is called (which is how the dev node gets its name) ... 

> >      2. pm_qos will be updated to be callable from atomic context
> >      3. pm_qos will be updated to export statistics initially closely
> >         matching what suspend blockers provides (simple update of the rw
> >         interface?)
> > 
> > After this is done, the current android suspend block patch becomes a
> > re-expression in kernel space in terms of pm_qos, with the current
> > userspace wakelocks being adapted by the android framework into pm_qos
> > requirements expressed to /dev/cpu_interactivity (or whatever name is
> > chosen).  Then opportunistic suspend is either a small add-on kernel
> > patch they have in their tree to suspend when the interactivity
> > constraint goes to NONE, or it could be done entirely by a userspace
> > process.  Long term this could migrate to the freezer and suspend from
> > idle approach as the various problem timers get fixed.
> > 
> > I think the big unresolved issue is the stats extension.  For android,
> > we need just a name written along with the value, so we have something
> > to hang the stats off ... current pm_qos userspace users just write a
> > value, so the name would be optional.  From the kernel, we probably just
> > need an additional API that takes a stats name or NULL if none
> > (pm_qos_add_request_named()?).  Then reading the stats could be done by
> > implementing a fops read routine on the misc device.
> 
> Is the original idea of having that information in debugfs objectionable?

Well ... debugfs is usually used to get around the sysfs rules.  In this
case, pm_qos has a dev interface ... I don't specifically object to
using debugfs, but I don't see any reason to forbid it from being a
simple dev read interface either.

James

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

[Arve Hjønnevåg]

On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
>> On Tuesday 01 June 2010, James Bottomley wrote:
>> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
>> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
>> > >
>> > > > You're the one mentioning x86, not me.  I already explained that some
>> > > > MSM hardware (the G1 for example) has lower power consumption in S3
>> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
>> > > > suspend from idle C state.  The fact that current x86 hardware has the
>> > > > same problem may be true, but it's not entirely relevant.
>> > >
>> > > As long as you can set a wakeup timer, an S state is just a C state with
>> > > side effects. The significant one is that entering an S state stops the
>> > > process scheduler and any in-kernel timers. I don't think Google care at
>> > > all about whether suspend is entered through an explicit transition or
>> > > something hooked into cpuidle - the relevant issue is that they want to
>> > > be able to express a set of constraints that lets them control whether
>> > > or not the scheduler keeps on scheduling, and which doesn't let them
>> > > lose wakeup events in the process.
>> >
>> > Exactly, so my understanding of where we currently are is:
>>
>> Thanks for the recap.
>>
>> >      1. pm_qos will be updated to be able to express the android suspend
>> >         blockers as interactivity constraints (exact name TBD, but
>> >         probably /dev/cpu_interactivity)
>>
>> I think that's not been decided yet precisely enough.  I saw a few ideas
>> here and there in the thread, but which of them are we going to follow?
>
> Well, android only needs two states (block and don't block), so that
> gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
> like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
> describe these, but if all we're arguing over is the define name, that's
> progress.

I think we need separate state constraints for suspend and idle low
power modes. On the msm platform only a subset of the interrupts can
wake up from the low power mode, so we block the use if the low power
mode from idle while other interrupts are enabled. We do not block
suspend however if those interrupts are not marked as wakeup
interrupts. Most constraints that prevent suspend are not hardware
specific and should not prevent entering low power modes from idle. In
other words we may need to prevent low power idle modes while allowing
suspend, and we may need to prevent suspend while allowing low power
idle modes.

It would also be good to not have an implementation that gets slower
and slower the more clients you have. With binary constraints this is
trivial.

>
> The other piece they need is the suspend block name, which comes with
> the stats API, and finally we need to decide what the actual constraint
> is called (which is how the dev node gets its name) ...
>
>> >      2. pm_qos will be updated to be callable from atomic context
>> >      3. pm_qos will be updated to export statistics initially closely
>> >         matching what suspend blockers provides (simple update of the rw
>> >         interface?)

4. It would be useful to change pm_qos_add_request to not allocate
anything so can add constraints from init functions that currently
cannot fail.

>> >
>> > After this is done, the current android suspend block patch becomes a
>> > re-expression in kernel space in terms of pm_qos, with the current
>> > userspace wakelocks being adapted by the android framework into pm_qos
>> > requirements expressed to /dev/cpu_interactivity (or whatever name is
>> > chosen).  Then opportunistic suspend is either a small add-on kernel
>> > patch they have in their tree to suspend when the interactivity
>> > constraint goes to NONE, or it could be done entirely by a userspace
>> > process.  Long term this could migrate to the freezer and suspend from
>> > idle approach as the various problem timers get fixed.
>> >
>> > I think the big unresolved issue is the stats extension.  For android,
>> > we need just a name written along with the value, so we have something
>> > to hang the stats off ... current pm_qos userspace users just write a
>> > value, so the name would be optional.  From the kernel, we probably just
>> > need an additional API that takes a stats name or NULL if none
>> > (pm_qos_add_request_named()?).  Then reading the stats could be done by
>> > implementing a fops read routine on the misc device.
>>
>> Is the original idea of having that information in debugfs objectionable?
>
> Well ... debugfs is usually used to get around the sysfs rules.  In this
> case, pm_qos has a dev interface ... I don't specifically object to
> using debugfs, but I don't see any reason to forbid it from being a
> simple dev read interface either.
>

We don't currently have a dev interface for stats so this is not an
immediate requirement. The suspend blocker debugfs interface is just
as good as the proc interface we have for wakelocks.

-- 
Arve Hjønnevåg

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

[Gross, Mark]

>-----Original Message-----
>From: Arve Hjønnevåg [mailto:arve@android.com]
>Sent: Tuesday, June 01, 2010 6:11 PM
>To: James Bottomley
>Cc: Rafael J. Wysocki; Matthew Garrett; Thomas Gleixner; Peter Zijlstra;
>tytso@mit.edu; LKML; Florian Mickler; Linux PM; Linux OMAP Mailing List;
>felipe.balbi@nokia.com; Alan Cox; Alan Stern; Gross, Mark; Neil Brown
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley@suse.de>
>wrote:
>> On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
>>> On Tuesday 01 June 2010, James Bottomley wrote:
>>> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
>>> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
>>> > >
>>> > > > You're the one mentioning x86, not me.  I already explained that
>some
>>> > > > MSM hardware (the G1 for example) has lower power consumption in
>S3
>>> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
>>> > > > suspend from idle C state.  The fact that current x86 hardware has
>the
>>> > > > same problem may be true, but it's not entirely relevant.
>>> > >
>>> > > As long as you can set a wakeup timer, an S state is just a C state
>with
>>> > > side effects. The significant one is that entering an S state stops
>the
>>> > > process scheduler and any in-kernel timers. I don't think Google
>care at
>>> > > all about whether suspend is entered through an explicit transition
>or
>>> > > something hooked into cpuidle - the relevant issue is that they want
>to
>>> > > be able to express a set of constraints that lets them control
>whether
>>> > > or not the scheduler keeps on scheduling, and which doesn't let them
>>> > > lose wakeup events in the process.
>>> >
>>> > Exactly, so my understanding of where we currently are is:
>>>
>>> Thanks for the recap.
>>>
>>> >      1. pm_qos will be updated to be able to express the android
>suspend
>>> >         blockers as interactivity constraints (exact name TBD, but
>>> >         probably /dev/cpu_interactivity)
>>>
>>> I think that's not been decided yet precisely enough.  I saw a few ideas
>>> here and there in the thread, but which of them are we going to follow?
>>
>> Well, android only needs two states (block and don't block), so that
>> gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
>> like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
>> describe these, but if all we're arguing over is the define name, that's
>> progress.
>
>I think we need separate state constraints for suspend and idle low
>power modes. On the msm platform only a subset of the interrupts can
>wake up from the low power mode, so we block the use if the low power
>mode from idle while other interrupts are enabled. We do not block
>suspend however if those interrupts are not marked as wakeup
>interrupts. Most constraints that prevent suspend are not hardware
>specific and should not prevent entering low power modes from idle. In
>other words we may need to prevent low power idle modes while allowing
>suspend, and we may need to prevent suspend while allowing low power
>idle modes.
>
>It would also be good to not have an implementation that gets slower
>and slower the more clients you have. With binary constraints this is
>trivial.
[mtg: ] agreed.

>
>>
>> The other piece they need is the suspend block name, which comes with
>> the stats API, and finally we need to decide what the actual constraint
>> is called (which is how the dev node gets its name) ...
>>
>>> >      2. pm_qos will be updated to be callable from atomic context
>>> >      3. pm_qos will be updated to export statistics initially closely
>>> >         matching what suspend blockers provides (simple update of the
>rw
>>> >         interface?)
>
>4. It would be useful to change pm_qos_add_request to not allocate
>anything so can add constraints from init functions that currently
>cannot fail.
[mtg: ] I'm not sure how to do this but I agree it would be good.  I guess we could have a block of pm_qos requests pre-allocated statically and re-use them.  In practice there will not be more than a handful of requests ever.  Dynamic allocation does seem like a bit of a waste.

>
>>> >
>>> > After this is done, the current android suspend block patch becomes a
>>> > re-expression in kernel space in terms of pm_qos, with the current
>>> > userspace wakelocks being adapted by the android framework into pm_qos
>>> > requirements expressed to /dev/cpu_interactivity (or whatever name is
>>> > chosen).  Then opportunistic suspend is either a small add-on kernel
>>> > patch they have in their tree to suspend when the interactivity
>>> > constraint goes to NONE, or it could be done entirely by a userspace
>>> > process.  Long term this could migrate to the freezer and suspend from
>>> > idle approach as the various problem timers get fixed.
>>> >
>>> > I think the big unresolved issue is the stats extension.  For android,
>>> > we need just a name written along with the value, so we have something
>>> > to hang the stats off ... current pm_qos userspace users just write a
>>> > value, so the name would be optional.  From the kernel, we probably
>just
>>> > need an additional API that takes a stats name or NULL if none
>>> > (pm_qos_add_request_named()?).  Then reading the stats could be done
>by
>>> > implementing a fops read routine on the misc device.
>>>
>>> Is the original idea of having that information in debugfs
>objectionable?
>>
>> Well ... debugfs is usually used to get around the sysfs rules.  In this
>> case, pm_qos has a dev interface ... I don't specifically object to
>> using debugfs, but I don't see any reason to forbid it from being a
>> simple dev read interface either.
>>
>
>We don't currently have a dev interface for stats so this is not an
>immediate requirement. The suspend blocker debugfs interface is just
>as good as the proc interface we have for wakelocks.
>
>--
>Arve Hjønnevåg

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

[Arve Hjønnevåg]

2010/6/1 Gross, Mark <mark.gross@intel.com>:
...
>>4. It would be useful to change pm_qos_add_request to not allocate
>>anything so can add constraints from init functions that currently
>>cannot fail.
> [mtg: ] I'm not sure how to do this but I agree it would be good.  I guess we could have a block of pm_qos requests pre-allocated statically and re-use them.  In practice there will not be more than a handful of requests ever.  Dynamic allocation does seem like a bit of a waste.

The calling code will have to store a pointer to your structure
anyway, you may as well have them provide the whole structure.

-- 
Arve Hjønnevåg

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

[Gross, Mark]

>-----Original Message-----
>From: Arve Hjønnevåg [mailto:arve@android.com]
>Sent: Tuesday, June 01, 2010 8:15 PM
>To: Gross, Mark
>Cc: James Bottomley; Rafael J. Wysocki; Matthew Garrett; Thomas Gleixner;
>Peter Zijlstra; tytso@mit.edu; LKML; Florian Mickler; Linux PM; Linux OMAP
>Mailing List; felipe.balbi@nokia.com; Alan Cox; Alan Stern; Neil Brown
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>2010/6/1 Gross, Mark <mark.gross@intel.com>:
>...
>>>4. It would be useful to change pm_qos_add_request to not allocate
>>>anything so can add constraints from init functions that currently
>>>cannot fail.
>> [mtg: ] I'm not sure how to do this but I agree it would be good.  I
>guess we could have a block of pm_qos requests pre-allocated statically and
>re-use them.  In practice there will not be more than a handful of requests
>ever.  Dynamic allocation does seem like a bit of a waste.
>
>The calling code will have to store a pointer to your structure
>anyway, you may as well have them provide the whole structure.
[mtg: ] duh!  You are right.  Make the caller's hold the structure.  Its been a long day.  That would be easy todo.

--gmross

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

[James Bottomley]

On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
> >> On Tuesday 01 June 2010, James Bottomley wrote:
> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> >> > >
> >> > > > You're the one mentioning x86, not me.  I already explained that some
> >> > > > MSM hardware (the G1 for example) has lower power consumption in S3
> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> >> > > > suspend from idle C state.  The fact that current x86 hardware has the
> >> > > > same problem may be true, but it's not entirely relevant.
> >> > >
> >> > > As long as you can set a wakeup timer, an S state is just a C state with
> >> > > side effects. The significant one is that entering an S state stops the
> >> > > process scheduler and any in-kernel timers. I don't think Google care at
> >> > > all about whether suspend is entered through an explicit transition or
> >> > > something hooked into cpuidle - the relevant issue is that they want to
> >> > > be able to express a set of constraints that lets them control whether
> >> > > or not the scheduler keeps on scheduling, and which doesn't let them
> >> > > lose wakeup events in the process.
> >> >
> >> > Exactly, so my understanding of where we currently are is:
> >>
> >> Thanks for the recap.
> >>
> >> >      1. pm_qos will be updated to be able to express the android suspend
> >> >         blockers as interactivity constraints (exact name TBD, but
> >> >         probably /dev/cpu_interactivity)
> >>
> >> I think that's not been decided yet precisely enough.  I saw a few ideas
> >> here and there in the thread, but which of them are we going to follow?
> >
> > Well, android only needs two states (block and don't block), so that
> > gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
> > describe these, but if all we're arguing over is the define name, that's
> > progress.
> 
> I think we need separate state constraints for suspend and idle low
> power modes. On the msm platform only a subset of the interrupts can
> wake up from the low power mode, so we block the use if the low power
> mode from idle while other interrupts are enabled. We do not block
> suspend however if those interrupts are not marked as wakeup
> interrupts. Most constraints that prevent suspend are not hardware
> specific and should not prevent entering low power modes from idle. In
> other words we may need to prevent low power idle modes while allowing
> suspend, and we may need to prevent suspend while allowing low power
> idle modes.

Well, as I said, pm_qos is s32 ... it's easy to make the constraint
ternary instead of binary.

> It would also be good to not have an implementation that gets slower
> and slower the more clients you have. With binary constraints this is
> trivial.

Well, that's an implementation detail ... ordering the list or using a
btree would significantly fix that.  However, the most number of
constraint users I've seen in android is around 60 ... that's not huge
from a kernel linear list perspective, so is this really a concern? ...
particularly when most uses don't necessarily change the constrain, so a
list search isn't done.

> > The other piece they need is the suspend block name, which comes with
> > the stats API, and finally we need to decide what the actual constraint
> > is called (which is how the dev node gets its name) ...
> >
> >> >      2. pm_qos will be updated to be callable from atomic context
> >> >      3. pm_qos will be updated to export statistics initially closely
> >> >         matching what suspend blockers provides (simple update of the rw
> >> >         interface?)
> 
> 4. It would be useful to change pm_qos_add_request to not allocate
> anything so can add constraints from init functions that currently
> cannot fail.

Sure .. we do that for the delayed work queues, it's just an API which
takes the structure as an argument leaving it the responsibility of the
caller to free.

> >> > After this is done, the current android suspend block patch becomes a
> >> > re-expression in kernel space in terms of pm_qos, with the current
> >> > userspace wakelocks being adapted by the android framework into pm_qos
> >> > requirements expressed to /dev/cpu_interactivity (or whatever name is
> >> > chosen).  Then opportunistic suspend is either a small add-on kernel
> >> > patch they have in their tree to suspend when the interactivity
> >> > constraint goes to NONE, or it could be done entirely by a userspace
> >> > process.  Long term this could migrate to the freezer and suspend from
> >> > idle approach as the various problem timers get fixed.
> >> >
> >> > I think the big unresolved issue is the stats extension.  For android,
> >> > we need just a name written along with the value, so we have something
> >> > to hang the stats off ... current pm_qos userspace users just write a
> >> > value, so the name would be optional.  From the kernel, we probably just
> >> > need an additional API that takes a stats name or NULL if none
> >> > (pm_qos_add_request_named()?).  Then reading the stats could be done by
> >> > implementing a fops read routine on the misc device.
> >>
> >> Is the original idea of having that information in debugfs objectionable?
> >
> > Well ... debugfs is usually used to get around the sysfs rules.  In this
> > case, pm_qos has a dev interface ... I don't specifically object to
> > using debugfs, but I don't see any reason to forbid it from being a
> > simple dev read interface either.
> >
> 
> We don't currently have a dev interface for stats so this is not an
> immediate requirement. The suspend blocker debugfs interface is just
> as good as the proc interface we have for wakelocks.

OK, great ... what actually exports the statistics is just an
implementation detail. 

James



_______________________________________________
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/6/1 James Bottomley <James.Bottomley@suse.de>:
> On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
>> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley@suse.de> wrote:
>> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
>> >> On Tuesday 01 June 2010, James Bottomley wrote:
>> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
>> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
>> >> > >
>> >> > > > You're the one mentioning x86, not me.  I already explained that some
>> >> > > > MSM hardware (the G1 for example) has lower power consumption in S3
>> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
>> >> > > > suspend from idle C state.  The fact that current x86 hardware has the
>> >> > > > same problem may be true, but it's not entirely relevant.
>> >> > >
>> >> > > As long as you can set a wakeup timer, an S state is just a C state with
>> >> > > side effects. The significant one is that entering an S state stops the
>> >> > > process scheduler and any in-kernel timers. I don't think Google care at
>> >> > > all about whether suspend is entered through an explicit transition or
>> >> > > something hooked into cpuidle - the relevant issue is that they want to
>> >> > > be able to express a set of constraints that lets them control whether
>> >> > > or not the scheduler keeps on scheduling, and which doesn't let them
>> >> > > lose wakeup events in the process.
>> >> >
>> >> > Exactly, so my understanding of where we currently are is:
>> >>
>> >> Thanks for the recap.
>> >>
>> >> >      1. pm_qos will be updated to be able to express the android suspend
>> >> >         blockers as interactivity constraints (exact name TBD, but
>> >> >         probably /dev/cpu_interactivity)
>> >>
>> >> I think that's not been decided yet precisely enough.  I saw a few ideas
>> >> here and there in the thread, but which of them are we going to follow?
>> >
>> > Well, android only needs two states (block and don't block), so that
>> > gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
>> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
>> > describe these, but if all we're arguing over is the define name, that's
>> > progress.
>>
>> I think we need separate state constraints for suspend and idle low
>> power modes. On the msm platform only a subset of the interrupts can
>> wake up from the low power mode, so we block the use if the low power
>> mode from idle while other interrupts are enabled. We do not block
>> suspend however if those interrupts are not marked as wakeup
>> interrupts. Most constraints that prevent suspend are not hardware
>> specific and should not prevent entering low power modes from idle. In
>> other words we may need to prevent low power idle modes while allowing
>> suspend, and we may need to prevent suspend while allowing low power
>> idle modes.
>
> Well, as I said, pm_qos is s32 ... it's easy to make the constraint
> ternary instead of binary.

No, they have to be two separate constraints, otherwise a constraint
to block suspend would override a constraint to block a low power idle
mode or the other way around.

>
>> It would also be good to not have an implementation that gets slower
>> and slower the more clients you have. With binary constraints this is
>> trivial.
>
> Well, that's an implementation detail ... ordering the list or using a

True. I think we also need timeout support in the short term though
which is also somewhat simpler to implement in an efficient way for
binary constraints.

> btree would significantly fix that.  However, the most number of
> constraint users I've seen in android is around 60 ... that's not huge
> from a kernel linear list perspective, so is this really a concern? ...
> particularly when most uses don't necessarily change the constrain, so a
> list search isn't done.

The search is done every time any of them changes.

>
>> > The other piece they need is the suspend block name, which comes with
>> > the stats API, and finally we need to decide what the actual constraint
>> > is called (which is how the dev node gets its name) ...
>> >
>> >> >      2. pm_qos will be updated to be callable from atomic context
>> >> >      3. pm_qos will be updated to export statistics initially closely
>> >> >         matching what suspend blockers provides (simple update of the rw
>> >> >         interface?)
>>
>> 4. It would be useful to change pm_qos_add_request to not allocate
>> anything so can add constraints from init functions that currently
>> cannot fail.
>
> Sure .. we do that for the delayed work queues, it's just an API which
> takes the structure as an argument leaving it the responsibility of the
> caller to free.
>
>> >> > After this is done, the current android suspend block patch becomes a
>> >> > re-expression in kernel space in terms of pm_qos, with the current
>> >> > userspace wakelocks being adapted by the android framework into pm_qos
>> >> > requirements expressed to /dev/cpu_interactivity (or whatever name is
>> >> > chosen).  Then opportunistic suspend is either a small add-on kernel
>> >> > patch they have in their tree to suspend when the interactivity
>> >> > constraint goes to NONE, or it could be done entirely by a userspace
>> >> > process.  Long term this could migrate to the freezer and suspend from
>> >> > idle approach as the various problem timers get fixed.
>> >> >
>> >> > I think the big unresolved issue is the stats extension.  For android,
>> >> > we need just a name written along with the value, so we have something
>> >> > to hang the stats off ... current pm_qos userspace users just write a
>> >> > value, so the name would be optional.  From the kernel, we probably just
>> >> > need an additional API that takes a stats name or NULL if none
>> >> > (pm_qos_add_request_named()?).  Then reading the stats could be done by
>> >> > implementing a fops read routine on the misc device.
>> >>
>> >> Is the original idea of having that information in debugfs objectionable?
>> >
>> > Well ... debugfs is usually used to get around the sysfs rules.  In this
>> > case, pm_qos has a dev interface ... I don't specifically object to
>> > using debugfs, but I don't see any reason to forbid it from being a
>> > simple dev read interface either.
>> >
>>
>> We don't currently have a dev interface for stats so this is not an
>> immediate requirement. The suspend blocker debugfs interface is just
>> as good as the proc interface we have for wakelocks.
>
> OK, great ... what actually exports the statistics is just an
> implementation detail.
>
> James
>
>
>
>



-- 
Arve Hjønnevåg

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

[James Bottomley]

On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> 2010/6/1 James Bottomley <James.Bottomley@suse.de>:
> > On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
> >> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> >> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
> >> >> On Tuesday 01 June 2010, James Bottomley wrote:
> >> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> >> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> >> >> > >
> >> >> > > > You're the one mentioning x86, not me.  I already explained that some
> >> >> > > > MSM hardware (the G1 for example) has lower power consumption in S3
> >> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> >> >> > > > suspend from idle C state.  The fact that current x86 hardware has the
> >> >> > > > same problem may be true, but it's not entirely relevant.
> >> >> > >
> >> >> > > As long as you can set a wakeup timer, an S state is just a C state with
> >> >> > > side effects. The significant one is that entering an S state stops the
> >> >> > > process scheduler and any in-kernel timers. I don't think Google care at
> >> >> > > all about whether suspend is entered through an explicit transition or
> >> >> > > something hooked into cpuidle - the relevant issue is that they want to
> >> >> > > be able to express a set of constraints that lets them control whether
> >> >> > > or not the scheduler keeps on scheduling, and which doesn't let them
> >> >> > > lose wakeup events in the process.
> >> >> >
> >> >> > Exactly, so my understanding of where we currently are is:
> >> >>
> >> >> Thanks for the recap.
> >> >>
> >> >> >      1. pm_qos will be updated to be able to express the android suspend
> >> >> >         blockers as interactivity constraints (exact name TBD, but
> >> >> >         probably /dev/cpu_interactivity)
> >> >>
> >> >> I think that's not been decided yet precisely enough.  I saw a few ideas
> >> >> here and there in the thread, but which of them are we going to follow?
> >> >
> >> > Well, android only needs two states (block and don't block), so that
> >> > gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
> >> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
> >> > describe these, but if all we're arguing over is the define name, that's
> >> > progress.
> >>
> >> I think we need separate state constraints for suspend and idle low
> >> power modes. On the msm platform only a subset of the interrupts can
> >> wake up from the low power mode, so we block the use if the low power
> >> mode from idle while other interrupts are enabled. We do not block
> >> suspend however if those interrupts are not marked as wakeup
> >> interrupts. Most constraints that prevent suspend are not hardware
> >> specific and should not prevent entering low power modes from idle. In
> >> other words we may need to prevent low power idle modes while allowing
> >> suspend, and we may need to prevent suspend while allowing low power
> >> idle modes.
> >
> > Well, as I said, pm_qos is s32 ... it's easy to make the constraint
> > ternary instead of binary.
> 
> No, they have to be two separate constraints, otherwise a constraint
> to block suspend would override a constraint to block a low power idle
> mode or the other way around.

Depends.  If you block the system from going into low power idle, does
that mean you still want it to be fully suspended?

If yes, then we do have independent constraints.  If not, they have a
hierarchy:

      * Fully Interactive (no low power idle or suspend)
      * Partially Interactive (may go into low power idle but not
        suspend)
      * None (may go into low power idle or suspend)

Which is expressable as a ternary constraint.

James


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

[Florian Mickler]

On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley <James.Bottomley@suse.de> wrote:

> On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > No, they have to be two separate constraints, otherwise a constraint
> > to block suspend would override a constraint to block a low power idle
> > mode or the other way around.
> 
> Depends.  If you block the system from going into low power idle, does
> that mean you still want it to be fully suspended?
> 
> If yes, then we do have independent constraints.  If not, they have a
> hierarchy:
> 
>       * Fully Interactive (no low power idle or suspend)
>       * Partially Interactive (may go into low power idle but not
>         suspend)
>       * None (may go into low power idle or suspend)
> 
> Which is expressable as a ternary constraint.
> 
> James
> 

But unblocking suspend at the moment is independent to getting idle.
If you have the requirement to stay in the highest-idle level (i.e.
best latency you can get) that does not (currently) mean, that you can
not suspend.

To preserve that explicit fall-through while still having working
run-time-powermanagement I think the qos-constraints need to be
separated. 

<disclaimer: just from what I read>
Provided you can reach the same power state from idle, current suspend
could probably also be implemented by just the freezing part and a hint
to the idle-loop to provide accelerated fall-through to lowest power. 
</disclaimer>

At that point, you could probably merge the constraints. 

But the freezing part is also the hard part, isn't it? (I have no
idea. Thomas seems to think about cgroups for that and doing smth about the timers.)

Cheers,
Flo

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

[James Bottomley]

On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 10:05:11 -0500
> James Bottomley <James.Bottomley@suse.de> wrote:
> 
> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > > No, they have to be two separate constraints, otherwise a constraint
> > > to block suspend would override a constraint to block a low power idle
> > > mode or the other way around.
> > 
> > Depends.  If you block the system from going into low power idle, does
> > that mean you still want it to be fully suspended?
> > 
> > If yes, then we do have independent constraints.  If not, they have a
> > hierarchy:
> > 
> >       * Fully Interactive (no low power idle or suspend)
> >       * Partially Interactive (may go into low power idle but not
> >         suspend)
> >       * None (may go into low power idle or suspend)
> > 
> > Which is expressable as a ternary constraint.
> > 
> > James
> > 
> 
> But unblocking suspend at the moment is independent to getting idle.
> If you have the requirement to stay in the highest-idle level (i.e.
> best latency you can get) that does not (currently) mean, that you can
> not suspend.

I don't understand that as a reason.  If we looks at this a qos
constraints, you're saying that the system may not drop into certain low
power states because it might turn something off that's currently being
used by a driver or a process.  Suspend is certainly the lowest state of
that because it turns everything off, why would it be legal to drop into
that?

I also couldn't find this notion of separation of idleness power from
suspend blocking in the original suspend block patch set ... if you can
either tell me where it is, or give me an example of the separated use
cases, I'd understand better.

> To preserve that explicit fall-through while still having working
> run-time-powermanagement I think the qos-constraints need to be
> separated. 

OK, as above, why?  or better yet, just give an example.

> <disclaimer: just from what I read>
> Provided you can reach the same power state from idle, current suspend
> could probably also be implemented by just the freezing part and a hint
> to the idle-loop to provide accelerated fall-through to lowest power. 
> </disclaimer>
> 
> At that point, you could probably merge the constraints. 
> 
> But the freezing part is also the hard part, isn't it? (I have no
> idea. Thomas seems to think about cgroups for that and doing smth about the timers.)

Um, well, as I said, I think using suspend from idle and freezer is
longer term.  I think if we express the constraints as qos android can
then use them to gate when to enter S3 .. which is functionally
equivalent to suspend blockers.  And the vanilla kernel can use them to
gate power states for the drivers in suspend from idle.

James


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

On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
>> On Wed, 02 Jun 2010 10:05:11 -0500
>> James Bottomley <James.Bottomley@suse.de> wrote:
>>
>> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
>> > > No, they have to be two separate constraints, otherwise a constraint
>> > > to block suspend would override a constraint to block a low power idle
>> > > mode or the other way around.
>> >
>> > Depends.  If you block the system from going into low power idle, does
>> > that mean you still want it to be fully suspended?
>> >
>> > If yes, then we do have independent constraints.  If not, they have a
>> > hierarchy:
>> >
>> >       * Fully Interactive (no low power idle or suspend)
>> >       * Partially Interactive (may go into low power idle but not
>> >         suspend)
>> >       * None (may go into low power idle or suspend)
>> >
>> > Which is expressable as a ternary constraint.
>> >
>> > James
>> >
>>
>> But unblocking suspend at the moment is independent to getting idle.
>> If you have the requirement to stay in the highest-idle level (i.e.
>> best latency you can get) that does not (currently) mean, that you can
>> not suspend.
>
> I don't understand that as a reason.  If we looks at this a qos
> constraints, you're saying that the system may not drop into certain low
> power states because it might turn something off that's currently being
> used by a driver or a process.  Suspend is certainly the lowest state of
> that because it turns everything off, why would it be legal to drop into
> that?

Because the driver gets called on suspend which gives it a change to
stop using it.

>
> I also couldn't find this notion of separation of idleness power from
> suspend blocking in the original suspend block patch set ... if you can
> either tell me where it is, or give me an example of the separated use
> cases, I'd understand better.
>

The suspend block patchset only deals with suspend, not low power idle
modes. The original wakelock patchset had two wakelock types, idle and
suspend.

>> To preserve that explicit fall-through while still having working
>> run-time-powermanagement I think the qos-constraints need to be
>> separated.
>
> OK, as above, why?  or better yet, just give an example.
>

The i2c bus on the Nexus One is used by the other core to turn off the
power you our core when we enter the lowest power mode. This means
that we cannot enter that low power mode while the i2c bus is active,
so we block low power idle modes. At some point we also tries to block
suspend in this case, but this caused a lot of failed suspend attempts
since the frequency scaling code would try to ramp up while freezing
processes which in turn aborted the process freezing attempts.

>> <disclaimer: just from what I read>
>> Provided you can reach the same power state from idle, current suspend
>> could probably also be implemented by just the freezing part and a hint
>> to the idle-loop to provide accelerated fall-through to lowest power.
>> </disclaimer>
>>
>> At that point, you could probably merge the constraints.
>>
>> But the freezing part is also the hard part, isn't it? (I have no
>> idea. Thomas seems to think about cgroups for that and doing smth about the timers.)
>
> Um, well, as I said, I think using suspend from idle and freezer is
> longer term.  I think if we express the constraints as qos android can
> then use them to gate when to enter S3 .. which is functionally
> equivalent to suspend blockers.  And the vanilla kernel can use them to
> gate power states for the drivers in suspend from idle.
>
> James
>
>
>



-- 
Arve Hjønnevåg

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

[James Bottomley]

On Wed, 2010-06-02 at 15:27 -0700, Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> >> On Wed, 02 Jun 2010 10:05:11 -0500
> >> James Bottomley <James.Bottomley@suse.de> wrote:
> >>
> >> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> >> > > No, they have to be two separate constraints, otherwise a constraint
> >> > > to block suspend would override a constraint to block a low power idle
> >> > > mode or the other way around.
> >> >
> >> > Depends.  If you block the system from going into low power idle, does
> >> > that mean you still want it to be fully suspended?
> >> >
> >> > If yes, then we do have independent constraints.  If not, they have a
> >> > hierarchy:
> >> >
> >> >       * Fully Interactive (no low power idle or suspend)
> >> >       * Partially Interactive (may go into low power idle but not
> >> >         suspend)
> >> >       * None (may go into low power idle or suspend)
> >> >
> >> > Which is expressable as a ternary constraint.
> >> >
> >> > James
> >> >
> >>
> >> But unblocking suspend at the moment is independent to getting idle.
> >> If you have the requirement to stay in the highest-idle level (i.e.
> >> best latency you can get) that does not (currently) mean, that you can
> >> not suspend.
> >
> > I don't understand that as a reason.  If we looks at this a qos
> > constraints, you're saying that the system may not drop into certain low
> > power states because it might turn something off that's currently being
> > used by a driver or a process.  Suspend is certainly the lowest state of
> > that because it turns everything off, why would it be legal to drop into
> > that?
> 
> Because the driver gets called on suspend which gives it a change to
> stop using it.
> 
> >
> > I also couldn't find this notion of separation of idleness power from
> > suspend blocking in the original suspend block patch set ... if you can
> > either tell me where it is, or give me an example of the separated use
> > cases, I'd understand better.
> >
> 
> The suspend block patchset only deals with suspend, not low power idle
> modes. The original wakelock patchset had two wakelock types, idle and
> suspend.

OK, so that explains why I didn't see it ...

> >> To preserve that explicit fall-through while still having working
> >> run-time-powermanagement I think the qos-constraints need to be
> >> separated.
> >
> > OK, as above, why?  or better yet, just give an example.
> >
> 
> The i2c bus on the Nexus One is used by the other core to turn off the
> power you our core when we enter the lowest power mode. This means
> that we cannot enter that low power mode while the i2c bus is active,
> so we block low power idle modes. At some point we also tries to block
> suspend in this case, but this caused a lot of failed suspend attempts
> since the frequency scaling code would try to ramp up while freezing
> processes which in turn aborted the process freezing attempts.

OK, so this is a device specific power constraint state.  I suppose it
makes sense to have a bunch of those, because the device isn't
necessarily going to know what idle power mode it can't go into, so the
cpu govenor should sort it out rather than have the device specify a
minimum state.  

James


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

[Florian Mickler]

On Wed, 02 Jun 2010 15:41:11 -0500
James Bottomley <James.Bottomley@suse.de> wrote:

> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> > On Wed, 02 Jun 2010 10:05:11 -0500
> > James Bottomley <James.Bottomley@suse.de> wrote:
> > 
> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > > > No, they have to be two separate constraints, otherwise a constraint
> > > > to block suspend would override a constraint to block a low power idle
> > > > mode or the other way around.
> > > 
> > > Depends.  If you block the system from going into low power idle, does
> > > that mean you still want it to be fully suspended?
> > > 
> > > If yes, then we do have independent constraints.  If not, they have a
> > > hierarchy:
> > > 
> > >       * Fully Interactive (no low power idle or suspend)
> > >       * Partially Interactive (may go into low power idle but not
> > >         suspend)
> > >       * None (may go into low power idle or suspend)
> > > 
> > > Which is expressable as a ternary constraint.
> > > 
> > > James
> > > 
> > 
> > But unblocking suspend at the moment is independent to getting idle.
> > If you have the requirement to stay in the highest-idle level (i.e.
> > best latency you can get) that does not (currently) mean, that you can
> > not suspend.
> 
> I don't understand that as a reason.  If we looks at this a qos
> constraints, you're saying that the system may not drop into certain low
> power states because it might turn something off that's currently being
> used by a driver or a process.  Suspend is certainly the lowest state of
> that because it turns everything off, why would it be legal to drop into
> that?
> 
> I also couldn't find this notion of separation of idleness power from
> suspend blocking in the original suspend block patch set ... if you can
> either tell me where it is, or give me an example of the separated use
> cases, I'd understand better.
> 
> > To preserve that explicit fall-through while still having working
> > run-time-powermanagement I think the qos-constraints need to be
> > separated. 
> 
> OK, as above, why?  or better yet, just give an example.

Hm. Maybe it is me who doesn't understand. 

With proposed patchset: 
1. As soon as we unblock suspend we go down.  (i.e. suspending)
2. While suspend is blocked, the idle-loop does it's things. (i.e.
runtime power managment -> can give same power-result as suspend)

possible cases:
1: 
   - qos-latency-constraints: 1ms,  [here: forbids anything other than
     C1 idle state.]
   - suspend is blocked

2: - qos latency-constraints: as in 1
   - suspend unblocked

3: - qos latency-constraints: infinity, cpu in lowest power state.
   - suspend is blocked

4: - qos latency-constraints: infinity, cpu in lowest power state.
   - suspend unblocked


in case 2 and 4 we would suspend, regardeless of the qos-latency.

in case 1 and 3 we would stay awake, regardeless of the qos-latency
constraint.


If only one constraint, then case 2 (or 3) wouldn't be possible. But it
is possible now. 

A possible use case as an example?
(hmm... i'm trying my imagination hard now): 
	Your sound needs low latency, so that could be a cause for the
	qos-latency constraint. 

	And unblocking suspend could nonetheless happen:
	For example... you have an firefox open and don't want to
	prevent suspend for that case when the display is turned off


Cheers,
Flo

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

[Gross, Mark]

>-----Original Message-----
>From: Florian Mickler [mailto:florian@mickler.org]
>Sent: Wednesday, June 02, 2010 4:06 PM
>To: James Bottomley
>Cc: Arve Hjønnevåg; Neil Brown; tytso@mit.edu; Peter Zijlstra; LKML; Alan
>Cox; Gross, Mark; Thomas Gleixner; Linux OMAP Mailing List; Linux PM;
>felipe.balbi@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>On Wed, 02 Jun 2010 15:41:11 -0500
>James Bottomley <James.Bottomley@suse.de> wrote:
>
>> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
>> > On Wed, 02 Jun 2010 10:05:11 -0500
>> > James Bottomley <James.Bottomley@suse.de> wrote:
>> >
>> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
>> > > > No, they have to be two separate constraints, otherwise a
>constraint
>> > > > to block suspend would override a constraint to block a low power
>idle
>> > > > mode or the other way around.
>> > >
>> > > Depends.  If you block the system from going into low power idle,
>does
>> > > that mean you still want it to be fully suspended?
>> > >
>> > > If yes, then we do have independent constraints.  If not, they have a
>> > > hierarchy:
>> > >
>> > >       * Fully Interactive (no low power idle or suspend)
>> > >       * Partially Interactive (may go into low power idle but not
>> > >         suspend)
>> > >       * None (may go into low power idle or suspend)
>> > >
>> > > Which is expressable as a ternary constraint.
>> > >
>> > > James
>> > >
>> >
>> > But unblocking suspend at the moment is independent to getting idle.
>> > If you have the requirement to stay in the highest-idle level (i.e.
>> > best latency you can get) that does not (currently) mean, that you can
>> > not suspend.
>>
>> I don't understand that as a reason.  If we looks at this a qos
>> constraints, you're saying that the system may not drop into certain low
>> power states because it might turn something off that's currently being
>> used by a driver or a process.  Suspend is certainly the lowest state of
>> that because it turns everything off, why would it be legal to drop into
>> that?
>>
>> I also couldn't find this notion of separation of idleness power from
>> suspend blocking in the original suspend block patch set ... if you can
>> either tell me where it is, or give me an example of the separated use
>> cases, I'd understand better.
>>
>> > To preserve that explicit fall-through while still having working
>> > run-time-powermanagement I think the qos-constraints need to be
>> > separated.
>>
>> OK, as above, why?  or better yet, just give an example.
>
>Hm. Maybe it is me who doesn't understand.
>
>With proposed patchset:
>1. As soon as we unblock suspend we go down.  (i.e. suspending)
>2. While suspend is blocked, the idle-loop does it's things. (i.e.
>runtime power managment -> can give same power-result as suspend)
>
>possible cases:
>1:
>   - qos-latency-constraints: 1ms,  [here: forbids anything other than
>     C1 idle state.]
>   - suspend is blocked
>
>2: - qos latency-constraints: as in 1
>   - suspend unblocked
>
>3: - qos latency-constraints: infinity, cpu in lowest power state.
>   - suspend is blocked
>
>4: - qos latency-constraints: infinity, cpu in lowest power state.
>   - suspend unblocked
>
>
>in case 2 and 4 we would suspend, regardeless of the qos-latency.
>
>in case 1 and 3 we would stay awake, regardeless of the qos-latency
>constraint.
>
>
>If only one constraint, then case 2 (or 3) wouldn't be possible. But it
>is possible now.
>
>A possible use case as an example?
>(hmm... i'm trying my imagination hard now):
>	Your sound needs low latency, so that could be a cause for the
>	qos-latency constraint.
>
>	And unblocking suspend could nonetheless happen:
>	For example... you have an firefox open and don't want to
>	prevent suspend for that case when the display is turned off
>
>
[mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.

We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether.  Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active.

--mgross

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

[Alan Cox]

> [mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.

That should be trivial in the usual case because 99% of the time you can
hot path

	the QoS entry changing is the latest one
	there have been no other changes
	If it is valid I can use the cached previous aggregate I cunningly
		saved in the top QoS entry when I computed the new one

(ie most of the time from the kernel side you have a QoS stack)

> We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether.  Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active.

We need some of this anyway for deep power saving because there is
hardware which can't wake from soem states, which in turn means if that
device is active we need to be above the state in question.

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

[Peter Zijlstra]

On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > [mtg: ] This has been a pain point for the PM_QOS implementation.
> They change the constrain back and forth at the transaction level of
> the i2c driver.  The pm_qos code really wasn't made to deal with such
> hot path use, as each such change triggers a re-computation of what
> the aggregate qos request is.
> 
> That should be trivial in the usual case because 99% of the time you can
> hot path
> 
> 	the QoS entry changing is the latest one
> 	there have been no other changes
> 	If it is valid I can use the cached previous aggregate I cunningly
> 		saved in the top QoS entry when I computed the new one
> 
> (ie most of the time from the kernel side you have a QoS stack)

Why would the kernel change the QoS state of a task? Why not have two
interacting QoS variables, one for the task, one for the subsystem in
question, and the action depends on their relative value?


> > We've had a number of attempts at fixing this, but I think the
> proper fix is to bolt a "disable C-states > x" interface into cpu_idle
> that bypases pm_qos altogether.  Or, perhaps add a new pm_qos API that
> does the equivalent operation, overriding whatever constraint is
> active.
> 
> We need some of this anyway for deep power saving because there is
> hardware which can't wake from soem states, which in turn means if that
> device is active we need to be above the state in question.

Right, and I can imagine that depending on the platform details and not
the device details, so we get platform hooks in the drivers, or possible
up in the generic stack because I don't think NICs actually know if
there are open connections.

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

[James Bottomley]

On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > [mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.
> 
> That should be trivial in the usual case because 99% of the time you can
> hot path
> 
> 	the QoS entry changing is the latest one
> 	there have been no other changes
> 	If it is valid I can use the cached previous aggregate I cunningly
> 		saved in the top QoS entry when I computed the new one
> 
> (ie most of the time from the kernel side you have a QoS stack)

It's not just the list based computation: that's trivial to fix, as you
say ... the other problem is the notifier chain, because that's blocking
and could be long.  Could we invoke the notifier through a workqueue?
It doesn't seem to have veto power, so it's pure notification, does it
matter if the notice is delayed (as long as it's in order)?

> > We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether.  Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active.
> 
> We need some of this anyway for deep power saving because there is
> hardware which can't wake from soem states, which in turn means if that
> device is active we need to be above the state in question.

James

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

[Florian Mickler]

On Thu, 03 Jun 2010 08:24:31 -0500
James Bottomley <James.Bottomley@suse.de> wrote:

> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.
> > 
> > That should be trivial in the usual case because 99% of the time you can
> > hot path
> > 
> > 	the QoS entry changing is the latest one
> > 	there have been no other changes
> > 	If it is valid I can use the cached previous aggregate I cunningly
> > 		saved in the top QoS entry when I computed the new one
> > 
> > (ie most of the time from the kernel side you have a QoS stack)
> 
> It's not just the list based computation: that's trivial to fix, as you
> say ... the other problem is the notifier chain, because that's blocking
> and could be long.  Could we invoke the notifier through a workqueue?
> It doesn't seem to have veto power, so it's pure notification, does it
> matter if the notice is delayed (as long as it's in order)?

I think schedule_work() (worqueue.h) can take care of that. 
Thats how the rfkill subsystem does it. 

Cheers,
Flo

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

[Gross, Mark]

>-----Original Message-----
>From: James Bottomley [mailto:James.Bottomley@suse.de]
>Sent: Thursday, June 03, 2010 6:25 AM
>To: Alan Cox
>Cc: Gross, Mark; Florian Mickler; Arve Hjønnevåg; Neil Brown;
>tytso@mit.edu; Peter Zijlstra; LKML; Thomas Gleixner; Linux OMAP Mailing
>List; Linux PM; felipe.balbi@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>> > [mtg: ] This has been a pain point for the PM_QOS implementation.  They
>change the constrain back and forth at the transaction level of the i2c
>driver.  The pm_qos code really wasn't made to deal with such hot path use,
>as each such change triggers a re-computation of what the aggregate qos
>request is.
>>
>> That should be trivial in the usual case because 99% of the time you can
>> hot path
>>
>> 	the QoS entry changing is the latest one
>> 	there have been no other changes
>> 	If it is valid I can use the cached previous aggregate I cunningly
>> 		saved in the top QoS entry when I computed the new one
>>
>> (ie most of the time from the kernel side you have a QoS stack)
>
>It's not just the list based computation: that's trivial to fix, as you
>say ... the other problem is the notifier chain, because that's blocking
>and could be long.  Could we invoke the notifier through a workqueue?
>It doesn't seem to have veto power, so it's pure notification, does it
>matter if the notice is delayed (as long as it's in order)?
[mtg: ] true.  The notifications "could be" done on as a scheduled work item
in most cases.  I think there is only one user of the notification so far 
any way.  Most pm_qos users do a pole of the current value for whatever parameter they are interested in.

--mgross

>
>> > We've had a number of attempts at fixing this, but I think the proper
>fix is to bolt a "disable C-states > x" interface into cpu_idle that
>bypases pm_qos altogether.  Or, perhaps add a new pm_qos API that does the
>equivalent operation, overriding whatever constraint is active.
>>
>> We need some of this anyway for deep power saving because there is
>> hardware which can't wake from soem states, which in turn means if that
>> device is active we need to be above the state in question.
>
>James
>

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

[Thomas Gleixner]

On Thu, 3 Jun 2010, James Bottomley wrote:

> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.
> > 
> > That should be trivial in the usual case because 99% of the time you can
> > hot path
> > 
> > 	the QoS entry changing is the latest one
> > 	there have been no other changes
> > 	If it is valid I can use the cached previous aggregate I cunningly
> > 		saved in the top QoS entry when I computed the new one
> > 
> > (ie most of the time from the kernel side you have a QoS stack)
> 
> It's not just the list based computation: that's trivial to fix, as you
> say ... the other problem is the notifier chain, because that's blocking
> and could be long.  Could we invoke the notifier through a workqueue?
> It doesn't seem to have veto power, so it's pure notification, does it
> matter if the notice is delayed (as long as it's in order)?

It depends on the information type and for a lot of things we might
get away without notifiers. 

The only real issue is when you need to get other cores out of their
deep idle state to make a new constraint work. That's what we do with
the DMA latency notifier right now.

Thanks,

	tglx

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

[James Bottomley]

On Thu, 2010-06-03 at 16:35 +0200, Thomas Gleixner wrote:
> On Thu, 3 Jun 2010, James Bottomley wrote:
> 
> > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > > [mtg: ] This has been a pain point for the PM_QOS implementation.  They change the constrain back and forth at the transaction level of the i2c driver.  The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is.
> > > 
> > > That should be trivial in the usual case because 99% of the time you can
> > > hot path
> > > 
> > > 	the QoS entry changing is the latest one
> > > 	there have been no other changes
> > > 	If it is valid I can use the cached previous aggregate I cunningly
> > > 		saved in the top QoS entry when I computed the new one
> > > 
> > > (ie most of the time from the kernel side you have a QoS stack)
> > 
> > It's not just the list based computation: that's trivial to fix, as you
> > say ... the other problem is the notifier chain, because that's blocking
> > and could be long.  Could we invoke the notifier through a workqueue?
> > It doesn't seem to have veto power, so it's pure notification, does it
> > matter if the notice is delayed (as long as it's in order)?
> 
> It depends on the information type and for a lot of things we might
> get away without notifiers. 
> 
> The only real issue is when you need to get other cores out of their
> deep idle state to make a new constraint work. That's what we do with
> the DMA latency notifier right now.

But the only DMA latency notifier is cpuidle_latency_notifier.  That
looks callable from atomic context, so we could have two chains: one
atomic and one not.

The only other notifier in use is the ieee80211_max_network_latency,
which uses mutexes, so does require user context.

James

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

[Kevin Hilman]

Peter Zijlstra <peterz@infradead.org> writes:

> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>> They change the constrain back and forth at the transaction level of
>> the i2c driver.  The pm_qos code really wasn't made to deal with such
>> hot path use, as each such change triggers a re-computation of what
>> the aggregate qos request is.
>> 
>> That should be trivial in the usual case because 99% of the time you can
>> hot path
>> 
>> 	the QoS entry changing is the latest one
>> 	there have been no other changes
>> 	If it is valid I can use the cached previous aggregate I cunningly
>> 		saved in the top QoS entry when I computed the new one
>> 
>> (ie most of the time from the kernel side you have a QoS stack)
>
> Why would the kernel change the QoS state of a task? Why not have two
> interacting QoS variables, one for the task, one for the subsystem in
> question, and the action depends on their relative value?

Yes, having a QoS parameter per-subsystem (or even per-device) is very
important for SoCs that have independently controlled powerdomains.
If all devices/subsystems in a particular powerdomain have QoS
parameters that permit, the power state of that powerdomain can be
lowered independently from system-wide power state and power states of
other power domains.

Kevin

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

[Gross, Mark]

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>Sent: Thursday, June 03, 2010 7:43 AM
>To: Peter Zijlstra
>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve
>Hjønnevåg; Neil Brown; tytso@mit.edu; LKML; Thomas Gleixner; Linux OMAP
>Mailing List; Linux PM; felipe.balbi@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>Peter Zijlstra <peterz@infradead.org> writes:
>
>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>>> They change the constrain back and forth at the transaction level of
>>> the i2c driver.  The pm_qos code really wasn't made to deal with such
>>> hot path use, as each such change triggers a re-computation of what
>>> the aggregate qos request is.
>>>
>>> That should be trivial in the usual case because 99% of the time you can
>>> hot path
>>>
>>> 	the QoS entry changing is the latest one
>>> 	there have been no other changes
>>> 	If it is valid I can use the cached previous aggregate I cunningly
>>> 		saved in the top QoS entry when I computed the new one
>>>
>>> (ie most of the time from the kernel side you have a QoS stack)
>>
>> Why would the kernel change the QoS state of a task? Why not have two
>> interacting QoS variables, one for the task, one for the subsystem in
>> question, and the action depends on their relative value?
>
>Yes, having a QoS parameter per-subsystem (or even per-device) is very
>important for SoCs that have independently controlled powerdomains.
>If all devices/subsystems in a particular powerdomain have QoS
>parameters that permit, the power state of that powerdomain can be
>lowered independently from system-wide power state and power states of
>other power domains.
>
This seems similar to that pm_qos generalization into bus drivers we where 
waving our hands at during the collab summit in April?  We never did get 
into meaningful detail at that time.

--mgross

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

[Kevin Hilman]

"Gross, Mark" <mark.gross@intel.com> writes:

>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: Thursday, June 03, 2010 7:43 AM
>>To: Peter Zijlstra
>>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve
>>Hjønnevåg; Neil Brown; tytso@mit.edu; LKML; Thomas Gleixner; Linux OMAP
>>Mailing List; Linux PM; felipe.balbi@nokia.com
>>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>>
>>Peter Zijlstra <peterz@infradead.org> writes:
>>
>>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>>>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>>>> They change the constrain back and forth at the transaction level of
>>>> the i2c driver.  The pm_qos code really wasn't made to deal with such
>>>> hot path use, as each such change triggers a re-computation of what
>>>> the aggregate qos request is.
>>>>
>>>> That should be trivial in the usual case because 99% of the time you can
>>>> hot path
>>>>
>>>> 	the QoS entry changing is the latest one
>>>> 	there have been no other changes
>>>> 	If it is valid I can use the cached previous aggregate I cunningly
>>>> 		saved in the top QoS entry when I computed the new one
>>>>
>>>> (ie most of the time from the kernel side you have a QoS stack)
>>>
>>> Why would the kernel change the QoS state of a task? Why not have two
>>> interacting QoS variables, one for the task, one for the subsystem in
>>> question, and the action depends on their relative value?
>>
>>Yes, having a QoS parameter per-subsystem (or even per-device) is very
>>important for SoCs that have independently controlled powerdomains.
>>If all devices/subsystems in a particular powerdomain have QoS
>>parameters that permit, the power state of that powerdomain can be
>>lowered independently from system-wide power state and power states of
>>other power domains.
>>
> This seems similar to that pm_qos generalization into bus drivers we where 
> waving our hands at during the collab summit in April?  We never did get 
> into meaningful detail at that time.

The hand-waving was around how to generalize it into the driver-model,
or PM QoS.  We're already doing this for OMAP, but in an OMAP-specific
way, but it's become clear that this is something useful to
generalize.

Kevin

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

[James Bottomley]

On Thu, 2010-06-03 at 09:58 -0700, Kevin Hilman wrote:
> "Gross, Mark" <mark.gross@intel.com> writes:
> 
> >>-----Original Message-----
> >>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >>Sent: Thursday, June 03, 2010 7:43 AM
> >>To: Peter Zijlstra
> >>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve
> >>Hjønnevåg; Neil Brown; tytso@mit.edu; LKML; Thomas Gleixner; Linux OMAP
> >>Mailing List; Linux PM; felipe.balbi@nokia.com
> >>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> >>
> >>Peter Zijlstra <peterz@infradead.org> writes:
> >>
> >>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> >>>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
> >>>> They change the constrain back and forth at the transaction level of
> >>>> the i2c driver.  The pm_qos code really wasn't made to deal with such
> >>>> hot path use, as each such change triggers a re-computation of what
> >>>> the aggregate qos request is.
> >>>>
> >>>> That should be trivial in the usual case because 99% of the time you can
> >>>> hot path
> >>>>
> >>>> 	the QoS entry changing is the latest one
> >>>> 	there have been no other changes
> >>>> 	If it is valid I can use the cached previous aggregate I cunningly
> >>>> 		saved in the top QoS entry when I computed the new one
> >>>>
> >>>> (ie most of the time from the kernel side you have a QoS stack)
> >>>
> >>> Why would the kernel change the QoS state of a task? Why not have two
> >>> interacting QoS variables, one for the task, one for the subsystem in
> >>> question, and the action depends on their relative value?
> >>
> >>Yes, having a QoS parameter per-subsystem (or even per-device) is very
> >>important for SoCs that have independently controlled powerdomains.
> >>If all devices/subsystems in a particular powerdomain have QoS
> >>parameters that permit, the power state of that powerdomain can be
> >>lowered independently from system-wide power state and power states of
> >>other power domains.
> >>
> > This seems similar to that pm_qos generalization into bus drivers we where 
> > waving our hands at during the collab summit in April?  We never did get 
> > into meaningful detail at that time.
> 
> The hand-waving was around how to generalize it into the driver-model,
> or PM QoS.  We're already doing this for OMAP, but in an OMAP-specific
> way, but it's become clear that this is something useful to
> generalize.

Do you have a pointer to the source and description?  It might be useful
to look at to do a reality check on what we're talking about.

James


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

[Muralidhar, Rajeev D]

Hi Kevin, Mark, all,

Yes, from our brief discussions at ELC, and all the ensuing discussions that have happened in the last few weeks, it certainly seems like a good time to think about:
- what is a good model to tie up device idleness, latencies, constraints with cpu idle infrastructure - extensions to PM_QOS, part of what is being discussed, especially Kevin's earlier mail about QOS parameter per subsystem/device that may have independent clock/power domain control.

- what is a good infrastructure to subsequently allow platform-specific low power state - extensions to cpuidle infrastructure to allow platform-wide low power state? Exact conditions for such entry/exit into low power state (latency, wake, etc.) could be platform specific.

Is it a good idea to discuss about a model that could be applicable to other SOCs/platforms as well?

Thanks
Rajeev


-----Original Message-----
From: linux-pm-bounces@lists.linux-foundation.org [mailto:linux-pm-bounces@lists.linux-foundation.org] On Behalf Of Kevin Hilman
Sent: Thursday, June 03, 2010 10:28 PM
To: Gross, Mark
Cc: Neil Brown; tytso@mit.edu; Peter Zijlstra; felipe.balbi@nokia.com; LKML; Florian Mickler; James Bottomley; Thomas Gleixner; Linux OMAP Mailing List; Linux PM; Alan Cox
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

"Gross, Mark" <mark.gross@intel.com> writes:

>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: Thursday, June 03, 2010 7:43 AM
>>To: Peter Zijlstra
>>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve
>>Hjønnevåg; Neil Brown; tytso@mit.edu; LKML; Thomas Gleixner; Linux OMAP
>>Mailing List; Linux PM; felipe.balbi@nokia.com
>>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>>
>>Peter Zijlstra <peterz@infradead.org> writes:
>>
>>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>>>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>>>> They change the constrain back and forth at the transaction level of
>>>> the i2c driver.  The pm_qos code really wasn't made to deal with such
>>>> hot path use, as each such change triggers a re-computation of what
>>>> the aggregate qos request is.
>>>>
>>>> That should be trivial in the usual case because 99% of the time you can
>>>> hot path
>>>>
>>>> 	the QoS entry changing is the latest one
>>>> 	there have been no other changes
>>>> 	If it is valid I can use the cached previous aggregate I cunningly
>>>> 		saved in the top QoS entry when I computed the new one
>>>>
>>>> (ie most of the time from the kernel side you have a QoS stack)
>>>
>>> Why would the kernel change the QoS state of a task? Why not have two
>>> interacting QoS variables, one for the task, one for the subsystem in
>>> question, and the action depends on their relative value?
>>
>>Yes, having a QoS parameter per-subsystem (or even per-device) is very
>>important for SoCs that have independently controlled powerdomains.
>>If all devices/subsystems in a particular powerdomain have QoS
>>parameters that permit, the power state of that powerdomain can be
>>lowered independently from system-wide power state and power states of
>>other power domains.
>>
> This seems similar to that pm_qos generalization into bus drivers we where 
> waving our hands at during the collab summit in April?  We never did get 
> into meaningful detail at that time.

The hand-waving was around how to generalize it into the driver-model,
or PM QoS.  We're already doing this for OMAP, but in an OMAP-specific
way, but it's become clear that this is something useful to
generalize.

Kevin
_______________________________________________
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)

[Bryan Huntsman]

>> Yes, having a QoS parameter per-subsystem (or even per-device) is very
>> important for SoCs that have independently controlled powerdomains.
>> If all devices/subsystems in a particular powerdomain have QoS
>> parameters that permit, the power state of that powerdomain can be
>> lowered independently from system-wide power state and power states of
>> other power domains.
>>
> This seems similar to that pm_qos generalization into bus drivers we where 
> waving our hands at during the collab summit in April?  We never did get 
> into meaningful detail at that time.
> 
> --mgross

I think there is definitely a need for QoS parameters per-device.  I've 
been pondering how to incorporate this concept into runtime_pm.  One 
idea would be to add pm_qos-like callbacks to struct dev_pm_ops, e.g. 
runtime_pm_qos_add/update/remove_requirement().  Requirements would be 
passed up the tree to the first parent that cares, usually a bus driver. 
  Is this similar to what you guys were discussing at the collab summit? 
  Thanks.

- Bryan

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

[mark gross]

On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote:
> On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > 
> > > You're the one mentioning x86, not me.  I already explained that some
> > > MSM hardware (the G1 for example) has lower power consumption in S3
> > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > > suspend from idle C state.  The fact that current x86 hardware has the
> > > same problem may be true, but it's not entirely relevant.
> > 
> > As long as you can set a wakeup timer, an S state is just a C state with 
> > side effects. The significant one is that entering an S state stops the 
> > process scheduler and any in-kernel timers. I don't think Google care at 
> > all about whether suspend is entered through an explicit transition or 
> > something hooked into cpuidle - the relevant issue is that they want to 
> > be able to express a set of constraints that lets them control whether 
> > or not the scheduler keeps on scheduling, and which doesn't let them 
> > lose wakeup events in the process.
> 
> Exactly, so my understanding of where we currently are is:
> 
>      1. pm_qos will be updated to be able to express the android suspend
>         blockers as interactivity constraints (exact name TBD, but
>         probably /dev/cpu_interactivity)
>      2. pm_qos will be updated to be callable from atomic context
>      3. pm_qos will be updated to export statistics initially closely
>         matching what suspend blockers provides (simple update of the rw
>         interface?)
> 
> After this is done, the current android suspend block patch becomes a
> re-expression in kernel space in terms of pm_qos, with the current
> userspace wakelocks being adapted by the android framework into pm_qos
> requirements expressed to /dev/cpu_interactivity (or whatever name is
> chosen).  Then opportunistic suspend is either a small add-on kernel
> patch they have in their tree to suspend when the interactivity
> constraint goes to NONE, or it could be done entirely by a userspace
> process.  Long term this could migrate to the freezer and suspend from
> idle approach as the various problem timers get fixed.

This is all nice but, all this does is implement the exact same thing as
the wake lock / suspend blocker API as a pm_qos request-class.  It
leaves the overlapping constraint issue from ISR to user mode in place
depending on exactly how the oppertunistic suspend is implemented.

I expect it will be via a notifier on the pm_qos request-class update
that would do exactly what the wake lock code does today.  just load up
an a "suspend_on_non_interactivity" driver that registers for the call
back, have it enabled by the user mode PM, and you have the equivelent
architecture as what was proposed by the wake lock patches.

it gives the Android guys what they want, without adding a new
subsystem, minimizing the changes and makes most of the architecture
much more politicaly acceptible.

But doesn't it have the same issues with getting the overlapping
constraints right from wake up source to user mode and dealing with the
wake up envents in a sane way?  Instead of sprinkling suspend-blockers
about the kernel we'll sprinkle pm_qos_requests about.  I like getting
more users of pm_qos, but isn't this the same thing?

> 
> I think the big unresolved issue is the stats extension.  For android,
> we need just a name written along with the value, so we have something
> to hang the stats off ... current pm_qos userspace users just write a
> value, so the name would be optional.  From the kernel, we probably just
> need an additional API that takes a stats name or NULL if none
> (pm_qos_add_request_named()?).  Then reading the stats could be done by
> implementing a fops read routine on the misc device.

I don't think the status would be a big deal to add.


However; I am really burned out by this discussion.  I am willing to
stub this out ASAP if it puts this behind us if the principles in the
discussion are in more or less agreement.

--mgross

For the record, I still like my low power event idea, which could
coexist with the above.

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

[James Bottomley]

On Tue, 2010-06-01 at 19:45 -0700, mark gross wrote:
> On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote:
> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > > 
> > > > You're the one mentioning x86, not me.  I already explained that some
> > > > MSM hardware (the G1 for example) has lower power consumption in S3
> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > > > suspend from idle C state.  The fact that current x86 hardware has the
> > > > same problem may be true, but it's not entirely relevant.
> > > 
> > > As long as you can set a wakeup timer, an S state is just a C state with 
> > > side effects. The significant one is that entering an S state stops the 
> > > process scheduler and any in-kernel timers. I don't think Google care at 
> > > all about whether suspend is entered through an explicit transition or 
> > > something hooked into cpuidle - the relevant issue is that they want to 
> > > be able to express a set of constraints that lets them control whether 
> > > or not the scheduler keeps on scheduling, and which doesn't let them 
> > > lose wakeup events in the process.
> > 
> > Exactly, so my understanding of where we currently are is:
> > 
> >      1. pm_qos will be updated to be able to express the android suspend
> >         blockers as interactivity constraints (exact name TBD, but
> >         probably /dev/cpu_interactivity)
> >      2. pm_qos will be updated to be callable from atomic context
> >      3. pm_qos will be updated to export statistics initially closely
> >         matching what suspend blockers provides (simple update of the rw
> >         interface?)
> > 
> > After this is done, the current android suspend block patch becomes a
> > re-expression in kernel space in terms of pm_qos, with the current
> > userspace wakelocks being adapted by the android framework into pm_qos
> > requirements expressed to /dev/cpu_interactivity (or whatever name is
> > chosen).  Then opportunistic suspend is either a small add-on kernel
> > patch they have in their tree to suspend when the interactivity
> > constraint goes to NONE, or it could be done entirely by a userspace
> > process.  Long term this could migrate to the freezer and suspend from
> > idle approach as the various problem timers get fixed.
> 
> This is all nice but, all this does is implement the exact same thing as
> the wake lock / suspend blocker API as a pm_qos request-class.

funny that ...

>   It
> leaves the overlapping constraint issue from ISR to user mode in place
> depending on exactly how the oppertunistic suspend is implemented.

if the vanilla kernel is simply consuming the pm_qos infrastructure and
using suspend from idle, this is irrelevant.  As I said, S3 suspend
*can* be implemented via a suspend manager process from userspace (the
alan stern proposal).  However, if I were coding the android kernel, I'd
do it as a tiny add on kernel patch.  The main goal of making the
android kernel close enough to the vanilla kernel for there not to be
two separate upstreams for the device driver writers has been achieved
regardless of which path is taken.

> I expect it will be via a notifier on the pm_qos request-class update
> that would do exactly what the wake lock code does today.  just load up
> an a "suspend_on_non_interactivity" driver that registers for the call
> back, have it enabled by the user mode PM, and you have the equivelent
> architecture as what was proposed by the wake lock patches.
> 
> it gives the Android guys what they want, without adding a new
> subsystem, minimizing the changes and makes most of the architecture
> much more politicaly acceptible.
> 
> But doesn't it have the same issues with getting the overlapping
> constraints right from wake up source to user mode and dealing with the
> wake up envents in a sane way?  Instead of sprinkling suspend-blockers
> about the kernel we'll sprinkle pm_qos_requests about.  I like getting
> more users of pm_qos, but isn't this the same thing?

Suspend from idle doesn't have the wakeup problem.  it only manifests if
you want to take the system down via the S states.  I think long term,
making suspend from idle work for all hardware is the agreed goal, even
if android can't implement it today and has to use an S state work
around.

> > I think the big unresolved issue is the stats extension.  For android,
> > we need just a name written along with the value, so we have something
> > to hang the stats off ... current pm_qos userspace users just write a
> > value, so the name would be optional.  From the kernel, we probably just
> > need an additional API that takes a stats name or NULL if none
> > (pm_qos_add_request_named()?).  Then reading the stats could be done by
> > implementing a fops read routine on the misc device.
> 
> I don't think the status would be a big deal to add.
> 
> 
> However; I am really burned out by this discussion.  I am willing to
> stub this out ASAP if it puts this behind us if the principles in the
> discussion are in more or less agreement.
> 
> --mgross
> 
> For the record, I still like my low power event idea, which could
> coexist with the above.

The proposal is isomorphic to what I said above ... just
s/pm_qos/whatever the lp API is/

James

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

[Thomas Gleixner]

On Sat, 29 May 2010, James Bottomley wrote:
> On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> > 
> > 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.
> 
> Strange, that's not what I heard as the possible solution.  I thought he
> was advocating expressing the kernel side of suspend blockers as QoS
> constraints.  Once we have QoS constraints correctly done in the kernel,
> userspace still has to express its requirements.  If the requirements
> are static, then they can be done from policy files or in some other
> static way but if they're dynamic, they'll still have to be in the
> applications ... in about the same places the android wakelocks are.

That's wrong. You only need the explicit dynamic QoS constraints for
applications which follow the scheme:

     while (1) {
     	   if (event_available())
	      process_event();
	   else
	      do_useless_crap_which_consumes_power();
     }	   

which need the following annotation:

     while (1) {
     	   block_suspend();
     	   if (event_available()) {
	      process_event();
	      unblock_suspend();
	   } else {
	      unblock_suspend();
	      do_useless_crap_which_consumes_power();
           }
     }	   

Plus the kernel counterpart of drivers which take the suspend blocker
in the interrupt handler and release it when the event queue is empty.

So that's done for making polling event handling power "efficient".

Even worse, you need the same "annotation" for non polling mode and it
enforces the use of select() because you cannot take a suspend blocker
across a blocking read() without adding more invasive interactions to
the kernel..

So the "sane" app looks like:

   while (1) {
   	 select();
	 block_suspend();
	 process_events();
	 unblock_suspend();
   }

I'm really tired of arguing that this promotion of "programming style"
is the worst idea ever, so let's look how you can do the same thing
QoS based.

s/block_suspend()/qos(INTERACTIVE)/ and
s/unblock_suspend()/qos(NONE)/ and
s/block_magic()/qos_magic()/ in the drivers.

Yes, it's mostly the same, with a subtle difference:

While android can use it in the big hammer approach to disable the
existing user initiated suspend via /sys/power/state, the rest of the
world can benefit as well in various ways.

 - Sane applications which use a blocking event wait can be handled
   with a static QoS setting simply because a blocking read relies on
   the QoS state of the underlying I/O system.

 - Idle based suspend as the logical consequence of idle states is
   just a matter of QoS constraint based decisions.

 - Untrusted apps can be confined in cgroups. The groups are set to
   QoS(None) when user land decides that it's time to safe power
   (e.g. screen lock kicks in)

 - QoS states can block applications from I/O when the I/O system is
   set to a state which is exclusive.

  - ...

So that allows to use the same mechanism for more than the android
sledge hammer approach and confines the controversial use cases into
android specific files without adding a hard to maintain user space
interface which would prevent or at least make it hard to do some of
the above mentioned things which we want to see implemented.

While I personally disagree with the android approach, I REALLY want
to provide them a mechanism to make it work, but not for the price
that it actively prevents solutions which are considered to be
technically superior by a relevant group of developers/maintainers.

> > 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.
> 
> I don't think anyone disagrees with this. As long as we find a long term
> solution that satisfies the android case, everyone will be happy.

See above.

Thanks,

	tglx

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

[Rafael J. Wysocki]

On Monday 31 May 2010, Thomas Gleixner wrote:
> On Sat, 29 May 2010, James Bottomley wrote:
> > On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> > > 
> > > 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.
> > 
> > Strange, that's not what I heard as the possible solution.  I thought he
> > was advocating expressing the kernel side of suspend blockers as QoS
> > constraints.  Once we have QoS constraints correctly done in the kernel,
> > userspace still has to express its requirements.  If the requirements
> > are static, then they can be done from policy files or in some other
> > static way but if they're dynamic, they'll still have to be in the
> > applications ... in about the same places the android wakelocks are.
> 
> That's wrong. You only need the explicit dynamic QoS constraints for
> applications which follow the scheme:
> 
>      while (1) {
>      	   if (event_available())
> 	      process_event();
> 	   else
> 	      do_useless_crap_which_consumes_power();
>      }	   
> 
> which need the following annotation:
> 
>      while (1) {
>      	   block_suspend();
>      	   if (event_available()) {
> 	      process_event();
> 	      unblock_suspend();
> 	   } else {
> 	      unblock_suspend();
> 	      do_useless_crap_which_consumes_power();
>            }
>      }	   
> 
> Plus the kernel counterpart of drivers which take the suspend blocker
> in the interrupt handler and release it when the event queue is empty.
> 
> So that's done for making polling event handling power "efficient".
> 
> Even worse, you need the same "annotation" for non polling mode and it
> enforces the use of select() because you cannot take a suspend blocker
> across a blocking read() without adding more invasive interactions to
> the kernel..
> 
> So the "sane" app looks like:
> 
>    while (1) {
>    	 select();
> 	 block_suspend();
> 	 process_events();
> 	 unblock_suspend();
>    }
> 
> I'm really tired of arguing that this promotion of "programming style"
> is the worst idea ever, so let's look how you can do the same thing
> QoS based.
> 
> s/block_suspend()/qos(INTERACTIVE)/ and
> s/unblock_suspend()/qos(NONE)/ and
> s/block_magic()/qos_magic()/ in the drivers.
> 
> Yes, it's mostly the same, with a subtle difference:
> 
> While android can use it in the big hammer approach to disable the
> existing user initiated suspend via /sys/power/state, the rest of the
> world can benefit as well in various ways.
> 
>  - Sane applications which use a blocking event wait can be handled
>    with a static QoS setting simply because a blocking read relies on
>    the QoS state of the underlying I/O system.
> 
>  - Idle based suspend as the logical consequence of idle states is
>    just a matter of QoS constraint based decisions.
> 
>  - Untrusted apps can be confined in cgroups. The groups are set to
>    QoS(None) when user land decides that it's time to safe power
>    (e.g. screen lock kicks in)
> 
>  - QoS states can block applications from I/O when the I/O system is
>    set to a state which is exclusive.
> 
>   - ...
> 
> So that allows to use the same mechanism for more than the android
> sledge hammer approach and confines the controversial use cases into
> android specific files without adding a hard to maintain user space
> interface which would prevent or at least make it hard to do some of
> the above mentioned things which we want to see implemented.

I generally agree.

I think the Alan Stern's recent proposal goes along these lines, but it has
the advantage of being a bit more specific. ;-)

Thanks,
Rafael

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

[Thomas Gleixner]

On Tue, 1 Jun 2010, Rafael J. Wysocki wrote:
> On Monday 31 May 2010, Thomas Gleixner wrote:
> > So that allows to use the same mechanism for more than the android
> > sledge hammer approach and confines the controversial use cases into
> > android specific files without adding a hard to maintain user space
> > interface which would prevent or at least make it hard to do some of
> > the above mentioned things which we want to see implemented.
> 
> I generally agree.
> 
> I think the Alan Stern's recent proposal goes along these lines, but it has
> the advantage of being a bit more specific. ;-)

Yes, Alan Stern's proposal is going into that direction and I'm not
opposed. Just wanted to get the overall picture straight for James :)

Thanks,

	tglx

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

[James Bottomley]

On Mon, 2010-05-31 at 23:41 +0200, Thomas Gleixner wrote:
> On Sat, 29 May 2010, James Bottomley wrote:
> > On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> > > 
> > > 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.
> > 
> > Strange, that's not what I heard as the possible solution.  I thought he
> > was advocating expressing the kernel side of suspend blockers as QoS
> > constraints.  Once we have QoS constraints correctly done in the kernel,
> > userspace still has to express its requirements.  If the requirements
> > are static, then they can be done from policy files or in some other
> > static way but if they're dynamic, they'll still have to be in the
> > applications ... in about the same places the android wakelocks are.
> 
> That's wrong. You only need the explicit dynamic QoS constraints for
> applications which follow the scheme:
> 
>      while (1) {
>      	   if (event_available())
> 	      process_event();
> 	   else
> 	      do_useless_crap_which_consumes_power();
>      }	   
> 
> which need the following annotation:
> 
>      while (1) {
>      	   block_suspend();
>      	   if (event_available()) {
> 	      process_event();
> 	      unblock_suspend();
> 	   } else {
> 	      unblock_suspend();
> 	      do_useless_crap_which_consumes_power();
>            }
>      }	   
> 
> Plus the kernel counterpart of drivers which take the suspend blocker
> in the interrupt handler and release it when the event queue is empty.
> 
> So that's done for making polling event handling power "efficient".
> 
> Even worse, you need the same "annotation" for non polling mode and it
> enforces the use of select() because you cannot take a suspend blocker
> across a blocking read() without adding more invasive interactions to
> the kernel..
> 
> So the "sane" app looks like:
> 
>    while (1) {
>    	 select();
> 	 block_suspend();
> 	 process_events();
> 	 unblock_suspend();
>    }
> 
> I'm really tired of arguing that this promotion of "programming style"
> is the worst idea ever, so let's look how you can do the same thing
> QoS based.
> 
> s/block_suspend()/qos(INTERACTIVE)/ and
> s/unblock_suspend()/qos(NONE)/ and
> s/block_magic()/qos_magic()/ in the drivers.

So this is the re-expression in terms of a QoS API that I mentioned ...
as I said, I think it's the way forwards. (from the android point of
view, it keeps the user space expression in exactly the same place as
the original wake locks, or suspend blocks, which is why it looks like a
rename to them).

> Yes, it's mostly the same, with a subtle difference:
> 
> While android can use it in the big hammer approach to disable the
> existing user initiated suspend via /sys/power/state, the rest of the
> world can benefit as well in various ways.
> 
>  - Sane applications which use a blocking event wait can be handled
>    with a static QoS setting simply because a blocking read relies on
>    the QoS state of the underlying I/O system.
> 
>  - Idle based suspend as the logical consequence of idle states is
>    just a matter of QoS constraint based decisions.
> 
>  - Untrusted apps can be confined in cgroups. The groups are set to
>    QoS(None) when user land decides that it's time to safe power
>    (e.g. screen lock kicks in)
> 
>  - QoS states can block applications from I/O when the I/O system is
>    set to a state which is exclusive.
> 
>   - ...

I understand this ... it's effectively the alan stern approach.  I've
already said that looks like the way forwards.

> So that allows to use the same mechanism for more than the android
> sledge hammer approach and confines the controversial use cases into
> android specific files without adding a hard to maintain user space
> interface which would prevent or at least make it hard to do some of
> the above mentioned things which we want to see implemented.

Yes, which is why I think something like this can be made to work ... I
don't really see that we differ on the broad brush picture.  As long as
the acceptable implementation accomplishes what everyone wants, I think
we're home.

James

> While I personally disagree with the android approach, I REALLY want
> to provide them a mechanism to make it work, but not for the price
> that it actively prevents solutions which are considered to be
> technically superior by a relevant group of developers/maintainers.
> 
> > > 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.
> > 
> > I don't think anyone disagrees with this. As long as we find a long term
> > solution that satisfies the android case, everyone will be happy.
> 
> See above.
> 
> Thanks,
> 
> 	tglx

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: [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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Rafael J. Wysocki]

On Saturday 29 May 2010, Peter Zijlstra wrote:
> 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.

It will only work for apps that use I/O, but there may be purely CPU-bound
ones that need that kind of approach too.

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: [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)

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

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

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

[Zygo Blaxell]

On Fri, May 28, 2010 at 10:17:55AM +0100, Alan Cox wrote:
> > 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'm not sure "other people are shipping without them" is such a good
metric, especially for scheduler features.  For some reason (I have some
ideas what it might be, but I won't speculate here) people don't like
messing with the scheduler in mainline, even though there's a lot of
special cases where a bit of messing with the scheduler (or replacing
it outright) goes a long way toward qualitatively improving performance
on some workloads.

I'd love to have several more ways to have large classes of processes stop
executing, and stay stopped, even though traditional Unix and mainline
Linux would try to run them.  I don't want to put knowledge of this into
every application I run since there are literally thousands of them,
and IMNSHO it's not even an application's responsibility to know this
kind of thing.  The "sort" program can't know what QoS to ask for in any
sane system design.  The best it can do is try to execute as hard as it
can whenever the kernel lets it, and have some other application advise
the kernel about how much or how little service (including cases like
"no service at all") the sort program should get from the system.

To choose a random example, I'd like a "duty cycle" constraint on
process execution (i.e. a runnable task must execute between L and M ns
per N ns interval--stealing slices from lower priority processes if it
doesn't get enough and isn't blocked on I/O, and leaving the CPU idle even
though the process is runnable if it gets too much).  I usually want to
apply this kind of limit to programs like Firefox, because Firefox is a)
big enough that controlling it actually matters for power consumption,
b) sensitive enough to user interaction latency that I want it to have
fairly high CPU priority when it has something to do, and c) big and
complex enough that I wouldn't want to try to adjust its behavior by
modifying its source.  Also, Firefox's behavior tends to be driven by
the data it pulls from random web sites, over which I have no control
whatsoever, and many of them are intentionally wasteful.

I'm not willing to run a non-mainline kernel (or Firefox, for that
matter) just to get that feature, and I'm not willing to submit patches
to mainline if I've seen nearly identical ideas rejected recently, so I
live without the feature for now.  This implies that the statistic for
"people running desirable scheduler features" is at least one lower than
the statistic for "people who would use desirable scheduler features if
they didn't have to hack up non-mainline kernels to get them."

I can hack up something that does something similar to duty cycle in
user-space, but it's got a lot of problems:

	- when you send SIGSTOP/SIGCONT to a process, it wakes up its
	parent through waitpid() (well, you can partially get around
	this with ptrace(), but that raises other issues),

	- it's racy wrt fork(),

	- it can't opportunistically schedule process execution,
	e.g. during times when the CPU is idle at high clock rates,

	- sufficiently badly behaved processes are able to escape
	the CPU usage regulation mechanism, and

	- estimating how much global CPU has been used as a percentage of
	real time is easy, but how much CPU relative to other processes
	running on the system is not.  I keep doing math like "subtract
	aggregate process CPU usage from global CPU usage" and getting
	numbers outside the range of 0..100% of global CPU usage.

Also, for non-trivial cases, the user-space CPU management process
consumes more CPU than any other process on the system, and keeps waking
up the CPU every N and M ns, even if the process being scheduled isn't
runnable.  

Simply providing better information to userspace to help a regulator
application of this kind would be a huge leap in the right direction.

Arguably I could run the applications I want to throttle under KVM,
and hack up the KVM to manage the CPU usage; however, that's hardly
transparent to the application, which is now running on the wrong machine
for a lot of what it wants to do.

So instead of fixing the software, I have an extra-large third-party
battery on my laptop.  It's a cheaper solution on small (one user) scales.
I can't ship a competitive product with that kind of problem, though.

Having said all that, I'm fairly sure suspend blockers aren't the way to
get it.  I'd much rather have interesting QoS constraint features,
including new conditions under which to not run otherwise runnable tasks.
Maybe ionice and SCHED_IDLEPRIO on steroids?

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: [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)

[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, 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:

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

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

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

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

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

[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, 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 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: [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)

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

[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: [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)

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

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

[James Bottomley]

On Sat, 2010-05-29 at 12:42 +0200, Peter Zijlstra 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.

I still think there is a semantic issue here ... see other email.

> If you start to randomly not run tasks, the inversion chaos that ensues
> is terrible.

As a sweeping statement, I disagree because you're explicitly saying we
can't solve the actual problem.  If you're saying the scheduler
shouldn't do this and something external has to make the tasks idle
somehow first, I agree.

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

So as a mechanism for idling tasks, this looks possible.  I don't like
it from a theoretical viewpoint because it can't idle cpu bound tasks.
I'd like a solution that solved all of the problem, not just all except
stuff we think probably won't happen on a phone because experience tells
me that partial solutions eventually turn up gotchas down the road.

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

The timers for a polling main loop have to be stopped ... this isn't
possible with the current interface today, therefore we have to have
kernel changes in some form.

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

So, that sounds like the goal of just about everyone on the thread.

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

They haven't actually said this.  They've said they've implemented
opportunistic suspend because it solves two problems: power savings for
devices whose C states don't go as low as S3 and forced idling of tasks.
Their main goal is extending battery life per charge, and what I've
heard them say is any solution that does this is fine ... as long as the
life per charge is as good as (or preferably better than) their current
implementation ... I don't think that's unreasonable, and I think it
might be achievable with some of the ideas in this thread.

James

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: [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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Rafael J. Wysocki]

On Saturday 29 May 2010, Arve Hjønnevåg wrote:
> 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).

I wasn't referring to suspend blockers, but to the idea of initiating full
system suspend from idle, which I still think makes sense.  If you are
waiting for an interrupt that cannot wake you from suspend, then
_obviously_ suspend should not be started.  However, if you're not waiting for
such an interrupt and the (a) and (b) above hold, it makes sense to start
suspend from idle.

Thanks,
Rafael

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

[Arve Hjønnevåg]

2010/5/29 Rafael J. Wysocki <rjw@sisk.pl>:
> On Saturday 29 May 2010, Arve Hjønnevåg wrote:
>> 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).
>
> I wasn't referring to suspend blockers, but to the idea of initiating full
> system suspend from idle, which I still think makes sense.  If you are
> waiting for an interrupt that cannot wake you from suspend, then
> _obviously_ suspend should not be started.  However, if you're not waiting for
> such an interrupt and the (a) and (b) above hold, it makes sense to start
> suspend from idle.
>

What about timers? When you suspend timers stop (otherwise it is just
a deep-idle mode), and this could cause problems. Some drivers rely on
timers if the hardware does not have a completion interrupt. It is not
uncommon to see send command x then wait 200ms in a some hardware
specs.

-- 
Arve Hjønnevåg

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

[Rafael J. Wysocki]

On Saturday 29 May 2010, Arve Hjønnevåg wrote:
> 2010/5/29 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Saturday 29 May 2010, Arve Hjønnevåg wrote:
> >> 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).
> >
> > I wasn't referring to suspend blockers, but to the idea of initiating full
> > system suspend from idle, which I still think makes sense.  If you are
> > waiting for an interrupt that cannot wake you from suspend, then
> > _obviously_ suspend should not be started.  However, if you're not waiting for
> > such an interrupt and the (a) and (b) above hold, it makes sense to start
> > suspend from idle.
> >
> 
> What about timers? When you suspend timers stop (otherwise it is just
> a deep-idle mode), and this could cause problems. Some drivers rely on
> timers if the hardware does not have a completion interrupt. It is not
> uncommon to see send command x then wait 200ms in a some hardware
> specs.

QoS should be used in such cases.

Rafael

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

[Arve Hjønnevåg]

2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
> On Saturday 29 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/29 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Saturday 29 May 2010, Arve Hjønnevåg wrote:
>> >> 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).
>> >
>> > I wasn't referring to suspend blockers, but to the idea of initiating full
>> > system suspend from idle, which I still think makes sense.  If you are
>> > waiting for an interrupt that cannot wake you from suspend, then
>> > _obviously_ suspend should not be started.  However, if you're not waiting for
>> > such an interrupt and the (a) and (b) above hold, it makes sense to start
>> > suspend from idle.
>> >
>>
>> What about timers? When you suspend timers stop (otherwise it is just
>> a deep-idle mode), and this could cause problems. Some drivers rely on
>> timers if the hardware does not have a completion interrupt. It is not
>> uncommon to see send command x then wait 200ms in a some hardware
>> specs.
>
> QoS should be used in such cases.
>

I think it makes more sense to block suspend while wakeup events are
pending than blocking it everywhere timers are used by code that could
be called while handling wakeup events or other critical work. Also,
even if you did block suspend everywhere timers where used you still
have the race where a wakeup interrupt happens right after you decided
to suspend. In other words, you still need to block suspend in all the
same places as with the current opportunistic suspend code, so what is
the benefit of delaying suspend until idle?

-- 
Arve Hjønnevåg

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

[Rafael J. Wysocki]

On Monday 31 May 2010, Arve Hjønnevåg wrote:
> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
...
> 
> I think it makes more sense to block suspend while wakeup events are
> pending than blocking it everywhere timers are used by code that could
> be called while handling wakeup events or other critical work. Also,
> even if you did block suspend everywhere timers where used you still
> have the race where a wakeup interrupt happens right after you decided
> to suspend. In other words, you still need to block suspend in all the
> same places as with the current opportunistic suspend code, so what is
> the benefit of delaying suspend until idle?

Assume for a while that you don't use suspend blockers, OK?  I realize you
think that anything else doesn't make sense, but evidently some other people
have that opinion about suspend blockers.

Now, under that assumption, I think it _generally_ is reasonable to make the
system go into full suspend if everything (ie. CPUs and I/O) has been idle
for sufficiently long time and there are no QoS requirements that aren't
compatible with full system suspend.

Rafael

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

[Arve Hjønnevåg]

2010/5/31 Rafael J. Wysocki <rjw@sisk.pl>:
> On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
> ...
>>
>> I think it makes more sense to block suspend while wakeup events are
>> pending than blocking it everywhere timers are used by code that could
>> be called while handling wakeup events or other critical work. Also,
>> even if you did block suspend everywhere timers where used you still
>> have the race where a wakeup interrupt happens right after you decided
>> to suspend. In other words, you still need to block suspend in all the
>> same places as with the current opportunistic suspend code, so what is
>> the benefit of delaying suspend until idle?
>
> Assume for a while that you don't use suspend blockers, OK?  I realize you
> think that anything else doesn't make sense, but evidently some other people
> have that opinion about suspend blockers.
>

It sounded like you were suggesting that initiating suspend from idle
would somehow avoid the race condition with wakeup events. All I'm
saying is that you would need to block suspend in all the same places.
If you don't care about ignoring wakeup events, then sure you can
initiate suspend from idle.

> Now, under that assumption, I think it _generally_ is reasonable to make the
> system go into full suspend if everything (ie. CPUs and I/O) has been idle
> for sufficiently long time and there are no QoS requirements that aren't
> compatible with full system suspend.
>

-- 
Arve Hjønnevåg

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

[Igor Stoppa]

Hi,

ext Arve Hjønnevåg wrote:

> It sounded like you were suggesting that initiating suspend from idle
> would somehow avoid the race condition with wakeup events. All I'm
> saying is that you would need to block suspend in all the same places.
> If you don't care about ignoring wakeup events, then sure you can
> initiate suspend from idle.
>   

Sorry if i'm asking something that was already said, but the thread is 
quite complex and i am not sure i have been able to grasp all of it.

So, regardless of the SW implementation:

-1) are you focusing on "good" HW or do you want to address all at the 
same time?

-2) would you be ok with addressing "bad" HW as a special case, which 
requires workarounds and shouldn't dictate the overall design?

-3) do you agree with the assumption that new HW is expected to get 
reasonably better and therefore workarounds at point 2) will 
progressively be confined to devices less and less common?

-4) going to the definition of "good" and "bad" (maybe this should have 
come earlier in the list), can we define "good" HW as HW where:
 * suspend state and lowest achievable runtime idle state are basically 
equivalent from both power consumption and latency pov
 * the HW itself is properly able to track wakeup sources while it is in 
its deepest power state (as example OMAP3 has few independent 
wake-capable pads and a "wake ring" where one only gets the information 
that at least one of the pads belonging to such ring has received a wakeup)
 * wakeup sources can be dynamically masked at HW level, so that if a 
peripheral is not interesting, it doesn't wakeup the system (for example 
the camera button when the camera cover is closed)

-5) HW that is not capable of properly generating asynchronous signal is 
most likely the cause for extra timers in kernel and it should be 
considered "bad" - in any other case having recurring in-kernel timers 
should be treated as bugs, if their existence is not tied to some 
meaningful work

thanks, igor

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1465 bytes --]

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

> 2010/5/31 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
> > ...
> >>
> >> I think it makes more sense to block suspend while wakeup events are
> >> pending than blocking it everywhere timers are used by code that could
> >> be called while handling wakeup events or other critical work. Also,
> >> even if you did block suspend everywhere timers where used you still
> >> have the race where a wakeup interrupt happens right after you decided
> >> to suspend. In other words, you still need to block suspend in all the
> >> same places as with the current opportunistic suspend code, so what is
> >> the benefit of delaying suspend until idle?
> >
> > Assume for a while that you don't use suspend blockers, OK?  I realize you
> > think that anything else doesn't make sense, but evidently some other people
> > have that opinion about suspend blockers.
> >
> 
> It sounded like you were suggesting that initiating suspend from idle
> would somehow avoid the race condition with wakeup events. All I'm
> saying is that you would need to block suspend in all the same places.
> If you don't care about ignoring wakeup events, then sure you can
> initiate suspend from idle.

And why should you miss a wakeup there ? If you get an interrupt in
the transition, then you are not longer idle.

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Arve Hjønnevåg]

2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
> On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>
>> 2010/5/31 Rafael J. Wysocki <rjw@sisk.pl>:
>> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
>> > ...
>> >>
>> >> I think it makes more sense to block suspend while wakeup events are
>> >> pending than blocking it everywhere timers are used by code that could
>> >> be called while handling wakeup events or other critical work. Also,
>> >> even if you did block suspend everywhere timers where used you still
>> >> have the race where a wakeup interrupt happens right after you decided
>> >> to suspend. In other words, you still need to block suspend in all the
>> >> same places as with the current opportunistic suspend code, so what is
>> >> the benefit of delaying suspend until idle?
>> >
>> > Assume for a while that you don't use suspend blockers, OK?  I realize you
>> > think that anything else doesn't make sense, but evidently some other people
>> > have that opinion about suspend blockers.
>> >
>>
>> It sounded like you were suggesting that initiating suspend from idle
>> would somehow avoid the race condition with wakeup events. All I'm
>> saying is that you would need to block suspend in all the same places.
>> If you don't care about ignoring wakeup events, then sure you can
>> initiate suspend from idle.
>
> And why should you miss a wakeup there ? If you get an interrupt in
> the transition, then you are not longer idle.
>

Because suspend itself causes you to not be idle you cannot abort
suspend just because you are not idle anymore.

-- 
Arve Hjønnevåg

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3051 bytes --]

On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> 2010/5/31 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > ...
> >> >>
> >> >> I think it makes more sense to block suspend while wakeup events are
> >> >> pending than blocking it everywhere timers are used by code that could
> >> >> be called while handling wakeup events or other critical work. Also,
> >> >> even if you did block suspend everywhere timers where used you still
> >> >> have the race where a wakeup interrupt happens right after you decided
> >> >> to suspend. In other words, you still need to block suspend in all the
> >> >> same places as with the current opportunistic suspend code, so what is
> >> >> the benefit of delaying suspend until idle?
> >> >
> >> > Assume for a while that you don't use suspend blockers, OK?  I realize you
> >> > think that anything else doesn't make sense, but evidently some other people
> >> > have that opinion about suspend blockers.
> >> >
> >>
> >> It sounded like you were suggesting that initiating suspend from idle
> >> would somehow avoid the race condition with wakeup events. All I'm
> >> saying is that you would need to block suspend in all the same places.
> >> If you don't care about ignoring wakeup events, then sure you can
> >> initiate suspend from idle.
> >
> > And why should you miss a wakeup there ? If you get an interrupt in
> > the transition, then you are not longer idle.
> >
> 
> Because suspend itself causes you to not be idle you cannot abort
> suspend just because you are not idle anymore.

You still are addicted to the current suspend mechanism. :)

The whole point of doing it from idle in the form of a deep power
state is to avoid the massive sh*tload of work which is neccesary to
run the existing suspend code. But that needs runtime power management
and tweaks to avoid your timers waking you, etc.

The mechanism you want to use is: suspend no matter what, like closing
the lid of the laptop, but with a few tweaks around it:

   1) An interrupt on a wakeup source which comes in while the suspend
      code runs, i.e before you transitioned into wakeup mode, must
      abort / prevent suspend.

   2) Prevent another attempt to suspend before the event has been
      delivered and the apps have signaled that they have not longer
      any work to do.

   As a side effect you confine crappy apps with that mechanism in
   some way.

In the laptop case we do not want the tweaks as not going into suspend
might set your backpack on fire.

If I understood you correctly then you can shutdown the CPU in idle
completelty already, but that's not enough due to:

    1) crappy applications keeping the cpu away from idle
    2) timers firing

Would solving those two issues be sufficient for you or am I missing
something ?

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Arve Hjønnevåg]

2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
> On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/1 Thomas Gleixner <tglx@linutronix.de>:
>> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> 2010/5/31 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/30 Rafael J. Wysocki <rjw@sisk.pl>:
>> >> > ...
>> >> >>
>> >> >> I think it makes more sense to block suspend while wakeup events are
>> >> >> pending than blocking it everywhere timers are used by code that could
>> >> >> be called while handling wakeup events or other critical work. Also,
>> >> >> even if you did block suspend everywhere timers where used you still
>> >> >> have the race where a wakeup interrupt happens right after you decided
>> >> >> to suspend. In other words, you still need to block suspend in all the
>> >> >> same places as with the current opportunistic suspend code, so what is
>> >> >> the benefit of delaying suspend until idle?
>> >> >
>> >> > Assume for a while that you don't use suspend blockers, OK?  I realize you
>> >> > think that anything else doesn't make sense, but evidently some other people
>> >> > have that opinion about suspend blockers.
>> >> >
>> >>
>> >> It sounded like you were suggesting that initiating suspend from idle
>> >> would somehow avoid the race condition with wakeup events. All I'm
>> >> saying is that you would need to block suspend in all the same places.
>> >> If you don't care about ignoring wakeup events, then sure you can
>> >> initiate suspend from idle.
>> >
>> > And why should you miss a wakeup there ? If you get an interrupt in
>> > the transition, then you are not longer idle.
>> >
>>
>> Because suspend itself causes you to not be idle you cannot abort
>> suspend just because you are not idle anymore.
>
> You still are addicted to the current suspend mechanism. :)
>

No I want you to stop confusing low power idle modes with suspend. I
know how to enter low power modes from idle if that low power mode is
not too disruptive.

> The whole point of doing it from idle in the form of a deep power
> state is to avoid the massive sh*tload of work which is neccesary to
> run the existing suspend code. But that needs runtime power management
> and tweaks to avoid your timers waking you, etc.
>
> The mechanism you want to use is: suspend no matter what, like closing
> the lid of the laptop, but with a few tweaks around it:
>
>   1) An interrupt on a wakeup source which comes in while the suspend
>      code runs, i.e before you transitioned into wakeup mode, must
>      abort / prevent suspend.
>
>   2) Prevent another attempt to suspend before the event has been
>      delivered and the apps have signaled that they have not longer
>      any work to do.
>
>   As a side effect you confine crappy apps with that mechanism in
>   some way.
>
> In the laptop case we do not want the tweaks as not going into suspend
> might set your backpack on fire.

If that is the case you should also disable the wakeup events.

>
> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
>
>    1) crappy applications keeping the cpu away from idle
>    2) timers firing
>
> Would solving those two issues be sufficient for you or am I missing
> something ?

Solving those two is enough for current android phones, but it may not
be enough for other android devices. 1 is not solvable (meaning we
cannot fix all apps), and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way
to solve 2 is to allow timers on a not-idle clock. Unrelated to
Android, I also want to use opportunistic suspend on my desktop.

-- 
Arve Hjønnevåg

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

[Peter Zijlstra]

On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:


> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
> 
>     1) crappy applications keeping the cpu away from idle
>     2) timers firing
> 
> Would solving those two issues be sufficient for you or am I missing
> something ?

Aren't the container snapshot/resume people fighting the same set of
problems here?

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

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1757 bytes --]

On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >>
> >> Because suspend itself causes you to not be idle you cannot abort
> >> suspend just because you are not idle anymore.
> >
> > You still are addicted to the current suspend mechanism. :)
> >
> 
> No I want you to stop confusing low power idle modes with suspend. I
> know how to enter low power modes from idle if that low power mode is
> not too disruptive.

What prevents us from going into a disruptive mode from idle ? I don't
see a reason - except crappy ACPI stuff, which I'm happy to ignore.

> > If I understood you correctly then you can shutdown the CPU in idle
> > completelty already, but that's not enough due to:
> >
> >    1) crappy applications keeping the cpu away from idle
> >    2) timers firing
> >
> > Would solving those two issues be sufficient for you or am I missing
> > something ?
> 
> Solving those two is enough for current android phones, but it may not
> be enough for other android devices.

In which way ? May not be enough is a pretty vague statement.

> 1 is not solvable (meaning we cannot fix all apps),

We can mitigate it with cgroups and confine crap there, i.e. force
idle them.

> and 2 is difficult to fix since the periodic
> work is useful while the device is actually in use. One possible way
> to solve 2 is to allow timers on a not-idle clock.

That's what I had in mind.

> Unrelated to Android, I also want to use opportunistic suspend on my
> desktop.

I expect that intel/amd fixing their stuff is going to happen way
before we sprinkled suspend blockers over a full featured desktop
distro.

Thanks,

	tglx

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Arve Hjønnevåg]

2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
> On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/2 Thomas Gleixner <tglx@linutronix.de>:
>> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> >>
>> >> Because suspend itself causes you to not be idle you cannot abort
>> >> suspend just because you are not idle anymore.
>> >
>> > You still are addicted to the current suspend mechanism. :)
>> >
>>
>> No I want you to stop confusing low power idle modes with suspend. I
>> know how to enter low power modes from idle if that low power mode is
>> not too disruptive.
>
> What prevents us from going into a disruptive mode from idle ? I don't
> see a reason - except crappy ACPI stuff, which I'm happy to ignore.
>

What do you consider disruptive? Disabling active interrupts? Stopping
the monotonic clock?

>> > If I understood you correctly then you can shutdown the CPU in idle
>> > completelty already, but that's not enough due to:
>> >
>> >    1) crappy applications keeping the cpu away from idle
>> >    2) timers firing
>> >
>> > Would solving those two issues be sufficient for you or am I missing
>> > something ?
>>
>> Solving those two is enough for current android phones, but it may not
>> be enough for other android devices.
>
> In which way ? May not be enough is a pretty vague statement.

They may not be based on hardware that can get to the same power mode
from idle as suspend. This could be acpi based hardware, it could be
like the hardware we started with that did not have regular timers
that could run in the low power mode, or devices could loose their
state in the lowest power mode.

>
>> 1 is not solvable (meaning we cannot fix all apps),
>
> We can mitigate it with cgroups and confine crap there, i.e. force
> idle them.
>

I think using suspend is much simpler. It avoids having to worry about
dependencies between processes.

>> and 2 is difficult to fix since the periodic
>> work is useful while the device is actually in use. One possible way
>> to solve 2 is to allow timers on a not-idle clock.
>
> That's what I had in mind.
>
>> Unrelated to Android, I also want to use opportunistic suspend on my
>> desktop.
>
> I expect that intel/amd fixing their stuff is going to happen way
> before we sprinkled suspend blockers over a full featured desktop
> distro.
>

You do not need to sprinkle suspend blocker all over the distro for it
to be useful. You can convert the existing auto-suspend code to use
opportunistic suspend and all apps that don't use suspend blocker will
behave as they do today while allowing apps to use suspend blockers to
keep the system running after the auto-suspend timeout expired.

-- 
Arve Hjønnevåg

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

[Peter Zijlstra]

On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend
is nothing more but a deep idle state.

(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
fixing it, get over it already).

> Unrelated to
> Android, I also want to use opportunistic suspend on my desktop.

So you're going to sprinkle this suspend blocker shite all over regular
userspace? Why not instead work on getting apps to behave properly and
idle when there's nothing to do?

After all, if you have the code to add suspend blockers into, you also
have the means to fix it being stupid in the first place.




_______________________________________________
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/6/2 Peter Zijlstra <peterz@infradead.org>:
> On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
>> No I want you to stop confusing low power idle modes with suspend.
>
> I think it is you who is confused. For power management purposes suspend
> is nothing more but a deep idle state.

No, idle is transparent, suspend is not.

>
> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> fixing it, get over it already).
>

I don't think it is realistic to drop support for all existing hardware.

>> Unrelated to
>> Android, I also want to use opportunistic suspend on my desktop.
>
> So you're going to sprinkle this suspend blocker shite all over regular
> userspace?

I have said several times, that regular user-space will not need to be
modified to maintain their current behavior.

> Why not instead work on getting apps to behave properly and
> idle when there's nothing to do?
>
> After all, if you have the code to add suspend blockers into, you also
> have the means to fix it being stupid in the first place.
>

Why would I add suspend blockers to the code I want to prevent running?

-- 
Arve Hjønnevåg

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

[Peter Zijlstra]

On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> 2010/6/2 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> >> No I want you to stop confusing low power idle modes with suspend.
> >
> > I think it is you who is confused. For power management purposes suspend
> > is nothing more but a deep idle state.
> 
> No, idle is transparent, suspend is not.

Which is where the problem is, it should be.

> Why would I add suspend blockers to the code I want to prevent running?

Because what you want might not be what others want. Suppose you're fine
with your torrent client/irc client/etc.. to loose their network
connection when you're not behind your desktop so you don't add suspend
blockers there.

Me, I'd be ready to administer physical violence if either of those lost
their connections when I wasn't around to keep the screen-saver from
kicking in.

This leads to having to sprinkle magic dust (and lots of config options)
all over userspace. Something that gets esp interesting with only a
boolean interface.

In the example above, having an active net connection would prevent my
desktop from suspending, but what if another platform can maintain net
connections while suspended? Do we then end up with arch specific code
in the net-stack? I'm sure DaveM would love that.


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

[Florian Mickler]

On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> > 2010/6/2 Peter Zijlstra <peterz@infradead.org>:
> > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> > >> No I want you to stop confusing low power idle modes with suspend.
> > >
> > > I think it is you who is confused. For power management purposes suspend
> > > is nothing more but a deep idle state.
> > 
> > No, idle is transparent, suspend is not.
> 
> Which is where the problem is, it should be.
> 
> > Why would I add suspend blockers to the code I want to prevent running?
> 
> Because what you want might not be what others want. Suppose you're fine
> with your torrent client/irc client/etc.. to loose their network
> connection when you're not behind your desktop so you don't add suspend
> blockers there.
> 
> Me, I'd be ready to administer physical violence if either of those lost
> their connections when I wasn't around to keep the screen-saver from
> kicking in.

Do you switch your pc on and off manually? Sometimes? Really?
(if not, you are probably a kernel hacker *g*) 

I assume, in general, there are only a few reasons to shut down a
machine: 

1. One has to do maintainance on the hardware or somehow needs to
interrupt the power supply.

2. One wants to save power. 

3. One wants to go easy on the hardware. 

4. ...?

Obviously, for reason 1 we need to maintain the shutdown-paths
indefinitely.  

But the rest are usecases that are similar to the suspend-blocker
usecases. You know that you are not using the machine and going
through the pain to shut down your machine. You have to do it manually.
Why? 

> This leads to having to sprinkle magic dust (and lots of config options)
> all over userspace. Something that gets esp interesting with only a
> boolean interface.

A userspace daemon could keep track of what applications can be
ignored. The wordprocessor probably should not keep the system busy. As
well as a running firefox. 

It is a hard problem. But we have _no way of deciding any of this in
the kernel_!


> 
> In the example above, having an active net connection would prevent my
> desktop from suspending, but what if another platform can maintain net
> connections while suspended? Do we then end up with arch specific code
> in the net-stack? I'm sure DaveM would love that.
> 
If it is driver knowledge, then it goes into the driver.
If it is platform knowledge, then it goes into the platform code.
I think that is a clear requirement to keeping sanity. 

The problem is there independently of suspend blockers. If the system
can suspend with network up, then you shure as hell want to suspend
even if the network is up. So it would actually be a reason for any
kind of "suspend blockers" scheme. Wouldn't it?

Cheers,
Flo

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

[Peter Zijlstra]

On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 12:21:28 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:

> Do you switch your pc on and off manually? Sometimes? Really?
> (if not, you are probably a kernel hacker *g*) 

Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace
parts, but no, not otherwise ;-) But I've been doing that for pretty
much as long as I've had a computer.

> But the rest are usecases that are similar to the suspend-blocker
> usecases. You know that you are not using the machine and going
> through the pain to shut down your machine. You have to do it manually.
> Why? 

Make suspend an idle state and teach apps to go real quiet.

(Then again, that only really works when regular network packets can
wake the machine for my case).

> > This leads to having to sprinkle magic dust (and lots of config options)
> > all over userspace. Something that gets esp interesting with only a
> > boolean interface.
> 
> A userspace daemon could keep track of what applications can be
> ignored. The wordprocessor probably should not keep the system busy. As
> well as a running firefox. 
> 
> It is a hard problem. But we have _no way of deciding any of this in
> the kernel_

Therefore I say, fix the worprocessor to not actually do anything if its
not poked at -- not too hard, wordprocessors really don't need to do
anything on their own, and you can do your last backup cycle when the
window becomes invisible and stop the timer until the document changes
again.

Same for firefox, you can teach it to not render animated gifs and run
javascript for invisible tabs, and once the screen-saver kicks in,
nothing is visible (and with X telling apps their window is visible or
not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

You really only ever want to freeze broken apps. And even for those I
would prefer it if I got notified some app is stupid, then I could
either fix it, or choose not to use it.

You can also teach cron to listen to dbus messages telling it about the
screen state and postpone jobs -- but please make that a configurable
thing, I really like all that work done at 4am when I'm (usually) not
around to be bothered by it.

> The problem is there independently of suspend blockers. If the system
> can suspend with network up, then you shure as hell want to suspend
> even if the network is up. So it would actually be a reason for any
> kind of "suspend blockers" scheme. Wouldn't it?

Well, at that point suspend is nothing more than an idle state, and
platform code needs to somehow inform the idle state governor that
active net connections need to prevent that idle state from being used.

If you want to call that suspend blockers, then sure, but its a long way
away from the explicit scheme proposed at the start of this thread.

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

[Florian Mickler]

On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> Same for firefox, you can teach it to not render animated gifs and run
> javascript for invisible tabs, and once the screen-saver kicks in,
> nothing is visible (and with X telling apps their window is visible or
> not it knows), so it should go idle all of its own.
> 
> Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an
orthogonal problem.

Suppose firefox were fixed. It still needs to fetch my rss feeds every
minute, because I'm sad if it doesn't. It just can't be fixed at the
application level.

Cheers,
Flo

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

[Peter Zijlstra]

On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> On Thu, 03 Jun 2010 09:40:02 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > Same for firefox, you can teach it to not render animated gifs and run
> > javascript for invisible tabs, and once the screen-saver kicks in,
> > nothing is visible (and with X telling apps their window is visible or
> > not it knows), so it should go idle all of its own.
> > 
> > Fix the friggin apps, don't kludge with freezing.
> 
> Of course programs should be as smart as possible. But that is an
> orthogonal problem.
> 
> Suppose firefox were fixed. It still needs to fetch my rss feeds every
> minute, because I'm sad if it doesn't. It just can't be fixed at the
> application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off
and nobody could possible see the result? So you can stop the timer when
you know the window isn't visible or alternatively when the screensaver
is active, I think most desktops have notification of that as well.

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

[Florian Mickler]

On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> > On Thu, 03 Jun 2010 09:40:02 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > Same for firefox, you can teach it to not render animated gifs and run
> > > javascript for invisible tabs, and once the screen-saver kicks in,
> > > nothing is visible (and with X telling apps their window is visible or
> > > not it knows), so it should go idle all of its own.
> > > 
> > > Fix the friggin apps, don't kludge with freezing.
> > 
> > Of course programs should be as smart as possible. But that is an
> > orthogonal problem.
> > 
> > Suppose firefox were fixed. It still needs to fetch my rss feeds every
> > minute, because I'm sad if it doesn't. It just can't be fixed at the
> > application level.
> 
> Sure it can, why would it need to fetch RSS feeds when the screen is off
> and nobody could possible see the result? So you can stop the timer when
> you know the window isn't visible or alternatively when the screensaver
> is active, I think most desktops have notification of that as well.

This is arguing on a very thin line. In fact it is becoming pointless. 

Suppose there were an RSS-feed plugin that signals events to an event
Plugin. That event plugin could be either visual notification or sending
audio-signals. But the RSS feed doesn't know what specific plugin it
talks to. So screen off is _not always_ the right indicator. Sometimes
it is, sometimes it's not. 
There would be a seperate infrastructure needed in the program to tell
the different plugins that the core thinks everything should stop.
How does the core knows when to stop? And then there probably need to
be some kind of "suspend blockers" in the program. *g*

Just solve it at the right level, so that the apps don't need to be
infected with this shit. And this belongs between the iron and the
apps. And it seems it needs to be some cooperative approach of kernel
and userspace-framework as it isn't right to put that much policy in
the kernel.

I don't think it is a black and white thing, where you can just say
"fix the friggin apps". 

And this is a really f*beep*ng serious point. (at least to me)

Cheers,
Flo

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

[Felipe Contreras]

On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
>> On Thu, 03 Jun 2010 09:40:02 +0200
>> Peter Zijlstra <peterz@infradead.org> wrote:
>>
>> > Same for firefox, you can teach it to not render animated gifs and run
>> > javascript for invisible tabs, and once the screen-saver kicks in,
>> > nothing is visible (and with X telling apps their window is visible or
>> > not it knows), so it should go idle all of its own.
>> >
>> > Fix the friggin apps, don't kludge with freezing.
>>
>> Of course programs should be as smart as possible. But that is an
>> orthogonal problem.
>>
>> Suppose firefox were fixed. It still needs to fetch my rss feeds every
>> minute, because I'm sad if it doesn't. It just can't be fixed at the
>> application level.
>
> Sure it can, why would it need to fetch RSS feeds when the screen is off
> and nobody could possible see the result? So you can stop the timer when
> you know the window isn't visible or alternatively when the screensaver
> is active, I think most desktops have notification of that as well.

Exactly, and that's what applications in the N900 do. For this to work
reliably, you need these notifications (network disconnected, screen
off) to be easily accessible, and even transparent to the application
writer.

I don't think the suspend blockers solve much. A bad application will
behave bad on any system. Suppose somebody decides to port Firefox to
Android, and forgets to listen to the screen off event (bad on Android
or Maemo), however, notices the application behaves very badly, so by
googling finds these suspend blockers, and enables them all the time
the application runs.

When the user install the application, will be greeted by a warning
"This application might break PM, do you want to enable suspend
blockers?" (or whatever), as any typical user would do, will press Yes
(whatever).

We end up in exactly the same situation.

-- 
Felipe Contreras

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

[Florian Mickler]

On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> >> On Thu, 03 Jun 2010 09:40:02 +0200
> >> Peter Zijlstra <peterz@infradead.org> wrote:
> >>
> >> > Fix the friggin apps, don't kludge with freezing.
> >>
> >> Of course programs should be as smart as possible. But that is an
> >> orthogonal problem.
> >>
> >> Suppose firefox were fixed. It still needs to fetch my rss feeds every
> >> minute, because I'm sad if it doesn't. It just can't be fixed at the
> >> application level.
> >
> > Sure it can, why would it need to fetch RSS feeds when the screen is off
> > and nobody could possible see the result? So you can stop the timer when
> > you know the window isn't visible or alternatively when the screensaver
> > is active, I think most desktops have notification of that as well.
> 
> Exactly, and that's what applications in the N900 do. For this to work
> reliably, you need these notifications (network disconnected, screen
> off) to be easily accessible, and even transparent to the application
> writer.
> 
> I don't think the suspend blockers solve much. A bad application will
> behave bad on any system. Suppose somebody decides to port Firefox to
> Android, and forgets to listen to the screen off event (bad on Android
> or Maemo), however, notices the application behaves very badly, so by
> googling finds these suspend blockers, and enables them all the time
> the application runs.
> 
> When the user install the application, will be greeted by a warning
> "This application might break PM, do you want to enable suspend
> blockers?" (or whatever), as any typical user would do, will press Yes
> (whatever).
> 
> We end up in exactly the same situation.
> 
No. The application will show up in the suspend blocker stats and the
user will remember: "Oh, yes. There was a warning about that. Well I
think I'm going to file a bug there."

The only difference is, that with suspend blockers, he can than
dismiss the applications permission to block suspend and will not miss
his job interview the next day because his phones battery run
out. And also he can use the application to a certain extent.

Cheers,
Flo

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

[Felipe Contreras]

On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <florian@mickler.org> wrote:
> On Sat, 5 Jun 2010 20:30:40 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> I don't think the suspend blockers solve much. A bad application will
>> behave bad on any system. Suppose somebody decides to port Firefox to
>> Android, and forgets to listen to the screen off event (bad on Android
>> or Maemo), however, notices the application behaves very badly, so by
>> googling finds these suspend blockers, and enables them all the time
>> the application runs.
>>
>> When the user install the application, will be greeted by a warning
>> "This application might break PM, do you want to enable suspend
>> blockers?" (or whatever), as any typical user would do, will press Yes
>> (whatever).
>>
>> We end up in exactly the same situation.
>>
> No. The application will show up in the suspend blocker stats and the
> user will remember: "Oh, yes. There was a warning about that. Well I
> think I'm going to file a bug there."

How would such stats be calculated? I presume at regular intervals you
check which applications are holding suspend blockers and increase a
counter.

How would you do that with the dynamic PM approach? At regular
intervals you check for which applications are running (not idle).

> The only difference is, that with suspend blockers, he can than
> dismiss the applications permission to block suspend and will not miss
> his job interview the next day because his phones battery run
> out. And also he can use the application to a certain extent.

So the difference is between removing the app, and making it run
crappy. I don't think that's a strong argument in favor of suspend
blockers.

-- 
Felipe Contreras

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

[Florian Mickler]

On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <florian@mickler.org> wrote:
> > On Sat, 5 Jun 2010 20:30:40 +0300
> > Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >> I don't think the suspend blockers solve much. A bad application will
> >> behave bad on any system. Suppose somebody decides to port Firefox to
> >> Android, and forgets to listen to the screen off event (bad on Android
> >> or Maemo), however, notices the application behaves very badly, so by
> >> googling finds these suspend blockers, and enables them all the time
> >> the application runs.
> >>
> >> When the user install the application, will be greeted by a warning
> >> "This application might break PM, do you want to enable suspend
> >> blockers?" (or whatever), as any typical user would do, will press Yes
> >> (whatever).
> >>
> >> We end up in exactly the same situation.
> >>
> > No. The application will show up in the suspend blocker stats and the
> > user will remember: "Oh, yes. There was a warning about that. Well I
> > think I'm going to file a bug there."
> 
> How would such stats be calculated? I presume at regular intervals you
> check which applications are holding suspend blockers and increase a
> counter.
> 
> How would you do that with the dynamic PM approach? At regular
> intervals you check for which applications are running (not idle).

IIRC, the patches discussed have debugging infrastructure in
them. The kernel does the accounting. 

> 
> > The only difference is, that with suspend blockers, he can than
> > dismiss the applications permission to block suspend and will not miss
> > his job interview the next day because his phones battery run
> > out. And also he can use the application to a certain extent.
> 
> So the difference is between removing the app, and making it run
> crappy. I don't think that's a strong argument in favor of suspend
> blockers.
> 
If you think a little about it, it is. Because if the app wouldn't be
usable at all, the bug wouldn't get fixed because the user wouldn't use
it. Or not?

Cheers,
Flo

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

[Felipe Contreras]

On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler <florian@mickler.org> wrote:
> On Sat, 5 Jun 2010 23:06:03 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> How would such stats be calculated? I presume at regular intervals you
>> check which applications are holding suspend blockers and increase a
>> counter.
>>
>> How would you do that with the dynamic PM approach? At regular
>> intervals you check for which applications are running (not idle).
>
> IIRC, the patches discussed have debugging infrastructure in
> them. The kernel does the accounting.

We are not talking about debugging, we are talking about stats shown
in user-space so that users can see the offending apps. It doesn't
matter where the accounting is done, it would be at regular intervals
and there's nothing that prevents the dynamic PM approach to offer
similar stats.

>> > The only difference is, that with suspend blockers, he can than
>> > dismiss the applications permission to block suspend and will not miss
>> > his job interview the next day because his phones battery run
>> > out. And also he can use the application to a certain extent.
>>
>> So the difference is between removing the app, and making it run
>> crappy. I don't think that's a strong argument in favor of suspend
>> blockers.
>>
> If you think a little about it, it is. Because if the app wouldn't be
> usable at all, the bug wouldn't get fixed because the user wouldn't use
> it. Or not?

I'm not sure what's your point here. One user not using a certain
application doesn't prevent bugs to get fixed. In fact, less people
using an app will cause less buzz, and less downloads, and less
positive votes... which might wake up the author to think: hey, maybe
I'm doing something wrong? Maybe I should really listen to those bug
reports.

Anyway, my point is that there's nothing special about 3rd party app
stats with suspend blockers.

-- 
Felipe Contreras

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

[Felipe Contreras]

2010/6/2 Arve Hjønnevåg <arve@android.com>:
> 2010/6/2 Peter Zijlstra <peterz@infradead.org>:
>> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> fixing it, get over it already).
>>
>
> I don't think it is realistic to drop support for all existing hardware.

We are talking about mainline here, there's no support for suspend
blockers, so nothing is dropped.

In the mind of everybody, suspend blockers is for opportunistic
suspend, which only makes sense on sensible hw (not current x86). So
in the mind of everybody, x86 should be out of scope for the analysis
of suspend blockers.

Are you seriously suggesting that one of the strong arguments in favor
of suspend blockers is x86 usage (nobody agrees)? If not, then drop
it.

>>> Unrelated to
>>> Android, I also want to use opportunistic suspend on my desktop.
>>
>> So you're going to sprinkle this suspend blocker shite all over regular
>> userspace?
>
> I have said several times, that regular user-space will not need to be
> modified to maintain their current behavior.

If I enable suspend blockers on my laptop, I have to modify my
user-space. Otherwise my system will behave horribly.

-- 
Felipe Contreras
_______________________________________________
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)

[Florian Mickler]

On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> 2010/6/2 Arve Hjønnevåg <arve@android.com>:
> > 2010/6/2 Peter Zijlstra <peterz@infradead.org>:
> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> >> fixing it, get over it already).
> >>
> >
> > I don't think it is realistic to drop support for all existing hardware.
> 
> We are talking about mainline here, there's no support for suspend
> blockers, so nothing is dropped.
> 
> In the mind of everybody, suspend blockers is for opportunistic
> suspend, which only makes sense on sensible hw (not current x86). So
> in the mind of everybody, x86 should be out of scope for the analysis
> of suspend blockers.
> 
> Are you seriously suggesting that one of the strong arguments in favor
> of suspend blockers is x86 usage (nobody agrees)? If not, then drop
> it.

I think they have an advantage over the
30-minute-screensaver-then-suspend that current desktops do. Because
you can define what keeps the system up. I.e. the
screensaver/powermanager is not limited to keyboard- and
mouse-inactivity.

> If I enable suspend blockers on my laptop, I have to modify my
> user-space. Otherwise my system will behave horribly.
> 

In the simplest case you have a shell script which takes a suspend
blocker and reads from stdinput. When you write "mem" to it, it
releases the suspend blocker and acquires it back again. Voila, forced
suspend reimplemented on top of opportunistic suspend.

That wasn't hard, was it? 

Cheers,
Flo
 

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

[Felipe Contreras]

On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler <florian@mickler.org> wrote:
> On Sat, 5 Jun 2010 20:44:24 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> 2010/6/2 Arve Hjønnevåg <arve@android.com>:
>> > 2010/6/2 Peter Zijlstra <peterz@infradead.org>:
>> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> >> fixing it, get over it already).
>> >>
>> >
>> > I don't think it is realistic to drop support for all existing hardware.
>>
>> We are talking about mainline here, there's no support for suspend
>> blockers, so nothing is dropped.
>>
>> In the mind of everybody, suspend blockers is for opportunistic
>> suspend, which only makes sense on sensible hw (not current x86). So
>> in the mind of everybody, x86 should be out of scope for the analysis
>> of suspend blockers.
>>
>> Are you seriously suggesting that one of the strong arguments in favor
>> of suspend blockers is x86 usage (nobody agrees)? If not, then drop
>> it.
>
> I think they have an advantage over the
> 30-minute-screensaver-then-suspend that current desktops do. Because
> you can define what keeps the system up. I.e. the
> screensaver/powermanager is not limited to keyboard- and
> mouse-inactivity.

What prevents you from defining other things keeping the system up
right now? Nothing. It's up to user-space to decide when to suspend.
In fact applications already block suspend; Transmission has the
option to block suspend when downloading torrents.

>> If I enable suspend blockers on my laptop, I have to modify my
>> user-space. Otherwise my system will behave horribly.
>>
>
> In the simplest case you have a shell script which takes a suspend
> blocker and reads from stdinput. When you write "mem" to it, it
> releases the suspend blocker and acquires it back again. Voila, forced
> suspend reimplemented on top of opportunistic suspend.
>
> That wasn't hard, was it?

Not hard, but still a modification of user-space, and a pretty bad one
because it will prevent typical forced suspend, and typical suspend
delaying (like with Transmission). Supposing the opportunistic suspend
doesn't block the forced suspend, still, absolutely nothing will be
achieved by enabling suspend blockers.

If you want to take even a minimal advantage of suspend blockers you
need serious modifications to user-space.

Supposing there's a perfect usage of suspend blockers from user-space
on current x86 platforms (in theory Android would have that), is the
benefit that big to consider this a strong argument in favor of
suspend blockers? Considering the small amount of x86 platforms using
Android (is there any?), the fact that nobody else will use suspend
blockers, and that x86 is already being fixed (as mentioned many times
before) so dynamic PM is possible, I don't think we should be
considering current x86 at all for suspend blockers.

-- 
Felipe Contreras
_______________________________________________
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)

[Florian Mickler]

On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras <felipe.contreras@gmail.com> wrote:

> Supposing there's a perfect usage of suspend blockers from user-space
> on current x86 platforms (in theory Android would have that), is the
> benefit that big to consider this a strong argument in favor of
> suspend blockers? Considering the small amount of x86 platforms using
> Android (is there any?), the fact that nobody else will use suspend
> blockers, and that x86 is already being fixed (as mentioned many times
> before) so dynamic PM is possible, I don't think we should be
> considering current x86 at all for suspend blockers.

A solution for the desktop to deprecate having to shut down the
machine would not be that bad, wouldn;t it? (Why have I to shut down
my machine anyway?) 

In my opinion such a decision (when to shutdown) has to be guided by
userspace knowledge.
Future x86 hardware is to be fixed (as I read in this discussion), so
using suspend blockers could be the tool of choice. 

But alright. Let's be a little bit more focused on the present
situation:

1) There currently is no other solution.
2) It is a first stepping stone to bringing android to mainline.
3) Any "perfect" solution will emerge anyway. As there are so many
people with so strong opinions engaged in this discussion, I'm
confident.
4) If there is a better solution, android will shurely adapt it as
soon as it is there. 

Cheers,
Flo

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

[Thomas Gleixner]

On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:26:27 +0300
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> > Supposing there's a perfect usage of suspend blockers from user-space
> > on current x86 platforms (in theory Android would have that), is the
> > benefit that big to consider this a strong argument in favor of
> > suspend blockers? Considering the small amount of x86 platforms using
> > Android (is there any?), the fact that nobody else will use suspend
> > blockers, and that x86 is already being fixed (as mentioned many times
> > before) so dynamic PM is possible, I don't think we should be
> > considering current x86 at all for suspend blockers.
> 
> A solution for the desktop to deprecate having to shut down the
> machine would not be that bad, wouldn;t it? (Why have I to shut down
> my machine anyway?) 
> 
> In my opinion such a decision (when to shutdown) has to be guided by
> userspace knowledge.
> Future x86 hardware is to be fixed (as I read in this discussion), so
> using suspend blockers could be the tool of choice. 
> 
> But alright. Let's be a little bit more focused on the present
> situation:
> 
> 1) There currently is no other solution.

Wrong. The solutions are there, just being refused.

> 2) It is a first stepping stone to bringing android to mainline.

Crap. Once we have an userspace API we are bound to it. Period. 

Also there is no technical reason why the whole driver stack cannot
be merged w/o the suspend blockers.

> 3) Any "perfect" solution will emerge anyway. As there are so many
> people with so strong opinions engaged in this discussion, I'm
> confident.

Yes, and that needs cooperation and compromises from both sides and
not just blindly defining that there is no other solution.

> 4) If there is a better solution, android will shurely adapt it as
> soon as it is there. 

Sure, after we accepted the crap there is no incentive at all.

Stop that advertising campaing already.

No thanks,

	tglx

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

[Florian Mickler]

On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> Stop that advertising campaing already.

Stop advertising that there is no problem. 

> 
> No thanks,
> 
> 	tglx

Cheers,
Flo

(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering and not dismissing the problem. This was pointed at
Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")

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

[Thomas Gleixner]

On Sat, 5 Jun 2010, Florian Mickler wrote:

> On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > Stop that advertising campaing already.
> 
> Stop advertising that there is no problem. 
> 
> > 
> > No thanks,
> > 
> > 	tglx
> 
> Cheers,
> Flo
> 
> (Sorry, crossfire. Caused
> by you answering in the wrong subthread. I know that you are
> engineering and not dismissing the problem. This was pointed at
> Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")

Welcome to my killfile.

 

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

[Alan Cox]

On Wed, 02 Jun 2010 11:10:51 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
> 
> 
> > If I understood you correctly then you can shutdown the CPU in idle
> > completelty already, but that's not enough due to:
> > 
> >     1) crappy applications keeping the cpu away from idle
> >     2) timers firing
> > 
> > Would solving those two issues be sufficient for you or am I missing
> > something ?
> 
> Aren't the container snapshot/resume people fighting the same set of
> problems here?

And virtualisation - its a big one for virtualisation because if you've
got 1000 misbehaving guests generating 100 wakeups a second you've got a
problem ....

Alan

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: [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)

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

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

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

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

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

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

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

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

[Neil Brown]

On Thu, 27 May 2010 23:40:29 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> 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

Reasonable definition I think.  However the current implementation doesn't
exactly match it.
With the current implementation you risk losing wakeups *independent* of the
hardware properties.
Even with ideal hardware events can be lost - by which I mean that they will
not be seen until some other event effects a wake-up.
e.g. the interrupt which signals the event happens immediately before the
suspend is requested (or maybe at the same time as), but the process which
needs to handle the event doesn't get a chance to see it before the suspend
procedure freezes that process, and even if it did it would have no way to
abort the suspend.

So I submit that the current implementation doesn't match your description of
"forced", is therefore buggy, and that if it were fixed, that would be
sufficient to meet the immediate needs of android.

NeilBrown

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

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

[Rafael J. Wysocki]

On Monday 31 May 2010, Neil Brown wrote:
> On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> 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
> 
> Reasonable definition I think.  However the current implementation doesn't
> exactly match it.
> With the current implementation you risk losing wakeups *independent* of the
> hardware properties.

Define "losing", please.

Currently, we simply don't regard hardware signals occuring _during_ the
suspend operation itself as wakeups (unless they are wakeup interrupts to be
precise, because these _are_ taken into account by our current code).

The reason is that the meaning of given event may be _different_ at run time
and after the system has been suspended.  For example, consider a power button
on a PC box.  If it's pressed at run time, it usually means "power off the
system" to the kernel.  After the system has been suspended, however, it means
"wake up".  So, you have to switch from one interpretation of the event to the
other and that's not an atomic operaition (to put it lightly).

> Even with ideal hardware events can be lost - by which I mean that they will
> not be seen until some other event effects a wake-up.
> e.g. the interrupt which signals the event happens immediately before the
> suspend is requested (or maybe at the same time as), but the process which
> needs to handle the event doesn't get a chance to see it before the suspend
> procedure freezes that process, and even if it did it would have no way to
> abort the suspend.
> 
> So I submit that the current implementation doesn't match your description of
> "forced", is therefore buggy, and that if it were fixed, that would be
> sufficient to meet the immediate needs of android.

I don't really think it may be fixed with respect to every possible kind of
hardware.  On platforms where I/O interrupts are wakeup events it should
work right now.  On other platforms it may be impossible to overcome hardware
limitations.

Thanks,
Rafael

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

[Neil Brown]

On Tue, 1 Jun 2010 00:05:19 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Monday 31 May 2010, Neil Brown wrote:
> > On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> 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
> > 
> > Reasonable definition I think.  However the current implementation doesn't
> > exactly match it.
> > With the current implementation you risk losing wakeups *independent* of the
> > hardware properties.
> 
> Define "losing", please.

I did.  See next line in my original.
 "... by which I mean that they will not be seen until some other event
 effects a wake-up".  By "seen" I mean "a user-space process has had a chance
 to react to the event, including having the opportunity to abort the suspend
 (or ensure an immediate wake-up)".
Another way of saying it might be that the event - as an abstract concept -
does not reach it's final destination promptly.  This "final destination" may
be well outside the kernel.

> 
> Currently, we simply don't regard hardware signals occuring _during_ the
> suspend operation itself as wakeups (unless they are wakeup interrupts to be
> precise, because these _are_ taken into account by our current code).
> 
> The reason is that the meaning of given event may be _different_ at run time
> and after the system has been suspended.  For example, consider a power button
> on a PC box.  If it's pressed at run time, it usually means "power off the
> system" to the kernel.  After the system has been suspended, however, it means
> "wake up".  So, you have to switch from one interpretation of the event to the
> other and that's not an atomic operaition (to put it lightly).

Yes, a suspend-toggle switch is inherently racy.  It is only wake-up sources
that are not inherently racy that are interesting.  e.g. a serial line from a
GSM device which reports "You have an SMS message".
I want to be able to turn my freerunner upside-down by which I tell it (via
the accelerometers) that I am done and want it to turn off.  If a TXT message
comes in just then, I don't want it to suspend, I want it to make an alert
noise.
I can put code in to ignore the accelerometer if a txt has just recently come
in, but if the TXT arrives just as the write to /sys/power/state starts, the
UART interrupt handler could have completed before it has the PRE_SUSPEND
method called.  So the suspend will complete and the wakeup from the UART
will have been "lost" in that the event didn't get all the way to its
destination: my ear.
My freerunner has a single core so without CONFIG_PREEMPT it may be that
there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
soft_irq thread has a chance to finish handling of the interrupt (my
knowledge of these details is limits).  But on a muilti-core device I think
there would definitely be a race-window.

Thanks,
NeilBrown

> 
> > Even with ideal hardware events can be lost - by which I mean that they will
> > not be seen until some other event effects a wake-up.
> > e.g. the interrupt which signals the event happens immediately before the
> > suspend is requested (or maybe at the same time as), but the process which
> > needs to handle the event doesn't get a chance to see it before the suspend
> > procedure freezes that process, and even if it did it would have no way to
> > abort the suspend.
> > 
> > So I submit that the current implementation doesn't match your description of
> > "forced", is therefore buggy, and that if it were fixed, that would be
> > sufficient to meet the immediate needs of android.
> 
> I don't really think it may be fixed with respect to every possible kind of
> hardware.  On platforms where I/O interrupts are wakeup events it should
> work right now.  On other platforms it may be impossible to overcome hardware
> limitations.
> 
> Thanks,
> Rafael
> --
> 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/

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

[Rafael J. Wysocki]

On Tuesday 01 June 2010, Neil Brown wrote:
> On Tue, 1 Jun 2010 00:05:19 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Monday 31 May 2010, Neil Brown wrote:
> > > On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> > > Thomas Gleixner <tglx@linutronix.de> 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
> > > 
> > > Reasonable definition I think.  However the current implementation doesn't
> > > exactly match it.
> > > With the current implementation you risk losing wakeups *independent* of the
> > > hardware properties.
> > 
> > Define "losing", please.
> 
> I did.  See next line in my original.
>  "... by which I mean that they will not be seen until some other event
>  effects a wake-up".

OK, sorry.

>  By "seen" I mean "a user-space process has had a chance
>  to react to the event, including having the opportunity to abort the suspend
>  (or ensure an immediate wake-up)".
> Another way of saying it might be that the event - as an abstract concept -
> does not reach it's final destination promptly.  This "final destination" may
> be well outside the kernel.
>
> > Currently, we simply don't regard hardware signals occuring _during_ the
> > suspend operation itself as wakeups (unless they are wakeup interrupts to be
> > precise, because these _are_ taken into account by our current code).
> > 
> > The reason is that the meaning of given event may be _different_ at run time
> > and after the system has been suspended.  For example, consider a power button
> > on a PC box.  If it's pressed at run time, it usually means "power off the
> > system" to the kernel.  After the system has been suspended, however, it means
> > "wake up".  So, you have to switch from one interpretation of the event to the
> > other and that's not an atomic operaition (to put it lightly).
> 
> Yes, a suspend-toggle switch is inherently racy.

For this reason we generally have to assume that some events occuring during
suspend will only be seen by user space after resume.  Now, since we make
such an assumption anyway, there's a little point working around some races
related to it while leaving the others as they are (that wouldn't improve
things all that much).

> It is only wake-up sources that are not inherently racy that are interesting.
> e.g. a serial line from a GSM device which reports "You have an SMS message".
> I want to be able to turn my freerunner upside-down by which I tell it (via
> the accelerometers) that I am done and want it to turn off.  If a TXT message
> comes in just then, I don't want it to suspend, I want it to make an alert
> noise.
> I can put code in to ignore the accelerometer if a txt has just recently come
> in, but if the TXT arrives just as the write to /sys/power/state starts, the
> UART interrupt handler could have completed before it has the PRE_SUSPEND
> method called.  So the suspend will complete and the wakeup from the UART
> will have been "lost" in that the event didn't get all the way to its
> destination: my ear.

As I said before, we generally can't prevent such things from happening,
because even if we handle the particular race described above, it still is
possible that the event will be "lost" if it arrives just a bit later (eg.
during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
solve the entire problem while increasing complexity.

> My freerunner has a single core so without CONFIG_PREEMPT it may be that
> there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> soft_irq thread has a chance to finish handling of the interrupt (my
> knowledge of these details is limits).  But on a muilti-core device I think
> there would definitely be a race-window.

Yes, there always will be a race window.  The only thing we can do is to
narrow it, but we cannot really close it (at least not on a PC, but I'm not
really sure it can be closed at all).

If you really want _all_ events to be delivered timely, the only way to go is
to avoid using suspend (and use the idle framework for power management).

Thanks,
Rafael

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

[Thomas Gleixner]

On Tue, 1 Jun 2010, Rafael J. Wysocki wrote:
> On Tuesday 01 June 2010, Neil Brown wrote:
> > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > soft_irq thread has a chance to finish handling of the interrupt (my
> > knowledge of these details is limits).  But on a muilti-core device I think
> > there would definitely be a race-window.
> 
> Yes, there always will be a race window.  The only thing we can do is to
> narrow it, but we cannot really close it (at least not on a PC, but I'm not
> really sure it can be closed at all).

It can be closed, when the state transition from normal event delivery
to wakeup mode is state safe, which it is on most platforms which are
designed for the mobile space.

Not so the current PC style x86 platforms, which are not relevant for
the problem at hand at all. Really, that stuff is going either to gain
sane properties or it's just going into the irrelevant realm.

Any attempt to solve the current x86/ACPI/BIOS/mess is waste of time
and is inevitably going to prevent progress.

> If you really want _all_ events to be delivered timely, the only way to go is
> to avoid using suspend (and use the idle framework for power management).

Amen.

	tglx

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

[Neil Brown]

On Tue, 1 Jun 2010 02:32:20 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Tuesday 01 June 2010, Neil Brown wrote:
> > I want to be able to turn my freerunner upside-down by which I tell it (via
> > the accelerometers) that I am done and want it to turn off.  If a TXT message
> > comes in just then, I don't want it to suspend, I want it to make an alert
> > noise.
> > I can put code in to ignore the accelerometer if a txt has just recently come
> > in, but if the TXT arrives just as the write to /sys/power/state starts, the
> > UART interrupt handler could have completed before it has the PRE_SUSPEND
> > method called.  So the suspend will complete and the wakeup from the UART
> > will have been "lost" in that the event didn't get all the way to its
> > destination: my ear.
> 
> As I said before, we generally can't prevent such things from happening,
> because even if we handle the particular race described above, it still is
> possible that the event will be "lost" if it arrives just a bit later (eg.
> during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> solve the entire problem while increasing complexity.
> 
> > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > soft_irq thread has a chance to finish handling of the interrupt (my
> > knowledge of these details is limits).  But on a muilti-core device I think
> > there would definitely be a race-window.
> 
> Yes, there always will be a race window.  The only thing we can do is to
> narrow it, but we cannot really close it (at least not on a PC, but I'm not
> really sure it can be closed at all).

Well you are the expert so I assume you are right, but I would really like to
understand why this is.

I guess that if the event was delivered as an edge-triggered interrupt which
the interrupt controller couldn't latch, then it might get lost.  Is that
what happens?
But if the event comes in as a level-triggered (or latched) interrupt, then
the driver simply chooses not to acknowledge the interrupt after PRE_SUSPEND
until RESUME.  Then any suspend would immediately be woken.  Maybe the window
for ignoring interrupt would have to be a bit smaller than that, but it
should be a well defined window that can be locked.
Why cannot we carry this sort of guarantee all the way up to user-space and
beyond?  Am I completely misunderstanding the hardware?

And if you are right that the race window cannot be closed, then the whole
suspend-blocker infrastructure is pointless as the purpose of it is simply to
close that window.  If it really does not and cannot work, then it would be
best to reject it for that reason rather than for less concrete aesthetic
arguments.
But presumably it does work in practice on Android hardware so ..... confused.

Having just seen the email from Thomas, maybe you mean that it cannot be
closed on devices using ACPI, but can on other devices.  I can sort-of
imagine how that would be the case (I tried reading an ACPI spec once - my
hat is of to those of you who understand it).
That shouldn't prevent us from closing the race window on "sane" hardware
that allows it.  This would, I think, be sufficient for Android's needs.

I'm hoping we can get agreement on:
  - there is a race with suspend
  - it can be closed on the sort of hardware that is typically used in the
    mobile space
  - closing it would address the need which lead to the suspend-block
    proposal.

If we have agreement on that, we can move on to
  - should we close the race? (hopefully "yes" because bugs should be fixed).
  - how should we close the race? (lots of room for exploration there).


Thanks,
NeilBrown

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

[Thomas Gleixner]

On Tue, 1 Jun 2010, Neil Brown wrote:
> And if you are right that the race window cannot be closed, then the whole
> suspend-blocker infrastructure is pointless as the purpose of it is simply to
> close that window.  If it really does not and cannot work, then it would be
> best to reject it for that reason rather than for less concrete aesthetic
> arguments.
> But presumably it does work in practice on Android hardware so ..... confused.
> 
> Having just seen the email from Thomas, maybe you mean that it cannot be
> closed on devices using ACPI, but can on other devices.  I can sort-of
> imagine how that would be the case (I tried reading an ACPI spec once - my
> hat is of to those of you who understand it).
> That shouldn't prevent us from closing the race window on "sane" hardware
> that allows it.  This would, I think, be sufficient for Android's needs.
> 
> I'm hoping we can get agreement on:
>   - there is a race with suspend

That's a matter of how you define "suspend". 

If "suspend" is another deep idle state and the hardware is sane,
there is no race at all - assumed that the driver/platform developer
got it right. It's not rocket science to transition from "normal" irq
delivery to wakeup based delivery raceless (except for PC style x86
hardware of today)

If "suspend" is the thing we are used to via /sys/power/state then the
race will persist forever except for the suspend blocker workaround,
which we can express in QoS terms as well w/o adding another suspend
related user space API.

Thanks,

	tglx

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

[Alan Stern]

On Tue, 1 Jun 2010, Neil Brown wrote:

> > As I said before, we generally can't prevent such things from happening,
> > because even if we handle the particular race described above, it still is
> > possible that the event will be "lost" if it arrives just a bit later (eg.
> > during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> > solve the entire problem while increasing complexity.
> > 
> > > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > > soft_irq thread has a chance to finish handling of the interrupt (my
> > > knowledge of these details is limits).  But on a muilti-core device I think
> > > there would definitely be a race-window.
> > 
> > Yes, there always will be a race window.  The only thing we can do is to
> > narrow it, but we cannot really close it (at least not on a PC, but I'm not
> > really sure it can be closed at all).
> 
> Well you are the expert so I assume you are right, but I would really like to
> understand why this is.
> 
> I guess that if the event was delivered as an edge-triggered interrupt which
> the interrupt controller couldn't latch, then it might get lost.  Is that
> what happens?

You're barking up the wrong tree.  If I understand correctly, Rafael is
saying that there's a race involving events which are not _wakeup_
events.  If a non-wakeup event arrives shortly before a suspend, it can
have its normal effect.  If it arrives while a suspend is in progress,
its delivery may be delayed until the system resumes.  And if it
arrives after the system is fully suspended, it may never be noticed at
all.

With wakeup events the problem isn't so bad.  Wakeup events are always
noticed, and if the system is designed properly they will either abort
a suspend-in-progress or else cause the system to resume as soon as the
suspend is complete.  (Linux is not yet properly designed in this
sense.)

Or maybe I'm misunderstanding also, and Rafael is saying that there's 
a race involving events whose meaning changes depending on whether or 
not the system is asleep.  This is obviously true and clearly 
unavoidable.

> And if you are right that the race window cannot be closed, then the whole
> suspend-blocker infrastructure is pointless as the purpose of it is simply to
> close that window.  If it really does not and cannot work, then it would be
> best to reject it for that reason rather than for less concrete aesthetic
> arguments.
> But presumably it does work in practice on Android hardware so ..... confused.

The point you're missing is that Android works with regard to wakeup
events.  It doesn't necessarily always receive non-wakeup events
(although I don't know how Android classifies events -- maybe
everything is a wakeup event for them).

Alan Stern

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

[Neil Brown]

On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 1 Jun 2010, Neil Brown wrote:
> > And if you are right that the race window cannot be closed, then the whole
> > suspend-blocker infrastructure is pointless as the purpose of it is simply to
> > close that window.  If it really does not and cannot work, then it would be
> > best to reject it for that reason rather than for less concrete aesthetic
> > arguments.
> > But presumably it does work in practice on Android hardware so ..... confused.
> > 
> > Having just seen the email from Thomas, maybe you mean that it cannot be
> > closed on devices using ACPI, but can on other devices.  I can sort-of
> > imagine how that would be the case (I tried reading an ACPI spec once - my
> > hat is of to those of you who understand it).
> > That shouldn't prevent us from closing the race window on "sane" hardware
> > that allows it.  This would, I think, be sufficient for Android's needs.
> > 
> > I'm hoping we can get agreement on:
> >   - there is a race with suspend
> 
> That's a matter of how you define "suspend". 

I define "suspend" as

    echo mem > /sys/power/state

> 
> If "suspend" is another deep idle state and the hardware is sane,
> there is no race at all - assumed that the driver/platform developer
> got it right. It's not rocket science to transition from "normal" irq
> delivery to wakeup based delivery raceless (except for PC style x86
> hardware of today)
> 
> If "suspend" is the thing we are used to via /sys/power/state then the
> race will persist forever except for the suspend blocker workaround,
> which we can express in QoS terms as well w/o adding another suspend
> related user space API.

I'm not interested in adding another user-space API if it can possibly be
avoided, and I think it can.  But that is a later step in the process.

I think you have acknowledged that there is a race with suspend - thanks.
Next step was "can it be closed".
You seem to suggest that it can, but you describe it as a "work around"
rather than a "bug fix"...

Do you agree that the race is a "bug", and therefore it is appropriate to
"fix" it assuming an acceptable fix can be found (which I think it can)?

If you agree that it is appropriate for try to fix this bug, then the next
step would be to get the Android devs to agree that a fix could - in
principle - address the need for which they created suspend-blockers.
Arve: can you confirm that?

Then, with a clear and agreed goal, we can look at possible fixes.

Thanks,
NeilBrown

> 
> Thanks,
> 
> 	tglx

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

[Florian Mickler]

On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown <neilb@suse.de> wrote:

> On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:

> > If "suspend" is another deep idle state and the hardware is sane,
> > there is no race at all - assumed that the driver/platform developer
> > got it right. It's not rocket science to transition from "normal" irq
> > delivery to wakeup based delivery raceless (except for PC style x86
> > hardware of today)

> > If "suspend" is the thing we are used to via /sys/power/state then the
> > race will persist forever except for the suspend blocker workaround,
> > which we can express in QoS terms as well w/o adding another suspend
> > related user space API.

Can you explain the difference between the /sys/power/state thing? Is
it the reprogramming of wake-sources as mentioned by Raffael?

In an idle based suspend I assume there would be no new wake-sources
on suspending.

> I'm not interested in adding another user-space API if it can possibly be
> avoided, and I think it can.  But that is a later step in the process.
> 
> I think you have acknowledged that there is a race with suspend - thanks.
> Next step was "can it be closed".
> You seem to suggest that it can, but you describe it as a "work around"
> rather than a "bug fix"...

Well as far as I get it, the workaround is to not suspend in sitations
where a race is likely to occur. (I.e. block suspend)

> 
> Do you agree that the race is a "bug", and therefore it is appropriate to
> "fix" it assuming an acceptable fix can be found (which I think it can)?
> 
> If you agree that it is appropriate for try to fix this bug, then the next
> step would be to get the Android devs to agree that a fix could - in
> principle - address the need for which they created suspend-blockers.
> Arve: can you confirm that?
> 
> Then, with a clear and agreed goal, we can look at possible fixes.
> 
> Thanks,
> NeilBrown
> 
> > 
> > Thanks,
> > 
> > 	tglx

cheers,
Flo

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

[Thomas Gleixner]

On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> I think you have acknowledged that there is a race with suspend - thanks.
> Next step was "can it be closed".
> You seem to suggest that it can, but you describe it as a "work around"
> rather than a "bug fix"...
> 
> Do you agree that the race is a "bug", and therefore it is appropriate to
> "fix" it assuming an acceptable fix can be found (which I think it can)?

If we can fix it, yes we definitely should do and not work around it.
 
Thanks,

	tglx

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

[Neil Brown]

On Mon, 31 May 2010 22:10:00 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > As I said before, we generally can't prevent such things from happening,
> > > because even if we handle the particular race described above, it still is
> > > possible that the event will be "lost" if it arrives just a bit later (eg.
> > > during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> > > solve the entire problem while increasing complexity.
> > > 
> > > > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > > > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > > > soft_irq thread has a chance to finish handling of the interrupt (my
> > > > knowledge of these details is limits).  But on a muilti-core device I think
> > > > there would definitely be a race-window.
> > > 
> > > Yes, there always will be a race window.  The only thing we can do is to
> > > narrow it, but we cannot really close it (at least not on a PC, but I'm not
> > > really sure it can be closed at all).
> > 
> > Well you are the expert so I assume you are right, but I would really like to
> > understand why this is.
> > 
> > I guess that if the event was delivered as an edge-triggered interrupt which
> > the interrupt controller couldn't latch, then it might get lost.  Is that
> > what happens?
> 
> You're barking up the wrong tree.  If I understand correctly, Rafael is
> saying that there's a race involving events which are not _wakeup_
> events.  If a non-wakeup event arrives shortly before a suspend, it can
> have its normal effect.  If it arrives while a suspend is in progress,
> its delivery may be delayed until the system resumes.  And if it
> arrives after the system is fully suspended, it may never be noticed at
> all.

I am only thinking of wakeup event. (And I am only thinking of suspend as
initiated by writing 'mem' to /sys/power/state.)
I agree that non-wakeup events can easily be delayed by suspend, and this is
by design and no-one wants it to change.

> 
> With wakeup events the problem isn't so bad.  Wakeup events are always
> noticed, and if the system is designed properly they will either abort
> a suspend-in-progress or else cause the system to resume as soon as the
> suspend is complete.  (Linux is not yet properly designed in this
> sense.)

This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
processed by the driver just before suspend may not get all the way out to
it's final destination (possibly in meat-space) until after some other event
wakes the device.  It is not possible to guarantee full delivery of a wakeup
event with Linux in its current state.  This is a bug.

> 
> Or maybe I'm misunderstanding also, and Rafael is saying that there's 
> a race involving events whose meaning changes depending on whether or 
> not the system is asleep.  This is obviously true and clearly 
> unavoidable.
> 
> > And if you are right that the race window cannot be closed, then the whole
> > suspend-blocker infrastructure is pointless as the purpose of it is simply to
> > close that window.  If it really does not and cannot work, then it would be
> > best to reject it for that reason rather than for less concrete aesthetic
> > arguments.
> > But presumably it does work in practice on Android hardware so ..... confused.
> 
> The point you're missing is that Android works with regard to wakeup
> events.  It doesn't necessarily always receive non-wakeup events
> (although I don't know how Android classifies events -- maybe
> everything is a wakeup event for them).
> 

I don't think I'm missing that.  Wakeup events are the only events of
interest.  But wakeup events are more than just low-level hardware events.
They are also the virtual events that are a direct consequence of the
original hardware event.
A UART asserts 'data ready' which is routed to an IO interrupt line that
wakes the device.  This is a wakeup event.
So are the bits that appear on the data line which represent the data
So are the characters that appear on the serial port
So is the "here is a message from the GSM processor" event
So is the "there is a new TXT message" event
So is the "'beep beep beep' out the speaker" event

All these events are wakeup events, and should abort or instant-resume the
system.  Currently only the first can be guaranteed to do this (... and maybe
the second, depending on the details of the implementation).
suspend-blocks effectively pass a lock from one event to the next to ensure
that all of these event block the suspend.  There are various other ways to
achieve the same thing, and I think it can be done with no significant change
to the API.  But some how we need to allow all of these events to be
linked wake-up events, not just the first one.

Thanks,
NeilBrown

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

[Rafael J. Wysocki]

On Tuesday 01 June 2010, Alan Stern wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > As I said before, we generally can't prevent such things from happening,
> > > because even if we handle the particular race described above, it still is
> > > possible that the event will be "lost" if it arrives just a bit later (eg.
> > > during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> > > solve the entire problem while increasing complexity.
> > > 
> > > > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > > > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > > > soft_irq thread has a chance to finish handling of the interrupt (my
> > > > knowledge of these details is limits).  But on a muilti-core device I think
> > > > there would definitely be a race-window.
> > > 
> > > Yes, there always will be a race window.  The only thing we can do is to
> > > narrow it, but we cannot really close it (at least not on a PC, but I'm not
> > > really sure it can be closed at all).
> > 
> > Well you are the expert so I assume you are right, but I would really like to
> > understand why this is.
> > 
> > I guess that if the event was delivered as an edge-triggered interrupt which
> > the interrupt controller couldn't latch, then it might get lost.  Is that
> > what happens?
> 
> You're barking up the wrong tree.  If I understand correctly, Rafael is
> saying that there's a race involving events which are not _wakeup_
> events.  If a non-wakeup event arrives shortly before a suspend, it can
> have its normal effect.  If it arrives while a suspend is in progress,
> its delivery may be delayed until the system resumes.  And if it
> arrives after the system is fully suspended, it may never be noticed at
> all.
> 
> With wakeup events the problem isn't so bad.  Wakeup events are always
> noticed, and if the system is designed properly they will either abort
> a suspend-in-progress or else cause the system to resume as soon as the
> suspend is complete.  (Linux is not yet properly designed in this
> sense.)
> 
> Or maybe I'm misunderstanding also, and Rafael is saying that there's 
> a race involving events whose meaning changes depending on whether or 
> not the system is asleep.  This is obviously true and clearly 
> unavoidable.

In fact I was referring to both in different places.  That's why what I said
wasn't too clear, sorry about that.

Rafael

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

[Arve Hjønnevåg]

On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday 31 May 2010, Neil Brown wrote:
>> On Thu, 27 May 2010 23:40:29 +0200 (CEST)
>> Thomas Gleixner <tglx@linutronix.de> 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
>>
>> Reasonable definition I think.  However the current implementation doesn't
>> exactly match it.
>> With the current implementation you risk losing wakeups *independent* of the
>> hardware properties.
>
> Define "losing", please.
>
> Currently, we simply don't regard hardware signals occuring _during_ the
> suspend operation itself as wakeups (unless they are wakeup interrupts to be
> precise, because these _are_ taken into account by our current code).
>
> The reason is that the meaning of given event may be _different_ at run time
> and after the system has been suspended.  For example, consider a power button
> on a PC box.  If it's pressed at run time, it usually means "power off the
> system" to the kernel.  After the system has been suspended, however, it means
> "wake up".  So, you have to switch from one interpretation of the event to the
> other and that's not an atomic operaition (to put it lightly).
>
>> Even with ideal hardware events can be lost - by which I mean that they will
>> not be seen until some other event effects a wake-up.
>> e.g. the interrupt which signals the event happens immediately before the
>> suspend is requested (or maybe at the same time as), but the process which
>> needs to handle the event doesn't get a chance to see it before the suspend
>> procedure freezes that process, and even if it did it would have no way to
>> abort the suspend.
>>
>> So I submit that the current implementation doesn't match your description of
>> "forced", is therefore buggy, and that if it were fixed, that would be
>> sufficient to meet the immediate needs of android.
>
> I don't really think it may be fixed with respect to every possible kind of
> hardware.  On platforms where I/O interrupts are wakeup events it should
> work right now.  On other platforms it may be impossible to overcome hardware
> limitations.
>

There is no reason you cannot make the rtc alarms work reliably on x86
hardware. Even if you may loose key events while suspending I think it
is still valuable to have reliable alarms. I gave an example earlier
why reliable alarms are useful (dvr application).

-- 
Arve Hjønnevåg

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

[Rafael J. Wysocki]

On Tuesday 01 June 2010, Arve Hjønnevåg wrote:
> On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday 31 May 2010, Neil Brown wrote:
> >> On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> >> Thomas Gleixner <tglx@linutronix.de> 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
> >>
> >> Reasonable definition I think.  However the current implementation doesn't
> >> exactly match it.
> >> With the current implementation you risk losing wakeups *independent* of the
> >> hardware properties.
> >
> > Define "losing", please.
> >
> > Currently, we simply don't regard hardware signals occuring _during_ the
> > suspend operation itself as wakeups (unless they are wakeup interrupts to be
> > precise, because these _are_ taken into account by our current code).
> >
> > The reason is that the meaning of given event may be _different_ at run time
> > and after the system has been suspended.  For example, consider a power button
> > on a PC box.  If it's pressed at run time, it usually means "power off the
> > system" to the kernel.  After the system has been suspended, however, it means
> > "wake up".  So, you have to switch from one interpretation of the event to the
> > other and that's not an atomic operaition (to put it lightly).
> >
> >> Even with ideal hardware events can be lost - by which I mean that they will
> >> not be seen until some other event effects a wake-up.
> >> e.g. the interrupt which signals the event happens immediately before the
> >> suspend is requested (or maybe at the same time as), but the process which
> >> needs to handle the event doesn't get a chance to see it before the suspend
> >> procedure freezes that process, and even if it did it would have no way to
> >> abort the suspend.
> >>
> >> So I submit that the current implementation doesn't match your description of
> >> "forced", is therefore buggy, and that if it were fixed, that would be
> >> sufficient to meet the immediate needs of android.
> >
> > I don't really think it may be fixed with respect to every possible kind of
> > hardware.  On platforms where I/O interrupts are wakeup events it should
> > work right now.  On other platforms it may be impossible to overcome hardware
> > limitations.
> >
> 
> There is no reason you cannot make the rtc alarms work reliably on x86
> hardware.

They usually work, but not in 100% of cases.

Generally, "x86 hardware" is a broad category, where modern ones have much more
interesting capabilities than the older.

> Even if you may loose key events while suspending I think it
> is still valuable to have reliable alarms.

I don't think anyone will argue with that. :-)

Rafael

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: [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)

[Paul Mundt]

On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > 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. 
> 
For systems with runtime PM and deep idle states in cpuidle suspend is
already fairly opportunistic. If sleep states (including suspend to RAM
and CPU off) are factored in to cpuidle then it's very easy to get in to
situations where everything simply shuts off automatically, which can be
problematic if a platform doesn't expose any external wakeup sources.

Platforms still need to be able to establish some heuristics, whether
this is via blocking certain state transitions or simply defining a
maximum acceptable suspend depth irrespective of latency (at least we
presently don't have a clean interface for preventing entry in to
impossible to recover from idle states outside of latency hints via PM
QoS, or at least not one that I'm aware of).

On the other hand, while this isn't that difficult for the UP case it
does pose more problems for the SMP case. Presently the suspend paths
(suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
enabling of non-boot CPUs via CPU hotplug explicitly, which will clear
them from the online CPU map. We would have to rework the semantics a bit
if cpuidle were also permitted to opportunistically offline CPUs.

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

[Brian Swetland]

On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>
> On the other hand, while this isn't that difficult for the UP case it
> does pose more problems for the SMP case. Presently the suspend paths
> (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
> enabling of non-boot CPUs via CPU hotplug explicitly, which will clear
> them from the online CPU map. We would have to rework the semantics a bit
> if cpuidle were also permitted to opportunistically offline CPUs.

That's definitely something we'd be interested in looking at.  Some
upcoming ARM v7 architecture SMP SoCs we're seeing will support full
independent clock scaling and power gating for the individual cores --
if there's not enough work to keep the 2nd (or nth) cpu busy, there
would be good power savings to be had shutting it down.

I haven't poked around too much with how things work in SMP
environments -- are there per-cpu idle threads?

Brian

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

[Peter Zijlstra]

On Wed, 2010-06-02 at 23:58 -0700, Brian Swetland wrote:
> 
> I haven't poked around too much with how things work in SMP
> environments -- are there per-cpu idle threads? 

Yes, and we recently grew the infrastructure for asymmetric MP in the
processing capacity sense.

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: [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)

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

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

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)

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

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

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

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

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

[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

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


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