[PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

I guess I should have sent this to you too. Only sent to linux-pm.

The inspiration for this patch series is the N9 CPU frequency boost
upon input events:

http://www.spinics.net/lists/cpufreq/msg00667.html

and the related changes in git://codeaurora.org/kernel/msm.git tree.
Those patches modify the ondemand cpufreq governor. This patch series
adds minimum and maximum CPU frequency as PM QoS parameters and
modifies the cpufreq core to enforce the PM QoS limits. There is also
an example module for boosting the frequency upon input events.

I've been testing these changes against Ubuntu 3.2 kernel on a Dell
E6420 with the ACPI cpufreq driver. The patches are against
linux-next/master, compile tested against it.

	--Antti

Alex Frid (1):
  PM QoS: Simplify PM QoS expansion/merge

Antti P Miettinen (5):
  PM QoS: Add CPU frequency min/max as PM QoS params
  cpufreq: Export user_policy min/max
  cpufreq: Preserve sysfs min/max request
  cpufreq: Enforce PM QoS min/max limits
  input: CPU frequency booster

 drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
 drivers/input/Kconfig         |    9 ++
 drivers/input/Makefile        |    1 +
 drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_qos.h        |   19 ++++-
 kernel/power/qos.c            |   55 ++++++++++----
 6 files changed, 293 insertions(+), 22 deletions(-)
 create mode 100644 drivers/input/input-cfboost.c

-- 
1.7.4.1

[PATCH 1/6] PM QoS: Simplify PM QoS expansion/merge

[Antti P Miettinen]

From: Alex Frid <afrid@nvidia.com>

- Replace class ID #define with enumeration
- Loop through PM QoS objects during initialization (rather than
  initializing them one-by-one)

Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-by: Antti Miettinen <amiettinen@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
---
 include/linux/pm_qos.h |   14 +++++++++-----
 kernel/power/qos.c     |   23 ++++++++++-------------
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index e5bbcba..5ac91d8 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -9,12 +9,16 @@
 #include <linux/miscdevice.h>
 #include <linux/device.h>
 
-#define PM_QOS_RESERVED 0
-#define PM_QOS_CPU_DMA_LATENCY 1
-#define PM_QOS_NETWORK_LATENCY 2
-#define PM_QOS_NETWORK_THROUGHPUT 3
+enum {
+	PM_QOS_RESERVED = 0,
+	PM_QOS_CPU_DMA_LATENCY,
+	PM_QOS_NETWORK_LATENCY,
+	PM_QOS_NETWORK_THROUGHPUT,
+
+	/* insert new class ID */
+	PM_QOS_NUM_CLASSES,
+};
 
-#define PM_QOS_NUM_CLASSES 4
 #define PM_QOS_DEFAULT_VALUE -1
 
 #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 995e3bd..d6d6dbd 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -469,21 +469,18 @@ static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
 static int __init pm_qos_power_init(void)
 {
 	int ret = 0;
+	int i;
 
-	ret = register_pm_qos_misc(&cpu_dma_pm_qos);
-	if (ret < 0) {
-		printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
-		return ret;
-	}
-	ret = register_pm_qos_misc(&network_lat_pm_qos);
-	if (ret < 0) {
-		printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
-		return ret;
+	BUILD_BUG_ON(ARRAY_SIZE(pm_qos_array) != PM_QOS_NUM_CLASSES);
+
+	for (i = 1; i < PM_QOS_NUM_CLASSES; i++) {
+		ret = register_pm_qos_misc(pm_qos_array[i]);
+		if (ret < 0) {
+			printk(KERN_ERR "pm_qos_param: %s setup failed\n",
+			       pm_qos_array[i]->name);
+			return ret;
+		}
 	}
-	ret = register_pm_qos_misc(&network_throughput_pm_qos);
-	if (ret < 0)
-		printk(KERN_ERR
-			"pm_qos_param: network_throughput setup failed\n");
 
 	return ret;
 }
-- 
1.7.4.1

[PATCH 2/6] PM QoS: Add CPU frequency min/max as PM QoS params

[Antti P Miettinen]

Add minimum and maximum CPU frequency as PM QoS parameters.

Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
 include/linux/pm_qos.h |    5 +++++
 kernel/power/qos.c     |   32 +++++++++++++++++++++++++++++++-
 2 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 5ac91d8..7b8d08b 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -14,8 +14,11 @@ enum {
 	PM_QOS_CPU_DMA_LATENCY,
 	PM_QOS_NETWORK_LATENCY,
 	PM_QOS_NETWORK_THROUGHPUT,
+	PM_QOS_CPU_FREQ_MIN,
+	PM_QOS_CPU_FREQ_MAX,
 
 	/* insert new class ID */
+
 	PM_QOS_NUM_CLASSES,
 };
 
@@ -25,6 +28,8 @@ enum {
 #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
 #define PM_QOS_DEV_LAT_DEFAULT_VALUE		0
+#define PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE	0
+#define PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE	LONG_MAX
 
 struct pm_qos_request {
 	struct plist_node node;
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index d6d6dbd..66ae05e 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -101,11 +101,41 @@ static struct pm_qos_object network_throughput_pm_qos = {
 };
 
 
+static BLOCKING_NOTIFIER_HEAD(cpu_freq_min_notifier);
+static struct pm_qos_constraints cpu_freq_min_constraints = {
+	.list = PLIST_HEAD_INIT(cpu_freq_min_constraints.list),
+	.target_value = PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE,
+	.default_value = PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE,
+	.type = PM_QOS_MAX,
+	.notifiers = &cpu_freq_min_notifier,
+};
+static struct pm_qos_object cpu_freq_min_pm_qos = {
+	.constraints = &cpu_freq_min_constraints,
+	.name = "cpu_freq_min",
+};
+
+
+static BLOCKING_NOTIFIER_HEAD(cpu_freq_max_notifier);
+static struct pm_qos_constraints cpu_freq_max_constraints = {
+	.list = PLIST_HEAD_INIT(cpu_freq_max_constraints.list),
+	.target_value = PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE,
+	.default_value = PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE,
+	.type = PM_QOS_MIN,
+	.notifiers = &cpu_freq_max_notifier,
+};
+static struct pm_qos_object cpu_freq_max_pm_qos = {
+	.constraints = &cpu_freq_max_constraints,
+	.name = "cpu_freq_max",
+};
+
+
 static struct pm_qos_object *pm_qos_array[] = {
 	&null_pm_qos,
 	&cpu_dma_pm_qos,
 	&network_lat_pm_qos,
-	&network_throughput_pm_qos
+	&network_throughput_pm_qos,
+	&cpu_freq_min_pm_qos,
+	&cpu_freq_max_pm_qos
 };
 
 static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
-- 
1.7.4.1

[PATCH 3/6] cpufreq: Export user_policy min/max

[Antti P Miettinen]

Add sysfs nodes for user_policy min and max settings.

Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
 drivers/cpufreq/cpufreq.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 8c2df34..e63b29f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -364,6 +364,8 @@ show_one(cpuinfo_transition_latency, cpuinfo.transition_latency);
 show_one(scaling_min_freq, min);
 show_one(scaling_max_freq, max);
 show_one(scaling_cur_freq, cur);
+show_one(policy_min_freq, user_policy.min);
+show_one(policy_max_freq, user_policy.max);
 
 static int __cpufreq_set_policy(struct cpufreq_policy *data,
 				struct cpufreq_policy *policy);
@@ -582,6 +584,8 @@ cpufreq_freq_attr_rw(scaling_min_freq);
 cpufreq_freq_attr_rw(scaling_max_freq);
 cpufreq_freq_attr_rw(scaling_governor);
 cpufreq_freq_attr_rw(scaling_setspeed);
+cpufreq_freq_attr_ro(policy_min_freq);
+cpufreq_freq_attr_ro(policy_max_freq);
 
 static struct attribute *default_attrs[] = {
 	&cpuinfo_min_freq.attr,
@@ -595,6 +599,8 @@ static struct attribute *default_attrs[] = {
 	&scaling_driver.attr,
 	&scaling_available_governors.attr,
 	&scaling_setspeed.attr,
+	&policy_min_freq.attr,
+	&policy_max_freq.attr,
 	NULL
 };
 
-- 
1.7.4.1

[PATCH 4/6] cpufreq: Preserve sysfs min/max request

[Antti P Miettinen]

Store the value received via sysfs as the user_policy
min/max value instead of the currently enforced min/max.
This allows restoring the user min/max values when
constraints on enforced min/max change.

Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
 drivers/cpufreq/cpufreq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e63b29f..65a512b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -389,7 +389,7 @@ static ssize_t store_##file_name					\
 		return -EINVAL;						\
 									\
 	ret = __cpufreq_set_policy(policy, &new_policy);		\
-	policy->user_policy.object = policy->object;			\
+	policy->user_policy.object = new_policy.object;			\
 									\
 	return ret ? ret : count;					\
 }
-- 
1.7.4.1

[PATCH 5/6] cpufreq: Enforce PM QoS min/max limits

[Antti P Miettinen]

Observe PM QoS CPU frequency minimum and maximum in addition
to policy settings.

Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
 drivers/cpufreq/cpufreq.c |   49 +++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 65a512b..cd90cd2b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -29,6 +29,7 @@
 #include <linux/completion.h>
 #include <linux/mutex.h>
 #include <linux/syscore_ops.h>
+#include <linux/pm_qos.h>
 
 #include <trace/events/power.h>
 
@@ -1634,9 +1635,17 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
 				struct cpufreq_policy *policy)
 {
 	int ret = 0;
+	unsigned int pmin = policy->min;
+	unsigned int pmax = policy->max;
+	unsigned int qmin = pm_qos_request(PM_QOS_CPU_FREQ_MIN);
+	unsigned int qmax = pm_qos_request(PM_QOS_CPU_FREQ_MAX);
 
-	pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
-		policy->min, policy->max);
+	pr_debug("setting new policy for CPU %u: %u - %u (%u - %u) kHz\n",
+		 policy->cpu, pmin, pmax, qmin, qmax);
+
+	/* clamp the new policy to PM QoS limits */
+	policy->min = max(pmin, qmin);
+	policy->max = min(pmax, qmax);
 
 	memcpy(&policy->cpuinfo, &data->cpuinfo,
 				sizeof(struct cpufreq_cpuinfo));
@@ -1711,6 +1720,9 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
 	}
 
 error_out:
+	/* restore the limits that the policy requested */
+	policy->min = pmin;
+	policy->max = pmax;
 	return ret;
 }
 
@@ -1904,9 +1916,36 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
 }
 EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
+static int cpu_freq_notify(struct notifier_block *b,
+			   unsigned long l, void *v);
+
+static struct notifier_block min_freq_notifier = {
+	.notifier_call = cpu_freq_notify,
+};
+static struct notifier_block max_freq_notifier = {
+	.notifier_call = cpu_freq_notify,
+};
+
+static int cpu_freq_notify(struct notifier_block *b,
+			   unsigned long l, void *v)
+{
+	int cpu;
+	pr_debug("PM QoS %s %lu\n",
+		 b == &min_freq_notifier ? "min" : "max", l);
+	for_each_online_cpu(cpu) {
+		struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+		if (policy) {
+			cpufreq_update_policy(policy->cpu);
+			cpufreq_cpu_put(policy);
+		}
+	}
+	return NOTIFY_OK;
+}
+
 static int __init cpufreq_core_init(void)
 {
 	int cpu;
+	int rc;
 
 	for_each_possible_cpu(cpu) {
 		per_cpu(cpufreq_policy_cpu, cpu) = -1;
@@ -1916,6 +1955,12 @@ static int __init cpufreq_core_init(void)
 	cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
 	BUG_ON(!cpufreq_global_kobject);
 	register_syscore_ops(&cpufreq_syscore_ops);
+	rc = pm_qos_add_notifier(PM_QOS_CPU_FREQ_MIN,
+				 &min_freq_notifier);
+	BUG_ON(rc);
+	rc = pm_qos_add_notifier(PM_QOS_CPU_FREQ_MAX,
+				 &max_freq_notifier);
+	BUG_ON(rc);
 
 	return 0;
 }
-- 
1.7.4.1

[PATCH 6/6] input: CPU frequency booster

[Antti P Miettinen]

Inspired by cpufreq ondemand governor changes at
git://codeaurora.org/kernel/msm.git tree in commits:

    2a6181bc76c6ce46ca0fa8e547be42acd534cf0e
    1cca8861d8fda4e05f6b0c59c60003345c15454d
    96a9aeb02bf5b3fbbef47e44460750eb275e9f1b
    b600449501cf15928440f87eff86b1f32d14214e
    88a65c7ae04632ffee11f9fc628d7ab017c06b83

Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
 drivers/input/Kconfig         |    9 ++
 drivers/input/Makefile        |    1 +
 drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 184 insertions(+), 0 deletions(-)
 create mode 100644 drivers/input/input-cfboost.c

diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 001b147..3859f78 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -161,6 +161,15 @@ config INPUT_APMPOWER
 	  To compile this driver as a module, choose M here: the
 	  module will be called apm-power.
 
+config INPUT_CFBOOST
+	tristate "CPU frequency booster"
+	depends on INPUT && CPU_FREQ
+	help
+	  Say Y here if you want to boost frequency upon input events;
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called input-cfboost.
+
 comment "Input Device Drivers"
 
 source "drivers/input/keyboard/Kconfig"
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 0c78949..6cad177 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_INPUT_TOUCHSCREEN)	+= touchscreen/
 obj-$(CONFIG_INPUT_MISC)	+= misc/
 
 obj-$(CONFIG_INPUT_APMPOWER)	+= apm-power.o
+obj-$(CONFIG_INPUT_CFBOOST)	+= input-cfboost.o
diff --git a/drivers/input/input-cfboost.c b/drivers/input/input-cfboost.c
new file mode 100644
index 0000000..bef3ec5
--- /dev/null
+++ b/drivers/input/input-cfboost.c
@@ -0,0 +1,174 @@
+/*
+ * drivers/input/input-cfboost.c
+ *
+ * Copyright (C) 2012 NVIDIA Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ */
+
+#include <linux/slab.h>
+#include <linux/jiffies.h>
+#include <linux/printk.h>
+#include <linux/workqueue.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/pm_qos.h>
+
+/* This module listens to input events and sets a temporary frequency
+ * floor upon input event detection. This is based on changes to
+ * cpufreq ondemand governor by:
+ *
+ * Tero Kristo <tero.kristo@nokia.com>
+ * Brian Steuer <bsteuer@codeaurora.org>
+ * David Ng <dave@codeaurora.org>
+ *
+ * at git://codeaurora.org/kernel/msm.git tree, commits:
+ *
+ * 2a6181bc76c6ce46ca0fa8e547be42acd534cf0e
+ * 1cca8861d8fda4e05f6b0c59c60003345c15454d
+ * 96a9aeb02bf5b3fbbef47e44460750eb275e9f1b
+ * b600449501cf15928440f87eff86b1f32d14214e
+ * 88a65c7ae04632ffee11f9fc628d7ab017c06b83
+ */
+
+MODULE_AUTHOR("Antti P Miettinen <amiettinen@nvidia.com>");
+MODULE_DESCRIPTION("Input event CPU frequency booster");
+MODULE_LICENSE("GPL v2");
+
+
+static struct pm_qos_request qos_req;
+static struct work_struct boost;
+static struct delayed_work unboost;
+static unsigned int boost_freq; /* kHz */
+module_param(boost_freq, uint, 0644);
+static unsigned long boost_time = 500; /* ms */
+module_param(boost_time, ulong, 0644);
+static struct workqueue_struct *cfb_wq;
+
+static void cfb_boost(struct work_struct *w)
+{
+	cancel_delayed_work_sync(&unboost);
+	pm_qos_update_request(&qos_req, boost_freq);
+	queue_delayed_work(cfb_wq, &unboost, msecs_to_jiffies(boost_time));
+}
+
+static void cfb_unboost(struct work_struct *w)
+{
+	pm_qos_update_request(&qos_req, PM_QOS_DEFAULT_VALUE);
+}
+
+static void cfb_input_event(struct input_handle *handle, unsigned int type,
+			    unsigned int code, int value)
+{
+	if (!work_pending(&boost))
+		queue_work(cfb_wq, &boost);
+}
+
+static int cfb_input_connect(struct input_handler *handler,
+			     struct input_dev *dev,
+			     const struct input_device_id *id)
+{
+	struct input_handle *handle;
+	int error;
+
+	handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
+	if (!handle)
+		return -ENOMEM;
+
+	handle->dev = dev;
+	handle->handler = handler;
+	handle->name = "icfboost";
+
+	error = input_register_handle(handle);
+	if (error)
+		goto err2;
+
+	error = input_open_device(handle);
+	if (error)
+		goto err1;
+
+	return 0;
+err1:
+	input_unregister_handle(handle);
+err2:
+	kfree(handle);
+	return error;
+}
+
+static void cfb_input_disconnect(struct input_handle *handle)
+{
+	input_close_device(handle);
+	input_unregister_handle(handle);
+	kfree(handle);
+}
+
+/* XXX make configurable */
+static const struct input_device_id cfb_ids[] = {
+	{ /* touch screen */
+		.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+				INPUT_DEVICE_ID_MATCH_KEYBIT,
+		.evbit = { BIT_MASK(EV_ABS) },
+		.keybit = {[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH) },
+	},
+	{ /* mouse */
+		.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+				INPUT_DEVICE_ID_MATCH_KEYBIT,
+		.evbit = { BIT_MASK(EV_REL) },
+		.keybit = {[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_MOUSE) },
+	},
+	{ },
+};
+
+static struct input_handler cfb_input_handler = {
+	.event		= cfb_input_event,
+	.connect	= cfb_input_connect,
+	.disconnect	= cfb_input_disconnect,
+	.name		= "icfboost",
+	.id_table	= cfb_ids,
+};
+
+static int __init cfboost_init(void)
+{
+	int ret;
+
+	cfb_wq = create_workqueue("icfb-wq");
+	if (!cfb_wq)
+		return -ENOMEM;
+	INIT_WORK(&boost, cfb_boost);
+	INIT_DELAYED_WORK(&unboost, cfb_unboost);
+	ret = input_register_handler(&cfb_input_handler);
+	if (ret) {
+		destroy_workqueue(cfb_wq);
+		return ret;
+	}
+	pm_qos_add_request(&qos_req, PM_QOS_CPU_FREQ_MIN,
+			   PM_QOS_DEFAULT_VALUE);
+	return 0;
+}
+
+static void __exit cfboost_exit(void)
+{
+	/* stop input events */
+	input_unregister_handler(&cfb_input_handler);
+	/* cancel pending work requests */
+	cancel_work_sync(&boost);
+	cancel_delayed_work_sync(&unboost);
+	/* clean up */
+	destroy_workqueue(cfb_wq);
+	pm_qos_remove_request(&qos_req);
+}
+
+module_init(cfboost_init);
+module_exit(cfboost_exit);
-- 
1.7.4.1

Re: [PATCH 4/6] cpufreq: Preserve sysfs min/max request

[Antti P Miettinen]

Any comments to this change?

Antti P Miettinen <amiettinen@nvidia.com> writes:
> Store the value received via sysfs as the user_policy
> min/max value instead of the currently enforced min/max.
> This allows restoring the user min/max values when
> constraints on enforced min/max change.
>
> Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
> ---
>  drivers/cpufreq/cpufreq.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e63b29f..65a512b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -389,7 +389,7 @@ static ssize_t store_##file_name					\
>  		return -EINVAL;						\
>  									\
>  	ret = __cpufreq_set_policy(policy, &new_policy);		\
> -	policy->user_policy.object = policy->object;			\
> +	policy->user_policy.object = new_policy.object;			\
>  									\
>  	return ret ? ret : count;					\
>  }

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Thu, Jan 12, 2012 at 10:43:49AM +0200, Antti P Miettinen wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > On Wednesday, January 11, 2012, Antti P Miettinen wrote:
> >> I think for CPU performance, it's probably simplest just to use
> >> frequency. Mapping from GOPS/MIPS/FLOPS/FPS is probably more sensily
> >> done by PM QoS client side.
> >
> > Well, unfortunately, frequency is kind of system-specific.  I mean,
> > you need to know what frequencies are supported/available to use that,
> > so it would require the potential users to know the CPU internals.
> >
> > Thanks,
> > Rafael
> 
> I would expect clients requesting for computing performance to require
> system specific knowledge anyway. Computing performance is often
> affected by target specific details (CPU, memory, interconnects). So
> something like board specific configuration parameters would probably be
> required for the PM QoS clients doing computing performance requests.
>
Also, one doesn't have to know the exact number to use the throughput
parameter.  If one value was not enough (i.e. you are missing
deadlines) the increase it until things stabilize.

In practice I doubt any of these qos parameter can be portable.  I
once thought of using units of bogomips for cpu throughput but, thats
just as un-portable as frequency.  Things will end up having to be
tuned or use some training algorithm.

--mark

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Thursday, January 12, 2012, Antti P Miettinen wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >> By blocking sleep states we can address "system level latency" or "best case
> >> latency" but as far as I can see PM QoS does not address "worst case
> >> latency".
> >
> > I'm not sure what you mean by "worst case latency".
> 
> Umm.. the usual concept. If latency is the time from stimulus to
> response, this time can vary based on context. One part of the context
> is the hardware state but there is also the system load. So for example
> the time from interrupt to display being updated is affected by hardware
> state but also system load. As far as I understand, current PM QoS
> latency requests addresses hardware state but do not account for
> possible resource contention, e.g. several latency sensitive clients
> (device drivers, tasks) competing for CPU. In this sense minimum CPU
> frequency requests would be similar.

That's correct, we don't take possible contention into account in PM QoS,
because such conditions may happen idependently of power management anyway.

Thanks,
Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Thursday, January 12, 2012, mark gross wrote:
> On Tue, Jan 10, 2012 at 10:02:49PM +0100, Jean Pihet wrote:
> > Hi Mark, Rafael,
> > 
> > On Tue, Jan 10, 2012 at 9:46 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > On Tuesday, January 10, 2012, mark gross wrote:
> > >> On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
> > >> > On Monday, January 09, 2012, mark gross wrote:
> > >> > > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> > >> > > > On Friday, January 06, 2012, mark gross wrote:
> > >> > > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > >> > > > > > The inspiration for this patch series is the N9 CPU frequency boost
> > >> > > > > > upon input events:
> > >> > > > > >
> > >> > > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > >> > > > > >
> > >> > > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > >> > > > > > Those patches modify the ondemand cpufreq governor. This patch series
> > >> > > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > >> > > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > >> > > > > > an example module for boosting the frequency upon input events.
> > >> > > > > >
> > >> > > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > >> > > > > > E6420 with the ACPI cpufreq driver. The patches are against
> > >> > > > > > linux-next/master, compile tested against it.
> > >> > > > > >
> > >> > > > > >     --Antti
> > >> > > > > >
> > >> > > > > > Alex Frid (1):
> > >> > > > > >   PM QoS: Simplify PM QoS expansion/merge
> > >> > > > > >
> > >> > > > > > Antti P Miettinen (5):
> > >> > > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > >> > > > > >   cpufreq: Export user_policy min/max
> > >> > > > > >   cpufreq: Preserve sysfs min/max request
> > >> > > > > >   cpufreq: Enforce PM QoS min/max limits
> > >> > > > > >   input: CPU frequency booster
> > >> > > > > >
> > >> > > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > >> > > > > >  drivers/input/Kconfig         |    9 ++
> > >> > > > > >  drivers/input/Makefile        |    1 +
> > >> > > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > >> > > > > >  include/linux/pm_qos.h        |   19 ++++-
> > >> > > > > >  kernel/power/qos.c            |   55 ++++++++++----
> > >> > > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > >> > > > > >  create mode 100644 drivers/input/input-cfboost.c
> > >> > > > > >
> > >> > > > >
> > >> > > > > The following is my version of part of this patch set I was tinkering
> > >> > > > > with.  Its missing the cpufreq notification this change has and doesn't
> > >> > > > > do anything WRT cfboost.
> > >> > > > >
> > >> > > > > Would it be ok if we could consolidate our two implementations and
> > >> > > > > completely separate the cfboost stuff as a separate patch set?
> > >> > > > >
> > >> > > > > My code below is missing the cpufreq notification logic you have.
> > >> > > >
> > >> > > > Well, I have one substantial problem with this approach.  Namely, our
> > >> > > > current PM QoS infrastructure is not suitable for throughput constraints,
> > >> > > > because they should be additive, unlike the latency ones.
> > >> > > >
> > >> > > > Namely, if sombody requests throughput X and someone else Y, the resulting
> > >> > > > combined throughput should be X+Y rather than max(X, Y).
> > >> > >
> > >> > > That can be done easy enough.  However; in practice I'm not convinced
> > >> > > doing and additive aggregation of the requested QoS would be any better
> > >> > > than just taking the max.
> > >> >
> > >> > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> > >> > general.  If Y is the max, then the subsystem that requested X may easily
> > >> > starve whoever requested the Y by using all of the bandwidth it asked for.
> > >>
> > >> I was thinking about this from the CPU point of view more over the day.
> > >> Given that there are many times more than one make the qos requests
> > >> additive will result in quickly requesting more cpu than is available
> > >> and waisting a lot of power.   Also additive aggregation falls over a
> > >> bit on with multi-core.
> > >>
> > >> As the consumer of the cpu resources are tasks, and we can only run one
> > >> task at a time on a cpu, I'm talking myself into thinking that max
> > >> *is* the right way to go for cpu throughput (i.e. frequency).
> > There are case where the constraints values should be additive. The
> > best example is the main memory throughput and so the memory
> > controller frequency (or the L3 frequency on OMAP). The main problem
> > is to estimate the overhead of multiple simultaneous transfers.
> > 
> > What do you think?
> 
> I think the number of that get summed in you memory bus example needs to
> be tied to the number of DMA engines + CPU cores that can concurrently
> transfer on that bus.  To sum all the request I think is too simplistic
> and will result in always maxing aggregate request

That still seems to be better than simply using the maximum requested
value.

Thanks,
Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Wednesday, January 11, 2012, Antti P Miettinen wrote:
>> I think for CPU performance, it's probably simplest just to use
>> frequency. Mapping from GOPS/MIPS/FLOPS/FPS is probably more sensily
>> done by PM QoS client side.
>
> Well, unfortunately, frequency is kind of system-specific.  I mean,
> you need to know what frequencies are supported/available to use that,
> so it would require the potential users to know the CPU internals.
>
> Thanks,
> Rafael

I would expect clients requesting for computing performance to require
system specific knowledge anyway. Computing performance is often
affected by target specific details (CPU, memory, interconnects). So
something like board specific configuration parameters would probably be
required for the PM QoS clients doing computing performance requests.

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> By blocking sleep states we can address "system level latency" or "best case
>> latency" but as far as I can see PM QoS does not address "worst case
>> latency".
>
> I'm not sure what you mean by "worst case latency".

Umm.. the usual concept. If latency is the time from stimulus to
response, this time can vary based on context. One part of the context
is the hardware state but there is also the system load. So for example
the time from interrupt to display being updated is affected by hardware
state but also system load. As far as I understand, current PM QoS
latency requests addresses hardware state but do not account for
possible resource contention, e.g. several latency sensitive clients
(device drivers, tasks) competing for CPU. In this sense minimum CPU
frequency requests would be similar.

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Tue, Jan 10, 2012 at 10:02:49PM +0100, Jean Pihet wrote:
> Hi Mark, Rafael,
> 
> On Tue, Jan 10, 2012 at 9:46 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, January 10, 2012, mark gross wrote:
> >> On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
> >> > On Monday, January 09, 2012, mark gross wrote:
> >> > > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> >> > > > On Friday, January 06, 2012, mark gross wrote:
> >> > > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> >> > > > > > The inspiration for this patch series is the N9 CPU frequency boost
> >> > > > > > upon input events:
> >> > > > > >
> >> > > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> >> > > > > >
> >> > > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> >> > > > > > Those patches modify the ondemand cpufreq governor. This patch series
> >> > > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> >> > > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> >> > > > > > an example module for boosting the frequency upon input events.
> >> > > > > >
> >> > > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> >> > > > > > E6420 with the ACPI cpufreq driver. The patches are against
> >> > > > > > linux-next/master, compile tested against it.
> >> > > > > >
> >> > > > > >     --Antti
> >> > > > > >
> >> > > > > > Alex Frid (1):
> >> > > > > >   PM QoS: Simplify PM QoS expansion/merge
> >> > > > > >
> >> > > > > > Antti P Miettinen (5):
> >> > > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> >> > > > > >   cpufreq: Export user_policy min/max
> >> > > > > >   cpufreq: Preserve sysfs min/max request
> >> > > > > >   cpufreq: Enforce PM QoS min/max limits
> >> > > > > >   input: CPU frequency booster
> >> > > > > >
> >> > > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> >> > > > > >  drivers/input/Kconfig         |    9 ++
> >> > > > > >  drivers/input/Makefile        |    1 +
> >> > > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> >> > > > > >  include/linux/pm_qos.h        |   19 ++++-
> >> > > > > >  kernel/power/qos.c            |   55 ++++++++++----
> >> > > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> >> > > > > >  create mode 100644 drivers/input/input-cfboost.c
> >> > > > > >
> >> > > > >
> >> > > > > The following is my version of part of this patch set I was tinkering
> >> > > > > with.  Its missing the cpufreq notification this change has and doesn't
> >> > > > > do anything WRT cfboost.
> >> > > > >
> >> > > > > Would it be ok if we could consolidate our two implementations and
> >> > > > > completely separate the cfboost stuff as a separate patch set?
> >> > > > >
> >> > > > > My code below is missing the cpufreq notification logic you have.
> >> > > >
> >> > > > Well, I have one substantial problem with this approach.  Namely, our
> >> > > > current PM QoS infrastructure is not suitable for throughput constraints,
> >> > > > because they should be additive, unlike the latency ones.
> >> > > >
> >> > > > Namely, if sombody requests throughput X and someone else Y, the resulting
> >> > > > combined throughput should be X+Y rather than max(X, Y).
> >> > >
> >> > > That can be done easy enough.  However; in practice I'm not convinced
> >> > > doing and additive aggregation of the requested QoS would be any better
> >> > > than just taking the max.
> >> >
> >> > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> >> > general.  If Y is the max, then the subsystem that requested X may easily
> >> > starve whoever requested the Y by using all of the bandwidth it asked for.
> >>
> >> I was thinking about this from the CPU point of view more over the day.
> >> Given that there are many times more than one make the qos requests
> >> additive will result in quickly requesting more cpu than is available
> >> and waisting a lot of power.   Also additive aggregation falls over a
> >> bit on with multi-core.
> >>
> >> As the consumer of the cpu resources are tasks, and we can only run one
> >> task at a time on a cpu, I'm talking myself into thinking that max
> >> *is* the right way to go for cpu throughput (i.e. frequency).
> There are case where the constraints values should be additive. The
> best example is the main memory throughput and so the memory
> controller frequency (or the L3 frequency on OMAP). The main problem
> is to estimate the overhead of multiple simultaneous transfers.
> 
> What do you think?

I think the number of that get summed in you memory bus example needs to
be tied to the number of DMA engines + CPU cores that can concurrently
transfer on that bus.  To sum all the request I think is too simplistic
and will result in always maxing aggregate request


--mark

> 
> >
> > I agree, but I wonder what units of throughput should be used in that case?
> >
> > Rafael
> 
> Regards,
> Jean
> 
> > _______________________________________________
> > linux-pm mailing list
> > linux-pm@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Tue, Jan 10, 2012 at 09:46:22PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 10, 2012, mark gross wrote:
> > On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 09, 2012, mark gross wrote:
> > > > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> > > > > On Friday, January 06, 2012, mark gross wrote:
> > > > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > > > > > > The inspiration for this patch series is the N9 CPU frequency boost
> > > > > > > upon input events:
> > > > > > > 
> > > > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > > > > > 
> > > > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > > > > > Those patches modify the ondemand cpufreq governor. This patch series
> > > > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > > > > > > an example module for boosting the frequency upon input events.
> > > > > > > 
> > > > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > > > > > > E6420 with the ACPI cpufreq driver. The patches are against
> > > > > > > linux-next/master, compile tested against it.
> > > > > > > 
> > > > > > > 	--Antti
> > > > > > > 
> > > > > > > Alex Frid (1):
> > > > > > >   PM QoS: Simplify PM QoS expansion/merge
> > > > > > > 
> > > > > > > Antti P Miettinen (5):
> > > > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > > > > > >   cpufreq: Export user_policy min/max
> > > > > > >   cpufreq: Preserve sysfs min/max request
> > > > > > >   cpufreq: Enforce PM QoS min/max limits
> > > > > > >   input: CPU frequency booster
> > > > > > > 
> > > > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > > > > > >  drivers/input/Kconfig         |    9 ++
> > > > > > >  drivers/input/Makefile        |    1 +
> > > > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > > > > > >  include/linux/pm_qos.h        |   19 ++++-
> > > > > > >  kernel/power/qos.c            |   55 ++++++++++----
> > > > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > > > > > >  create mode 100644 drivers/input/input-cfboost.c
> > > > > > > 
> > > > > > 
> > > > > > The following is my version of part of this patch set I was tinkering
> > > > > > with.  Its missing the cpufreq notification this change has and doesn't
> > > > > > do anything WRT cfboost.
> > > > > > 
> > > > > > Would it be ok if we could consolidate our two implementations and
> > > > > > completely separate the cfboost stuff as a separate patch set?
> > > > > > 
> > > > > > My code below is missing the cpufreq notification logic you have.
> > > > > 
> > > > > Well, I have one substantial problem with this approach.  Namely, our
> > > > > current PM QoS infrastructure is not suitable for throughput constraints,
> > > > > because they should be additive, unlike the latency ones.
> > > > > 
> > > > > Namely, if sombody requests throughput X and someone else Y, the resulting
> > > > > combined throughput should be X+Y rather than max(X, Y).
> > > > 
> > > > That can be done easy enough.  However; in practice I'm not convinced
> > > > doing and additive aggregation of the requested QoS would be any better
> > > > than just taking the max.
> > > 
> > > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> > > general.  If Y is the max, then the subsystem that requested X may easily
> > > starve whoever requested the Y by using all of the bandwidth it asked for.
> > 
> > I was thinking about this from the CPU point of view more over the day.
> > Given that there are many times more than one make the qos requests
> > additive will result in quickly requesting more cpu than is available
> > and waisting a lot of power.   Also additive aggregation falls over a
> > bit on with multi-core. 
> > 
> > As the consumer of the cpu resources are tasks, and we can only run one
> > task at a time on a cpu, I'm talking myself into thinking that max
> > *is* the right way to go for cpu throughput (i.e. frequency).
> 
> I agree, but I wonder what units of throughput should be used in that case?

I was thinking of using the same units that cpufreq works in. 

--mark

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Wednesday, January 11, 2012, Antti P Miettinen wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > On Monday, January 09, 2012, Antti P Miettinen wrote:
> >> Hmm.. congestion is an issue for latency requests as well.
> >
> > I'm not sure what you mean.  Care to elaborate?
> >
> > Rafael
> 
> Well, I was just thinking that latencies can get hurt by system load
> just like throughput can suffer from load.

The idea with latencies is different.  Latency constraints specify how
much time a given resource may be unavailable (due to power management).
So, when putting the resource into a low-power state we only need to
consider the minimum of those.

> By blocking sleep states we can address "system level latency" or "best case
> latency" but as far as I can see PM QoS does not address "worst case
> latency".

I'm not sure what you mean by "worst case latency".

Thanks,
Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Wednesday, January 11, 2012, Antti P Miettinen wrote:
> Jean Pihet <jean.pihet@newoldbits.com> writes:
> > There are case where the constraints values should be additive. The
> > best example is the main memory throughput and so the memory
> > controller frequency (or the L3 frequency on OMAP). The main problem
> > is to estimate the overhead of multiple simultaneous transfers.
> >
> > What do you think?
> 
> This is a valid point. What tree/branch should I look at for the OMAP L3
> PM QoS?
> 
> I think for CPU performance, it's probably simplest just to use
> frequency. Mapping from GOPS/MIPS/FLOPS/FPS is probably more sensily
> done by PM QoS client side.

Well, unfortunately, frequency is kind of system-specific.  I mean,
you need to know what frequencies are supported/available to use that,
so it would require the potential users to know the CPU internals.

Thanks,
Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

Jean Pihet <jean.pihet@newoldbits.com> writes:
> There are case where the constraints values should be additive. The
> best example is the main memory throughput and so the memory
> controller frequency (or the L3 frequency on OMAP). The main problem
> is to estimate the overhead of multiple simultaneous transfers.
>
> What do you think?

This is a valid point. What tree/branch should I look at for the OMAP L3
PM QoS?

I think for CPU performance, it's probably simplest just to use
frequency. Mapping from GOPS/MIPS/FLOPS/FPS is probably more sensily
done by PM QoS client side.

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Monday, January 09, 2012, Antti P Miettinen wrote:
>> Hmm.. congestion is an issue for latency requests as well.
>
> I'm not sure what you mean.  Care to elaborate?
>
> Rafael

Well, I was just thinking that latencies can get hurt by system load
just like throughput can suffer from load. By blocking sleep states we
can address "system level latency" or "best case latency" but as far as
I can see PM QoS does not address "worst case latency". So minimum CPU
frequency would be somewhat analogous - a "best case" or "system level"
QoS concept.

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Jean Pihet]

Hi Mark, Rafael,

On Tue, Jan 10, 2012 at 9:46 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, January 10, 2012, mark gross wrote:
>> On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
>> > On Monday, January 09, 2012, mark gross wrote:
>> > > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
>> > > > On Friday, January 06, 2012, mark gross wrote:
>> > > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
>> > > > > > The inspiration for this patch series is the N9 CPU frequency boost
>> > > > > > upon input events:
>> > > > > >
>> > > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
>> > > > > >
>> > > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
>> > > > > > Those patches modify the ondemand cpufreq governor. This patch series
>> > > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
>> > > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
>> > > > > > an example module for boosting the frequency upon input events.
>> > > > > >
>> > > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
>> > > > > > E6420 with the ACPI cpufreq driver. The patches are against
>> > > > > > linux-next/master, compile tested against it.
>> > > > > >
>> > > > > >     --Antti
>> > > > > >
>> > > > > > Alex Frid (1):
>> > > > > >   PM QoS: Simplify PM QoS expansion/merge
>> > > > > >
>> > > > > > Antti P Miettinen (5):
>> > > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
>> > > > > >   cpufreq: Export user_policy min/max
>> > > > > >   cpufreq: Preserve sysfs min/max request
>> > > > > >   cpufreq: Enforce PM QoS min/max limits
>> > > > > >   input: CPU frequency booster
>> > > > > >
>> > > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
>> > > > > >  drivers/input/Kconfig         |    9 ++
>> > > > > >  drivers/input/Makefile        |    1 +
>> > > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
>> > > > > >  include/linux/pm_qos.h        |   19 ++++-
>> > > > > >  kernel/power/qos.c            |   55 ++++++++++----
>> > > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
>> > > > > >  create mode 100644 drivers/input/input-cfboost.c
>> > > > > >
>> > > > >
>> > > > > The following is my version of part of this patch set I was tinkering
>> > > > > with.  Its missing the cpufreq notification this change has and doesn't
>> > > > > do anything WRT cfboost.
>> > > > >
>> > > > > Would it be ok if we could consolidate our two implementations and
>> > > > > completely separate the cfboost stuff as a separate patch set?
>> > > > >
>> > > > > My code below is missing the cpufreq notification logic you have.
>> > > >
>> > > > Well, I have one substantial problem with this approach.  Namely, our
>> > > > current PM QoS infrastructure is not suitable for throughput constraints,
>> > > > because they should be additive, unlike the latency ones.
>> > > >
>> > > > Namely, if sombody requests throughput X and someone else Y, the resulting
>> > > > combined throughput should be X+Y rather than max(X, Y).
>> > >
>> > > That can be done easy enough.  However; in practice I'm not convinced
>> > > doing and additive aggregation of the requested QoS would be any better
>> > > than just taking the max.
>> >
>> > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
>> > general.  If Y is the max, then the subsystem that requested X may easily
>> > starve whoever requested the Y by using all of the bandwidth it asked for.
>>
>> I was thinking about this from the CPU point of view more over the day.
>> Given that there are many times more than one make the qos requests
>> additive will result in quickly requesting more cpu than is available
>> and waisting a lot of power.   Also additive aggregation falls over a
>> bit on with multi-core.
>>
>> As the consumer of the cpu resources are tasks, and we can only run one
>> task at a time on a cpu, I'm talking myself into thinking that max
>> *is* the right way to go for cpu throughput (i.e. frequency).
There are case where the constraints values should be additive. The
best example is the main memory throughput and so the memory
controller frequency (or the L3 frequency on OMAP). The main problem
is to estimate the overhead of multiple simultaneous transfers.

What do you think?

>
> I agree, but I wonder what units of throughput should be used in that case?
>
> Rafael

Regards,
Jean

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

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Tuesday, January 10, 2012, mark gross wrote:
> On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 09, 2012, mark gross wrote:
> > > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> > > > On Friday, January 06, 2012, mark gross wrote:
> > > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > > > > > The inspiration for this patch series is the N9 CPU frequency boost
> > > > > > upon input events:
> > > > > > 
> > > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > > > > 
> > > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > > > > Those patches modify the ondemand cpufreq governor. This patch series
> > > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > > > > > an example module for boosting the frequency upon input events.
> > > > > > 
> > > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > > > > > E6420 with the ACPI cpufreq driver. The patches are against
> > > > > > linux-next/master, compile tested against it.
> > > > > > 
> > > > > > 	--Antti
> > > > > > 
> > > > > > Alex Frid (1):
> > > > > >   PM QoS: Simplify PM QoS expansion/merge
> > > > > > 
> > > > > > Antti P Miettinen (5):
> > > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > > > > >   cpufreq: Export user_policy min/max
> > > > > >   cpufreq: Preserve sysfs min/max request
> > > > > >   cpufreq: Enforce PM QoS min/max limits
> > > > > >   input: CPU frequency booster
> > > > > > 
> > > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > > > > >  drivers/input/Kconfig         |    9 ++
> > > > > >  drivers/input/Makefile        |    1 +
> > > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > > > > >  include/linux/pm_qos.h        |   19 ++++-
> > > > > >  kernel/power/qos.c            |   55 ++++++++++----
> > > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > > > > >  create mode 100644 drivers/input/input-cfboost.c
> > > > > > 
> > > > > 
> > > > > The following is my version of part of this patch set I was tinkering
> > > > > with.  Its missing the cpufreq notification this change has and doesn't
> > > > > do anything WRT cfboost.
> > > > > 
> > > > > Would it be ok if we could consolidate our two implementations and
> > > > > completely separate the cfboost stuff as a separate patch set?
> > > > > 
> > > > > My code below is missing the cpufreq notification logic you have.
> > > > 
> > > > Well, I have one substantial problem with this approach.  Namely, our
> > > > current PM QoS infrastructure is not suitable for throughput constraints,
> > > > because they should be additive, unlike the latency ones.
> > > > 
> > > > Namely, if sombody requests throughput X and someone else Y, the resulting
> > > > combined throughput should be X+Y rather than max(X, Y).
> > > 
> > > That can be done easy enough.  However; in practice I'm not convinced
> > > doing and additive aggregation of the requested QoS would be any better
> > > than just taking the max.
> > 
> > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> > general.  If Y is the max, then the subsystem that requested X may easily
> > starve whoever requested the Y by using all of the bandwidth it asked for.
> 
> I was thinking about this from the CPU point of view more over the day.
> Given that there are many times more than one make the qos requests
> additive will result in quickly requesting more cpu than is available
> and waisting a lot of power.   Also additive aggregation falls over a
> bit on with multi-core. 
> 
> As the consumer of the cpu resources are tasks, and we can only run one
> task at a time on a cpu, I'm talking myself into thinking that max
> *is* the right way to go for cpu throughput (i.e. frequency).

I agree, but I wonder what units of throughput should be used in that case?

Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Monday, January 09, 2012, Antti P Miettinen wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> > Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> > general.  If Y is the max, then the subsystem that requested X may easily
> > starve whoever requested the Y by using all of the bandwidth it asked for.
> 
> Hmm.. congestion is an issue for latency requests as well.

I'm not sure what you mean.  Care to elaborate?

Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Mon, Jan 09, 2012 at 10:27:29PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 09, 2012, mark gross wrote:
> > On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> > > On Friday, January 06, 2012, mark gross wrote:
> > > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > > > > The inspiration for this patch series is the N9 CPU frequency boost
> > > > > upon input events:
> > > > > 
> > > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > > > 
> > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > > > Those patches modify the ondemand cpufreq governor. This patch series
> > > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > > > > an example module for boosting the frequency upon input events.
> > > > > 
> > > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > > > > E6420 with the ACPI cpufreq driver. The patches are against
> > > > > linux-next/master, compile tested against it.
> > > > > 
> > > > > 	--Antti
> > > > > 
> > > > > Alex Frid (1):
> > > > >   PM QoS: Simplify PM QoS expansion/merge
> > > > > 
> > > > > Antti P Miettinen (5):
> > > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > > > >   cpufreq: Export user_policy min/max
> > > > >   cpufreq: Preserve sysfs min/max request
> > > > >   cpufreq: Enforce PM QoS min/max limits
> > > > >   input: CPU frequency booster
> > > > > 
> > > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > > > >  drivers/input/Kconfig         |    9 ++
> > > > >  drivers/input/Makefile        |    1 +
> > > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > > > >  include/linux/pm_qos.h        |   19 ++++-
> > > > >  kernel/power/qos.c            |   55 ++++++++++----
> > > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > > > >  create mode 100644 drivers/input/input-cfboost.c
> > > > > 
> > > > 
> > > > The following is my version of part of this patch set I was tinkering
> > > > with.  Its missing the cpufreq notification this change has and doesn't
> > > > do anything WRT cfboost.
> > > > 
> > > > Would it be ok if we could consolidate our two implementations and
> > > > completely separate the cfboost stuff as a separate patch set?
> > > > 
> > > > My code below is missing the cpufreq notification logic you have.
> > > 
> > > Well, I have one substantial problem with this approach.  Namely, our
> > > current PM QoS infrastructure is not suitable for throughput constraints,
> > > because they should be additive, unlike the latency ones.
> > > 
> > > Namely, if sombody requests throughput X and someone else Y, the resulting
> > > combined throughput should be X+Y rather than max(X, Y).
> > 
> > That can be done easy enough.  However; in practice I'm not convinced
> > doing and additive aggregation of the requested QoS would be any better
> > than just taking the max.
> 
> Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> general.  If Y is the max, then the subsystem that requested X may easily
> starve whoever requested the Y by using all of the bandwidth it asked for.

I was thinking about this from the CPU point of view more over the day.
Given that there are many times more than one make the qos requests
additive will result in quickly requesting more cpu than is available
and waisting a lot of power.   Also additive aggregation falls over a
bit on with multi-core. 

As the consumer of the cpu resources are tasks, and we can only run one
task at a time on a cpu, I'm talking myself into thinking that max
*is* the right way to go for cpu throughput (i.e. frequency).

Other resources (network?) could benefit from additive aggregation of
qos requests if they are resources that are concurrently shared with
multiple tasks.

--mark

> > But, we can give it a try.
> 
> Good. :-)
> 
> Thanks,
> Rafael
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
> general.  If Y is the max, then the subsystem that requested X may easily
> starve whoever requested the Y by using all of the bandwidth it asked for.

Hmm.. congestion is an issue for latency requests as well. I've viewed
the current PM QoS handling system level requests. If we want some kind
of resource reservation/provisioning that could probably be layered on
top of system level requests, no?

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Monday, January 09, 2012, mark gross wrote:
> On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> > On Friday, January 06, 2012, mark gross wrote:
> > > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > > > The inspiration for this patch series is the N9 CPU frequency boost
> > > > upon input events:
> > > > 
> > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > > 
> > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > > Those patches modify the ondemand cpufreq governor. This patch series
> > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > > > an example module for boosting the frequency upon input events.
> > > > 
> > > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > > > E6420 with the ACPI cpufreq driver. The patches are against
> > > > linux-next/master, compile tested against it.
> > > > 
> > > > 	--Antti
> > > > 
> > > > Alex Frid (1):
> > > >   PM QoS: Simplify PM QoS expansion/merge
> > > > 
> > > > Antti P Miettinen (5):
> > > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > > >   cpufreq: Export user_policy min/max
> > > >   cpufreq: Preserve sysfs min/max request
> > > >   cpufreq: Enforce PM QoS min/max limits
> > > >   input: CPU frequency booster
> > > > 
> > > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > > >  drivers/input/Kconfig         |    9 ++
> > > >  drivers/input/Makefile        |    1 +
> > > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > > >  include/linux/pm_qos.h        |   19 ++++-
> > > >  kernel/power/qos.c            |   55 ++++++++++----
> > > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > > >  create mode 100644 drivers/input/input-cfboost.c
> > > > 
> > > 
> > > The following is my version of part of this patch set I was tinkering
> > > with.  Its missing the cpufreq notification this change has and doesn't
> > > do anything WRT cfboost.
> > > 
> > > Would it be ok if we could consolidate our two implementations and
> > > completely separate the cfboost stuff as a separate patch set?
> > > 
> > > My code below is missing the cpufreq notification logic you have.
> > 
> > Well, I have one substantial problem with this approach.  Namely, our
> > current PM QoS infrastructure is not suitable for throughput constraints,
> > because they should be additive, unlike the latency ones.
> > 
> > Namely, if sombody requests throughput X and someone else Y, the resulting
> > combined throughput should be X+Y rather than max(X, Y).
> 
> That can be done easy enough.  However; in practice I'm not convinced
> doing and additive aggregation of the requested QoS would be any better
> than just taking the max.

Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
general.  If Y is the max, then the subsystem that requested X may easily
starve whoever requested the Y by using all of the bandwidth it asked for.

> But, we can give it a try.

Good. :-)

Thanks,
Rafael

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:
> On Friday, January 06, 2012, mark gross wrote:
> > On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > > The inspiration for this patch series is the N9 CPU frequency boost
> > > upon input events:
> > > 
> > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > 
> > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > Those patches modify the ondemand cpufreq governor. This patch series
> > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > > an example module for boosting the frequency upon input events.
> > > 
> > > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > > E6420 with the ACPI cpufreq driver. The patches are against
> > > linux-next/master, compile tested against it.
> > > 
> > > 	--Antti
> > > 
> > > Alex Frid (1):
> > >   PM QoS: Simplify PM QoS expansion/merge
> > > 
> > > Antti P Miettinen (5):
> > >   PM QoS: Add CPU frequency min/max as PM QoS params
> > >   cpufreq: Export user_policy min/max
> > >   cpufreq: Preserve sysfs min/max request
> > >   cpufreq: Enforce PM QoS min/max limits
> > >   input: CPU frequency booster
> > > 
> > >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> > >  drivers/input/Kconfig         |    9 ++
> > >  drivers/input/Makefile        |    1 +
> > >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/pm_qos.h        |   19 ++++-
> > >  kernel/power/qos.c            |   55 ++++++++++----
> > >  6 files changed, 293 insertions(+), 22 deletions(-)
> > >  create mode 100644 drivers/input/input-cfboost.c
> > > 
> > 
> > The following is my version of part of this patch set I was tinkering
> > with.  Its missing the cpufreq notification this change has and doesn't
> > do anything WRT cfboost.
> > 
> > Would it be ok if we could consolidate our two implementations and
> > completely separate the cfboost stuff as a separate patch set?
> > 
> > My code below is missing the cpufreq notification logic you have.
> 
> Well, I have one substantial problem with this approach.  Namely, our
> current PM QoS infrastructure is not suitable for throughput constraints,
> because they should be additive, unlike the latency ones.
> 
> Namely, if sombody requests throughput X and someone else Y, the resulting
> combined throughput should be X+Y rather than max(X, Y).

That can be done easy enough.  However; in practice I'm not convinced
doing and additive aggregation of the requested QoS would be any better
than just taking the max.  But, we can give it a try.

--mark

> Thanks,
> Rafael
> 
> 
> > >From b4be99354c5af20cbd4041cddd6038e2353e06b4 Mon Sep 17 00:00:00 2001
> > >From: mgross <mgross@mini>
> > >Date: Sat, 24 Dec 2011 13:40:03 -0800
> > >Subject: [PATCH] Some devices have a subtle relationship with the CPU
> >  throughput and need to set a minimum cpu frequency en order
> >  for the device to not experience performance issues with
> >  buffer under runs because the cpu was throttled too much to
> >  be able to keep the buffers full enough.
> > 
> > One graphics benchmark has shown this issue on Intel SOC devices.  The
> > graphics part ends up waiting on the cpu to fill the open GL instruction
> > queue between frames and thus graphic performance suffers because of the
> > cpu throttling because the CPU really isn't very busy while running the
> > benchmark.
> > ---
> >  drivers/cpufreq/cpufreq.c |    8 ++++++++
> >  include/linux/pm_qos.h    |    8 +++++---
> >  kernel/power/qos.c        |   19 +++++++++++++++++++
> >  3 files changed, 32 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 987a165..4cbd58b 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -29,6 +29,7 @@
> >  #include <linux/completion.h>
> >  #include <linux/mutex.h>
> >  #include <linux/syscore_ops.h>
> > +#include <linux/pm_qos.h>
> >  
> >  #include <trace/events/power.h>
> >  
> > @@ -1629,6 +1630,9 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
> >  
> >  	pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
> >  		policy->min, policy->max);
> > +	
> > +	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> > +		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
> >  
> >  	memcpy(&policy->cpuinfo, &data->cpuinfo,
> >  				sizeof(struct cpufreq_cpuinfo));
> > @@ -1736,6 +1740,10 @@ int cpufreq_update_policy(unsigned int cpu)
> >  	policy.policy = data->user_policy.policy;
> >  	policy.governor = data->user_policy.governor;
> >  
> > +	if (policy.min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> > +		policy.min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
> > +
> > +
> >  	/* BIOS might change freq behind our back
> >  	  -> ask driver for current freq and notify governors about a change */
> >  	if (cpufreq_driver->get) {
> > diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> > index 83b0ea3..ead081c 100644
> > --- a/include/linux/pm_qos.h
> > +++ b/include/linux/pm_qos.h
> > @@ -11,13 +11,15 @@
> >  
> >  #define PM_QOS_RESERVED 0
> >  #define PM_QOS_CPU_DMA_LATENCY 1
> > -#define PM_QOS_NETWORK_LATENCY 2
> > -#define PM_QOS_NETWORK_THROUGHPUT 3
> > +#define PM_QOS_CPU_THROUGHPUT 2
> > +#define PM_QOS_NETWORK_LATENCY 3
> > +#define PM_QOS_NETWORK_THROUGHPUT 4
> >  
> > -#define PM_QOS_NUM_CLASSES 4
> > +#define PM_QOS_NUM_CLASSES 5
> >  #define PM_QOS_DEFAULT_VALUE -1
> >  
> >  #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
> > +#define PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE	0
> >  #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
> >  #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
> >  #define PM_QOS_DEV_LAT_DEFAULT_VALUE		0
> > diff --git a/kernel/power/qos.c b/kernel/power/qos.c
> > index 995e3bd..92951fa 100644
> > --- a/kernel/power/qos.c
> > +++ b/kernel/power/qos.c
> > @@ -60,6 +60,19 @@ static DEFINE_SPINLOCK(pm_qos_lock);
> >  
> >  static struct pm_qos_object null_pm_qos;
> >  
> > +static BLOCKING_NOTIFIER_HEAD(cpu_throughput_notifier);
> > +static struct pm_qos_constraints cpu_throughput_constraints = {
> > +	.list = PLIST_HEAD_INIT(cpu_throughput_constraints.list),
> > +	.target_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
> > +	.default_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
> > +	.type = PM_QOS_MIN,
> > +	.notifiers = &cpu_throughput_notifier,
> > +};
> > +static struct pm_qos_object cpu_throughput_pm_qos = {
> > +	.constraints = &cpu_throughput_constraints,
> > +	.name = "cpu_throughput",
> > +};
> > +
> >  static BLOCKING_NOTIFIER_HEAD(cpu_dma_lat_notifier);
> >  static struct pm_qos_constraints cpu_dma_constraints = {
> >  	.list = PLIST_HEAD_INIT(cpu_dma_constraints.list),
> > @@ -104,6 +117,7 @@ static struct pm_qos_object network_throughput_pm_qos = {
> >  static struct pm_qos_object *pm_qos_array[] = {
> >  	&null_pm_qos,
> >  	&cpu_dma_pm_qos,
> > +	&cpu_throughput_pm_qos,
> >  	&network_lat_pm_qos,
> >  	&network_throughput_pm_qos
> >  };
> > @@ -475,6 +489,11 @@ static int __init pm_qos_power_init(void)
> >  		printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
> >  		return ret;
> >  	}
> > +	ret = register_pm_qos_misc(&cpu_throughput_pm_qos);
> > +	if (ret < 0) {
> > +		printk(KERN_ERR "pm_qos_param: cpu_throughput setup failed\n");
> > +		return ret;
> > +	}
> >  	ret = register_pm_qos_misc(&network_lat_pm_qos);
> >  	if (ret < 0) {
> >  		printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
> > 
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Rafael J. Wysocki]

On Friday, January 06, 2012, mark gross wrote:
> On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> > The inspiration for this patch series is the N9 CPU frequency boost
> > upon input events:
> > 
> > http://www.spinics.net/lists/cpufreq/msg00667.html
> > 
> > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > Those patches modify the ondemand cpufreq governor. This patch series
> > adds minimum and maximum CPU frequency as PM QoS parameters and
> > modifies the cpufreq core to enforce the PM QoS limits. There is also
> > an example module for boosting the frequency upon input events.
> > 
> > I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> > E6420 with the ACPI cpufreq driver. The patches are against
> > linux-next/master, compile tested against it.
> > 
> > 	--Antti
> > 
> > Alex Frid (1):
> >   PM QoS: Simplify PM QoS expansion/merge
> > 
> > Antti P Miettinen (5):
> >   PM QoS: Add CPU frequency min/max as PM QoS params
> >   cpufreq: Export user_policy min/max
> >   cpufreq: Preserve sysfs min/max request
> >   cpufreq: Enforce PM QoS min/max limits
> >   input: CPU frequency booster
> > 
> >  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
> >  drivers/input/Kconfig         |    9 ++
> >  drivers/input/Makefile        |    1 +
> >  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
> >  include/linux/pm_qos.h        |   19 ++++-
> >  kernel/power/qos.c            |   55 ++++++++++----
> >  6 files changed, 293 insertions(+), 22 deletions(-)
> >  create mode 100644 drivers/input/input-cfboost.c
> > 
> 
> The following is my version of part of this patch set I was tinkering
> with.  Its missing the cpufreq notification this change has and doesn't
> do anything WRT cfboost.
> 
> Would it be ok if we could consolidate our two implementations and
> completely separate the cfboost stuff as a separate patch set?
> 
> My code below is missing the cpufreq notification logic you have.

Well, I have one substantial problem with this approach.  Namely, our
current PM QoS infrastructure is not suitable for throughput constraints,
because they should be additive, unlike the latency ones.

Namely, if sombody requests throughput X and someone else Y, the resulting
combined throughput should be X+Y rather than max(X, Y).

Thanks,
Rafael


> >From b4be99354c5af20cbd4041cddd6038e2353e06b4 Mon Sep 17 00:00:00 2001
> >From: mgross <mgross@mini>
> >Date: Sat, 24 Dec 2011 13:40:03 -0800
> >Subject: [PATCH] Some devices have a subtle relationship with the CPU
>  throughput and need to set a minimum cpu frequency en order
>  for the device to not experience performance issues with
>  buffer under runs because the cpu was throttled too much to
>  be able to keep the buffers full enough.
> 
> One graphics benchmark has shown this issue on Intel SOC devices.  The
> graphics part ends up waiting on the cpu to fill the open GL instruction
> queue between frames and thus graphic performance suffers because of the
> cpu throttling because the CPU really isn't very busy while running the
> benchmark.
> ---
>  drivers/cpufreq/cpufreq.c |    8 ++++++++
>  include/linux/pm_qos.h    |    8 +++++---
>  kernel/power/qos.c        |   19 +++++++++++++++++++
>  3 files changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 987a165..4cbd58b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -29,6 +29,7 @@
>  #include <linux/completion.h>
>  #include <linux/mutex.h>
>  #include <linux/syscore_ops.h>
> +#include <linux/pm_qos.h>
>  
>  #include <trace/events/power.h>
>  
> @@ -1629,6 +1630,9 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
>  
>  	pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
>  		policy->min, policy->max);
> +	
> +	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> +		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
>  
>  	memcpy(&policy->cpuinfo, &data->cpuinfo,
>  				sizeof(struct cpufreq_cpuinfo));
> @@ -1736,6 +1740,10 @@ int cpufreq_update_policy(unsigned int cpu)
>  	policy.policy = data->user_policy.policy;
>  	policy.governor = data->user_policy.governor;
>  
> +	if (policy.min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> +		policy.min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
> +
> +
>  	/* BIOS might change freq behind our back
>  	  -> ask driver for current freq and notify governors about a change */
>  	if (cpufreq_driver->get) {
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 83b0ea3..ead081c 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -11,13 +11,15 @@
>  
>  #define PM_QOS_RESERVED 0
>  #define PM_QOS_CPU_DMA_LATENCY 1
> -#define PM_QOS_NETWORK_LATENCY 2
> -#define PM_QOS_NETWORK_THROUGHPUT 3
> +#define PM_QOS_CPU_THROUGHPUT 2
> +#define PM_QOS_NETWORK_LATENCY 3
> +#define PM_QOS_NETWORK_THROUGHPUT 4
>  
> -#define PM_QOS_NUM_CLASSES 4
> +#define PM_QOS_NUM_CLASSES 5
>  #define PM_QOS_DEFAULT_VALUE -1
>  
>  #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
> +#define PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE	0
>  #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
>  #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
>  #define PM_QOS_DEV_LAT_DEFAULT_VALUE		0
> diff --git a/kernel/power/qos.c b/kernel/power/qos.c
> index 995e3bd..92951fa 100644
> --- a/kernel/power/qos.c
> +++ b/kernel/power/qos.c
> @@ -60,6 +60,19 @@ static DEFINE_SPINLOCK(pm_qos_lock);
>  
>  static struct pm_qos_object null_pm_qos;
>  
> +static BLOCKING_NOTIFIER_HEAD(cpu_throughput_notifier);
> +static struct pm_qos_constraints cpu_throughput_constraints = {
> +	.list = PLIST_HEAD_INIT(cpu_throughput_constraints.list),
> +	.target_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
> +	.default_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
> +	.type = PM_QOS_MIN,
> +	.notifiers = &cpu_throughput_notifier,
> +};
> +static struct pm_qos_object cpu_throughput_pm_qos = {
> +	.constraints = &cpu_throughput_constraints,
> +	.name = "cpu_throughput",
> +};
> +
>  static BLOCKING_NOTIFIER_HEAD(cpu_dma_lat_notifier);
>  static struct pm_qos_constraints cpu_dma_constraints = {
>  	.list = PLIST_HEAD_INIT(cpu_dma_constraints.list),
> @@ -104,6 +117,7 @@ static struct pm_qos_object network_throughput_pm_qos = {
>  static struct pm_qos_object *pm_qos_array[] = {
>  	&null_pm_qos,
>  	&cpu_dma_pm_qos,
> +	&cpu_throughput_pm_qos,
>  	&network_lat_pm_qos,
>  	&network_throughput_pm_qos
>  };
> @@ -475,6 +489,11 @@ static int __init pm_qos_power_init(void)
>  		printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
>  		return ret;
>  	}
> +	ret = register_pm_qos_misc(&cpu_throughput_pm_qos);
> +	if (ret < 0) {
> +		printk(KERN_ERR "pm_qos_param: cpu_throughput setup failed\n");
> +		return ret;
> +	}
>  	ret = register_pm_qos_misc(&network_lat_pm_qos);
>  	if (ret < 0) {
>  		printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
> 

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Fri, Jan 06, 2012 at 09:38:39PM +0200, Antti P Miettinen wrote:
> [seems that posting via gmane is broken - resending (heehee - I do
> resent the gmane problem :) manually via mail - sorry if you get
> duplicates]

FWIW I've been having odd email behavior WRT linux-pm.  I'm not sure if
its my .procmailrc file or something else.

> mark gross <markgross@thegnar.org> writes:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 987a165..4cbd58b 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> [..]
> > +	
> > +	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> > +		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
> >  
> 
> Consider the following sequence
> 
> - say original min is 100MHz
> - PM QoS requests 1GHz minimum
> - user requests 500MHz minimum via sysfs
> - PM QoS request is canceled
> 
> After this the policy->min will be 1GHz. I'm not really happy with the
> min/max save/restore etc but something is needed to enable restoring the
> policy min/max when PM QoS constraints dissappear.

you are right.  If CPUFREQ is to be QoS aware we need to have it save
the request from user mode and compute the max between the user request
and the pm_qos constraint.

--mark

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

[seems that posting via gmane is broken - resending (heehee - I do
resent the gmane problem :) manually via mail - sorry if you get
duplicates]

mark gross <markgross@thegnar.org> writes:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 987a165..4cbd58b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
[..]
> +	
> +	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
> +		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
>  

Consider the following sequence

- say original min is 100MHz
- PM QoS requests 1GHz minimum
- user requests 500MHz minimum via sysfs
- PM QoS request is canceled

After this the policy->min will be 1GHz. I'm not really happy with the
min/max save/restore etc but something is needed to enable restoring the
policy min/max when PM QoS constraints dissappear.

	--Antti

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> The inspiration for this patch series is the N9 CPU frequency boost
> upon input events:
> 
> http://www.spinics.net/lists/cpufreq/msg00667.html
> 
> and the related changes in git://codeaurora.org/kernel/msm.git tree.
> Those patches modify the ondemand cpufreq governor. This patch series
> adds minimum and maximum CPU frequency as PM QoS parameters and
> modifies the cpufreq core to enforce the PM QoS limits. There is also
> an example module for boosting the frequency upon input events.
> 
> I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> E6420 with the ACPI cpufreq driver. The patches are against
> linux-next/master, compile tested against it.
> 
> 	--Antti
> 
> Alex Frid (1):
>   PM QoS: Simplify PM QoS expansion/merge
> 
> Antti P Miettinen (5):
>   PM QoS: Add CPU frequency min/max as PM QoS params
>   cpufreq: Export user_policy min/max
>   cpufreq: Preserve sysfs min/max request
>   cpufreq: Enforce PM QoS min/max limits
>   input: CPU frequency booster
> 
>  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
>  drivers/input/Kconfig         |    9 ++
>  drivers/input/Makefile        |    1 +
>  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_qos.h        |   19 ++++-
>  kernel/power/qos.c            |   55 ++++++++++----
>  6 files changed, 293 insertions(+), 22 deletions(-)
>  create mode 100644 drivers/input/input-cfboost.c
> 
> -- 
> 1.7.4.1
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

The following is my version of part of this patch set I was tinkering
with.  Its missing the cpufreq notification this change has and doesn't
do anything WRT cfboost.

Would it be ok if we could consolidate our two implementations and
completely separate the cfboost stuff as a separate patch set?

My code below is missing the cpufreq notification logic you have.

--mark

Signed-off-by: markgross <markgross@thegnar.org>


>From b4be99354c5af20cbd4041cddd6038e2353e06b4 Mon Sep 17 00:00:00 2001
>From: mgross <mgross@mini>
>Date: Sat, 24 Dec 2011 13:40:03 -0800
>Subject: [PATCH] Some devices have a subtle relationship with the CPU
 throughput and need to set a minimum cpu frequency en order
 for the device to not experience performance issues with
 buffer under runs because the cpu was throttled too much to
 be able to keep the buffers full enough.

One graphics benchmark has shown this issue on Intel SOC devices.  The
graphics part ends up waiting on the cpu to fill the open GL instruction
queue between frames and thus graphic performance suffers because of the
cpu throttling because the CPU really isn't very busy while running the
benchmark.
---
 drivers/cpufreq/cpufreq.c |    8 ++++++++
 include/linux/pm_qos.h    |    8 +++++---
 kernel/power/qos.c        |   19 +++++++++++++++++++
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 987a165..4cbd58b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -29,6 +29,7 @@
 #include <linux/completion.h>
 #include <linux/mutex.h>
 #include <linux/syscore_ops.h>
+#include <linux/pm_qos.h>
 
 #include <trace/events/power.h>
 
@@ -1629,6 +1630,9 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
 
 	pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
 		policy->min, policy->max);
+	
+	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
+		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
 
 	memcpy(&policy->cpuinfo, &data->cpuinfo,
 				sizeof(struct cpufreq_cpuinfo));
@@ -1736,6 +1740,10 @@ int cpufreq_update_policy(unsigned int cpu)
 	policy.policy = data->user_policy.policy;
 	policy.governor = data->user_policy.governor;
 
+	if (policy.min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
+		policy.min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
+
+
 	/* BIOS might change freq behind our back
 	  -> ask driver for current freq and notify governors about a change */
 	if (cpufreq_driver->get) {
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 83b0ea3..ead081c 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -11,13 +11,15 @@
 
 #define PM_QOS_RESERVED 0
 #define PM_QOS_CPU_DMA_LATENCY 1
-#define PM_QOS_NETWORK_LATENCY 2
-#define PM_QOS_NETWORK_THROUGHPUT 3
+#define PM_QOS_CPU_THROUGHPUT 2
+#define PM_QOS_NETWORK_LATENCY 3
+#define PM_QOS_NETWORK_THROUGHPUT 4
 
-#define PM_QOS_NUM_CLASSES 4
+#define PM_QOS_NUM_CLASSES 5
 #define PM_QOS_DEFAULT_VALUE -1
 
 #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
+#define PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE	0
 #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
 #define PM_QOS_DEV_LAT_DEFAULT_VALUE		0
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 995e3bd..92951fa 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -60,6 +60,19 @@ static DEFINE_SPINLOCK(pm_qos_lock);
 
 static struct pm_qos_object null_pm_qos;
 
+static BLOCKING_NOTIFIER_HEAD(cpu_throughput_notifier);
+static struct pm_qos_constraints cpu_throughput_constraints = {
+	.list = PLIST_HEAD_INIT(cpu_throughput_constraints.list),
+	.target_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
+	.default_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
+	.type = PM_QOS_MIN,
+	.notifiers = &cpu_throughput_notifier,
+};
+static struct pm_qos_object cpu_throughput_pm_qos = {
+	.constraints = &cpu_throughput_constraints,
+	.name = "cpu_throughput",
+};
+
 static BLOCKING_NOTIFIER_HEAD(cpu_dma_lat_notifier);
 static struct pm_qos_constraints cpu_dma_constraints = {
 	.list = PLIST_HEAD_INIT(cpu_dma_constraints.list),
@@ -104,6 +117,7 @@ static struct pm_qos_object network_throughput_pm_qos = {
 static struct pm_qos_object *pm_qos_array[] = {
 	&null_pm_qos,
 	&cpu_dma_pm_qos,
+	&cpu_throughput_pm_qos,
 	&network_lat_pm_qos,
 	&network_throughput_pm_qos
 };
@@ -475,6 +489,11 @@ static int __init pm_qos_power_init(void)
 		printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
 		return ret;
 	}
+	ret = register_pm_qos_misc(&cpu_throughput_pm_qos);
+	if (ret < 0) {
+		printk(KERN_ERR "pm_qos_param: cpu_throughput setup failed\n");
+		return ret;
+	}
 	ret = register_pm_qos_misc(&network_lat_pm_qos);
 	if (ret < 0) {
 		printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
-- 
1.7.5.4

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> The inspiration for this patch series is the N9 CPU frequency boost
> upon input events:
> 
> http://www.spinics.net/lists/cpufreq/msg00667.html
> 
> and the related changes in git://codeaurora.org/kernel/msm.git tree.
> Those patches modify the ondemand cpufreq governor. This patch series
> adds minimum and maximum CPU frequency as PM QoS parameters and
> modifies the cpufreq core to enforce the PM QoS limits. There is also
> an example module for boosting the frequency upon input events.
> 
> I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> E6420 with the ACPI cpufreq driver. The patches are against
> linux-next/master, compile tested against it.
> 
> 	--Antti
> 
> Alex Frid (1):
>   PM QoS: Simplify PM QoS expansion/merge
> 
> Antti P Miettinen (5):
>   PM QoS: Add CPU frequency min/max as PM QoS params
>   cpufreq: Export user_policy min/max
>   cpufreq: Preserve sysfs min/max request
>   cpufreq: Enforce PM QoS min/max limits
>   input: CPU frequency booster
> 
>  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
>  drivers/input/Kconfig         |    9 ++
>  drivers/input/Makefile        |    1 +
>  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_qos.h        |   19 ++++-
>  kernel/power/qos.c            |   55 ++++++++++----
>  6 files changed, 293 insertions(+), 22 deletions(-)
>  create mode 100644 drivers/input/input-cfboost.c
> 
> -- 
> 1.7.4.1
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

The following is my version of part of this patch set I was tinkering
with.  Its missing the cpufreq notification this change has and doesn't
do anything WRT cfboost.

Would it be ok if we could consolidate our two implementations and
completely separate the cfboost stuff as a separate patch set?

My code below is missing the cpufreq notification logic you have.

--mark

Signed-off-by: markgross <markgross@thegnar.org>


>From b4be99354c5af20cbd4041cddd6038e2353e06b4 Mon Sep 17 00:00:00 2001
From: mgross <mgross@mini>
Date: Sat, 24 Dec 2011 13:40:03 -0800
Subject: [PATCH] Some devices have a subtle relationship with the CPU
 throughput and need to set a minimum cpu frequency en order
 for the device to not experience performance issues with
 buffer under runs because the cpu was throttled too much to
 be able to keep the buffers full enough.

One graphics benchmark has shown this issue on Intel SOC devices.  The
graphics part ends up waiting on the cpu to fill the open GL instruction
queue between frames and thus graphic performance suffers because of the
cpu throttling because the CPU really isn't very busy while running the
benchmark.
---
 drivers/cpufreq/cpufreq.c |    8 ++++++++
 include/linux/pm_qos.h    |    8 +++++---
 kernel/power/qos.c        |   19 +++++++++++++++++++
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 987a165..4cbd58b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -29,6 +29,7 @@
 #include <linux/completion.h>
 #include <linux/mutex.h>
 #include <linux/syscore_ops.h>
+#include <linux/pm_qos.h>
 
 #include <trace/events/power.h>
 
@@ -1629,6 +1630,9 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
 
 	pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
 		policy->min, policy->max);
+	
+	if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
+		policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
 
 	memcpy(&policy->cpuinfo, &data->cpuinfo,
 				sizeof(struct cpufreq_cpuinfo));
@@ -1736,6 +1740,10 @@ int cpufreq_update_policy(unsigned int cpu)
 	policy.policy = data->user_policy.policy;
 	policy.governor = data->user_policy.governor;
 
+	if (policy.min < pm_qos_request(PM_QOS_CPU_THROUGHPUT))
+		policy.min = pm_qos_request(PM_QOS_CPU_THROUGHPUT);
+
+
 	/* BIOS might change freq behind our back
 	  -> ask driver for current freq and notify governors about a change */
 	if (cpufreq_driver->get) {
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 83b0ea3..ead081c 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -11,13 +11,15 @@
 
 #define PM_QOS_RESERVED 0
 #define PM_QOS_CPU_DMA_LATENCY 1
-#define PM_QOS_NETWORK_LATENCY 2
-#define PM_QOS_NETWORK_THROUGHPUT 3
+#define PM_QOS_CPU_THROUGHPUT 2
+#define PM_QOS_NETWORK_LATENCY 3
+#define PM_QOS_NETWORK_THROUGHPUT 4
 
-#define PM_QOS_NUM_CLASSES 4
+#define PM_QOS_NUM_CLASSES 5
 #define PM_QOS_DEFAULT_VALUE -1
 
 #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
+#define PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE	0
 #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
 #define PM_QOS_DEV_LAT_DEFAULT_VALUE		0
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 995e3bd..92951fa 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -60,6 +60,19 @@ static DEFINE_SPINLOCK(pm_qos_lock);
 
 static struct pm_qos_object null_pm_qos;
 
+static BLOCKING_NOTIFIER_HEAD(cpu_throughput_notifier);
+static struct pm_qos_constraints cpu_throughput_constraints = {
+	.list = PLIST_HEAD_INIT(cpu_throughput_constraints.list),
+	.target_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
+	.default_value = PM_QOS_CPU_THROUGHPUT_DEFAULT_VALUE,
+	.type = PM_QOS_MIN,
+	.notifiers = &cpu_throughput_notifier,
+};
+static struct pm_qos_object cpu_throughput_pm_qos = {
+	.constraints = &cpu_throughput_constraints,
+	.name = "cpu_throughput",
+};
+
 static BLOCKING_NOTIFIER_HEAD(cpu_dma_lat_notifier);
 static struct pm_qos_constraints cpu_dma_constraints = {
 	.list = PLIST_HEAD_INIT(cpu_dma_constraints.list),
@@ -104,6 +117,7 @@ static struct pm_qos_object network_throughput_pm_qos = {
 static struct pm_qos_object *pm_qos_array[] = {
 	&null_pm_qos,
 	&cpu_dma_pm_qos,
+	&cpu_throughput_pm_qos,
 	&network_lat_pm_qos,
 	&network_throughput_pm_qos
 };
@@ -475,6 +489,11 @@ static int __init pm_qos_power_init(void)
 		printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
 		return ret;
 	}
+	ret = register_pm_qos_misc(&cpu_throughput_pm_qos);
+	if (ret < 0) {
+		printk(KERN_ERR "pm_qos_param: cpu_throughput setup failed\n");
+		return ret;
+	}
 	ret = register_pm_qos_misc(&network_lat_pm_qos);
 	if (ret < 0) {
 		printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
-- 
1.7.5.4

Re: [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[mark gross]

On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:
> The inspiration for this patch series is the N9 CPU frequency boost
> upon input events:
> 
> http://www.spinics.net/lists/cpufreq/msg00667.html
> 
> and the related changes in git://codeaurora.org/kernel/msm.git tree.
> Those patches modify the ondemand cpufreq governor. This patch series
> adds minimum and maximum CPU frequency as PM QoS parameters and
> modifies the cpufreq core to enforce the PM QoS limits. There is also
> an example module for boosting the frequency upon input events.
> 
> I've been testing these changes against Ubuntu 3.2 kernel on a Dell
> E6420 with the ACPI cpufreq driver. The patches are against
> linux-next/master, compile tested against it.

wow, isn't this is timely :)
I was working on the same thing.  I used different names.  FWIW our
issue is motivated by some graphics workloads that get starved for
frames because the cpufreq governor sees nothing by < 50% CPU use so it
pushes the cpu into a low P-state which doesn't have throughput to feed
the next frame of OpenGL data before the next frame time.  This is
pretty common for some graphics workloads.

I look forward to reviewing you path set!

--mark


> 	--Antti
> 
> Alex Frid (1):
>   PM QoS: Simplify PM QoS expansion/merge
> 
> Antti P Miettinen (5):
>   PM QoS: Add CPU frequency min/max as PM QoS params
>   cpufreq: Export user_policy min/max
>   cpufreq: Preserve sysfs min/max request
>   cpufreq: Enforce PM QoS min/max limits
>   input: CPU frequency booster
> 
>  drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
>  drivers/input/Kconfig         |    9 ++
>  drivers/input/Makefile        |    1 +
>  drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_qos.h        |   19 ++++-
>  kernel/power/qos.c            |   55 ++++++++++----
>  6 files changed, 293 insertions(+), 22 deletions(-)
>  create mode 100644 drivers/input/input-cfboost.c
> 
> -- 
> 1.7.4.1
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

[PATCH 0/6] RFC: CPU frequency min/max as PM QoS params

[Antti P Miettinen]

The inspiration for this patch series is the N9 CPU frequency boost
upon input events:

http://www.spinics.net/lists/cpufreq/msg00667.html

and the related changes in git://codeaurora.org/kernel/msm.git tree.
Those patches modify the ondemand cpufreq governor. This patch series
adds minimum and maximum CPU frequency as PM QoS parameters and
modifies the cpufreq core to enforce the PM QoS limits. There is also
an example module for boosting the frequency upon input events.

I've been testing these changes against Ubuntu 3.2 kernel on a Dell
E6420 with the ACPI cpufreq driver. The patches are against
linux-next/master, compile tested against it.

	--Antti

Alex Frid (1):
  PM QoS: Simplify PM QoS expansion/merge

Antti P Miettinen (5):
  PM QoS: Add CPU frequency min/max as PM QoS params
  cpufreq: Export user_policy min/max
  cpufreq: Preserve sysfs min/max request
  cpufreq: Enforce PM QoS min/max limits
  input: CPU frequency booster

 drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
 drivers/input/Kconfig         |    9 ++
 drivers/input/Makefile        |    1 +
 drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_qos.h        |   19 ++++-
 kernel/power/qos.c            |   55 ++++++++++----
 6 files changed, 293 insertions(+), 22 deletions(-)
 create mode 100644 drivers/input/input-cfboost.c

-- 
1.7.4.1