[RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[Jonghwa Lee]

From: Lukasz Majewski <l.majewski@samsung.com>

The purpose of this series is to discuss assumptions and idea of implementing
LAB governor support. It shall be treated as a proof-of-concept code for new
(fresh) view on power consumption reduction.

It is divided to three big parts:
1. Low-level code for supporting frequency overclocking at Exynos4 SoCs.
Moreover support for cpufreq_overclock_* interface functions has been added.
This feature is implemented in a way to reduce number of changes at cpufreq
core driver to minimum. 

It alters entries at SoC specific frequency table to allow above the standard 
limits frequency. Exynos TMU (Thermal Management Unit) is a "safe valve" to 
disable overclocking when overheating is detected.

Despite, that this solution is Exynos4 specific it can be easily ported to other 
SoCs.

2. New LAB governor.
It calculates number of idle CPUs (based on scheduler data). On this basis it 
chose proper first level polynomial function for approximation.
Moreover it enables overclocking when single, heavy loaded CPU is running.

Those new heuristics allow for more platform tight frequency level decision.
To work efficienty this governor relies on scheduler to pack as much tasks as 
possible to running cores and put other to IDLE.
Following patches are helpful (one of):
- Vincent Guittot's "packing small tasks" patch
- Alex Shi's power-aware scheduling patch

3. Set of changes needed at core cpufreq code.
The only relevant change is to store idle_time value for each CPU.

Tested at 3.8 linux kernel, Exynos4412 Device

For more details please see respect log messages.


Lukasz Majewski (3):
  cpufreq:overclocking: Overclocking support at Exynos4 SoC
  cpufreq:LAB: Introduce new cpufreq LAB(Legacy Application Boost)
    governor
  cpufreq:LAB: Modify cpufreq_governor to support LAB Governor


 drivers/cpufreq/Kconfig              |   33 +++
 drivers/cpufreq/Makefile             |    1 +
 drivers/cpufreq/cpufreq_governor.c   |    7 +
 drivers/cpufreq/cpufreq_governor.h   |   15 ++
 drivers/cpufreq/cpufreq_lab.c        |  450 ++++++++++++++++++++++++++++++++++
 drivers/cpufreq/exynos-cpufreq.c     |  108 ++++++++
 drivers/cpufreq/exynos-cpufreq.h     |    7 +
 drivers/cpufreq/exynos4x12-cpufreq.c |   15 ++
 include/linux/cpufreq.h              |   35 +++
 9 files changed, 671 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

-- 
1.7.9.5

[RFC v2 1/3] cpufreq:overclocking: Overclocking support at Exynos4 SoC

[Jonghwa Lee]

From: Lukasz Majewski <l.majewski@samsung.com>

Exynos4 SoCs (e.g. 4x12) allow setting of frequency above its normal
condition limits. This can be done for some short time.

This commit comprises of:
- low-level code for overclocking support at Exynos4x12 SoC
- exynos-cpufreq.c modifications to support generic cpufreq_overclk_*
functions (which are used at LAB governor)
- Export cpufreq_overclk_* at cpufreq.h
- Code to enable cpufreq at Kconfig

It is crucial to also enable TMU (Thermal Monitoring Unit) to prevent from
overheating the SoC.

When CPU_FREQ_OVERCLOCK is enabled, two extra switches were added:
1. tb_en_over_clk - enable feature
2. tb_over_clk_freq - read overclocked freqency (defied at device tree)

Tested at 3.8 linux kernel, Exynos4412 Device.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
---
 drivers/cpufreq/Kconfig              |    7 +++
 drivers/cpufreq/exynos-cpufreq.c     |  108 ++++++++++++++++++++++++++++++++++
 drivers/cpufreq/exynos-cpufreq.h     |    7 +++
 drivers/cpufreq/exynos4x12-cpufreq.c |   15 +++++
 include/linux/cpufreq.h              |   32 ++++++++++
 5 files changed, 169 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index a1488f5..5a1c236 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -23,6 +23,13 @@ config CPU_FREQ_TABLE
 config CPU_FREQ_GOV_COMMON
 	bool
 
+config CPU_FREQ_OVERCLOCK
+	bool "CPU frequency overclocking support"
+	help
+	  Switch to enable support for overclocking support
+
+	  If in doubt, say N.
+
 config CPU_FREQ_STAT
 	tristate "CPU frequency translation statistics"
 	select CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 475b4f6..eac6818 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -239,6 +239,99 @@ static struct notifier_block exynos_cpufreq_nb = {
 	.notifier_call = exynos_cpufreq_pm_notifier,
 };
 
+#ifdef CONFIG_CPU_FREQ_OVERCLOCK
+static int tb_over_clk_update_freq(struct cpufreq_policy *policy, int enable)
+{
+	int ret, index;
+
+	index = exynos_info->get_freq_index(exynos_info->max_over_freq);
+	if (index < 0) {
+		pr_err("%s: Index not found !\n", __func__);
+		return -EINVAL;
+	}
+
+	mutex_lock(&cpufreq_lock);
+	exynos_info->max_over_idx = index;
+	exynos_info->en_over_clk = enable;
+
+	if (enable)
+		cpufreq_freq_table_set_valid_entry(exynos_info->freq_table,
+						   index,
+						   exynos_info->max_over_freq);
+	else
+		cpufreq_freq_table_set_invalid_entry(exynos_info->freq_table,
+						     index);
+
+	ret = cpufreq_frequency_table_cpuinfo(policy, exynos_info->freq_table);
+	mutex_unlock(&cpufreq_lock);
+
+	return ret;
+}
+
+int cpufreq_overclk_en(struct cpufreq_policy *policy)
+{
+	if (!exynos_info->en_over_clk)
+		return tb_over_clk_update_freq(policy, 1);
+
+	return 0;
+}
+
+int cpufreq_overclk_dis(struct cpufreq_policy *policy)
+{
+	if (exynos_info->en_over_clk)
+		return tb_over_clk_update_freq(policy, 0);
+
+	return 0;
+}
+
+int cpufreq_overclk_max(void)
+{
+	return exynos_info->max_over_freq;
+}
+
+static ssize_t show_tb_en_over_clk(struct cpufreq_policy *policy, char *buf)
+{
+	return sprintf(buf, "%d\n", exynos_info->en_over_clk);
+}
+
+static ssize_t store_tb_en_over_clk(struct cpufreq_policy *policy,
+				    const char *buf, size_t count)
+{
+	int ret, enable;
+
+	ret = sscanf(buf, "%d", &enable);
+	if (ret != 1 || enable < 0 || enable > 1)
+		return -EINVAL;
+
+	if (tb_over_clk_update_freq(policy, enable)) {
+		pr_err("Cannot enable TurboBoost overclocking!\n");
+		return -EINVAL;
+	}
+
+	return count;
+}
+
+struct freq_attr cpufreq_attr_tb_en_over_clk = {
+	.attr = { .name = "tb_en_over_clk",
+		  .mode = 0644,
+		},
+	.show = show_tb_en_over_clk,
+	.store = store_tb_en_over_clk,
+};
+
+static ssize_t show_tb_over_clk_freq(struct cpufreq_policy *policy, char *buf)
+{
+	return sprintf(buf, "%d\n", exynos_info->max_over_freq);
+}
+
+struct freq_attr cpufreq_attr_tb_over_clk_freq = {
+	.attr = { .name = "tb_over_clk_freq",
+		  .mode = 0444,
+		},
+	.show = show_tb_over_clk_freq,
+};
+#endif
+
 static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
 	policy->cur = policy->min = policy->max = exynos_getspeed(policy->cpu);
@@ -261,6 +354,10 @@ static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 
 static struct freq_attr *exynos_cpufreq_attr[] = {
 	&cpufreq_freq_attr_scaling_available_freqs,
+#ifdef CONFIG_CPU_FREQ_OVERCLOCK
+	&cpufreq_attr_tb_over_clk_freq,
+	&cpufreq_attr_tb_en_over_clk,
+#endif
 	NULL,
 };
 
@@ -281,6 +378,7 @@ static struct cpufreq_driver exynos_driver = {
 
 static int __init exynos_cpufreq_init(void)
 {
+	struct device_node *node = pdev->dev.of_node;
 	int ret = -EINVAL;
 
 	exynos_info = kzalloc(sizeof(struct exynos_dvfs_info), GFP_KERNEL);
@@ -310,6 +408,16 @@ static int __init exynos_cpufreq_init(void)
 		goto err_vdd_arm;
 	}
 
+#ifdef CONFIG_CPU_FREQ_OVERCLOCK
+	if (of_property_read_bool(node, "overclocking")) {
+		of_property_read_u32(node, "max_overclocking_freq",
+				     &exynos_info->max_over_freq);
+		pr_debug("%s: en_overclk: %d max_overclocking_freq: %d\n",
+			 __func__, exynos_info->en_over_clk,
+			 exynos_info->max_over_freq);
+	}
+#endif
+
 	locking_frequency = exynos_getspeed(0);
 
 	register_pm_notifier(&exynos_cpufreq_nb);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 92b852e..bc8ecfc 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -39,8 +39,15 @@ struct exynos_dvfs_info {
 	struct clk	*cpu_clk;
 	unsigned int	*volt_table;
 	struct cpufreq_frequency_table	*freq_table;
+	unsigned int    en_over_clk; /* enable overclocking
+					 for this policy */
+	unsigned int    max_over_freq; /* maximal overclocked
+					  frequency */
+	unsigned int    max_over_idx; /* maximal overclocked
+					 index at freq_table */
 	void (*set_freq)(unsigned int, unsigned int);
 	bool (*need_apll_change)(unsigned int, unsigned int);
+	int (*get_freq_index)(unsigned int);
 };
 
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c b/drivers/cpufreq/exynos4x12-cpufreq.c
index 08b7477..08ccfae 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -216,6 +216,20 @@ static void exynos4x12_set_frequency(unsigned int old_index,
 	}
 }
 
+int exynos4x12_get_freq_index(unsigned int freq)
+{
+	/* apll_freq tables are equal size for exynos4412 and exynos 4212 */
+	int i, size = ARRAY_SIZE(apll_freq_4412);
+
+	for (i = 0; i < size; i++)
+		if (apll_freq_4x12[i].freq == freq)
+			return i;
+
+	pr_debug("Entry for freq: %u not found\n", freq);
+
+	return -EINVAL;
+}
+
 int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 {
 	unsigned long rate;
@@ -251,6 +265,7 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 	info->freq_table = exynos4x12_freq_table;
 	info->set_freq = exynos4x12_set_frequency;
 	info->need_apll_change = exynos4x12_pms_change;
+	info->get_freq_index = exynos4x12_get_freq_index;
 
 	return 0;
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..8c185d6 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -331,6 +331,24 @@ static struct global_attr _name =		\
 __ATTR(_name, 0644, show_##_name, store_##_name)
 
 struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
+#ifdef CONFIG_CPU_FREQ_OVERCLOCK
+int cpufreq_overclk_dis(struct cpufreq_policy *policy);
+int cpufreq_overclk_en(struct cpufreq_policy *policy);
+int cpufreq_overclk_max(void);
+#else
+static inline int cpufreq_overclk_dis(struct cpufreq_policy *policy)
+{
+	return 0;
+}
+static inline int cpufreq_overclk_en (struct cpufreq_policy *policy)
+{
+	return 0;
+}
+static inline int cpufreq_overclk_max(void)
+{
+	return 0;
+}
+#endif
 void cpufreq_cpu_put(struct cpufreq_policy *data);
 const char *cpufreq_get_current_driver(void);
 
@@ -409,6 +427,20 @@ struct cpufreq_frequency_table {
 				    * order */
 };
 
+static inline void cpufreq_freq_table_set_valid_entry(
+					struct cpufreq_frequency_table *table,
+					unsigned int index, unsigned int freq)
+{
+	table[index].frequency = freq;
+}
+
+static inline void cpufreq_freq_table_set_invalid_entry(
+					  struct cpufreq_frequency_table *table,
+					  unsigned int index)
+{
+	table[index].frequency = CPUFREQ_ENTRY_INVALID;
+}
+
 int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
 				    struct cpufreq_frequency_table *table);
 
-- 
1.7.9.5

[RFC v2 2/3] cpufreq:LAB: Introduce new cpufreq LAB(Legacy Application Boost) governor

[Jonghwa Lee]

From: Lukasz Majewski <l.majewski@samsung.com>

This patch introduces new cpufreq governor named 'LAB'.
LAB governor will use scheduler, per-CPU information to determine how many
CPUs are in busy now. As a result the number of idle CPUs is calculated
for current load (digital low pass filtering is used to provide more stable
results). It will determine next frequency.

For instance, we can assume that it is working on quad core processor.

For each number of idle CPUs, separate single polynomial function has been
calculated (with different slope). For all CPUs idle, minimal policy freq
is chosen.

With only one busy processor, the new feature (overclock) will enable CPU
frequency boost above normal operation limit. This will allow for "faster"
work finish.
With two running CPUs, overclocking is disabled and output frequency is
close to maximum.
For three running cores the frequency is further lowered (the slope of
approximation polynomial changes, when compared to two running CPUs).

When all four cores are busy, the frequency is lowered. The slope of polynomial
is decreasing, so higher load will cause lower freq.

The LAB governor rely on following kernel features:
- TMU (Thermal Management Unit) to disable overclocking when thermal trip point
is passed (notifier for cpufreq TMU generated event is registered at LAB).
- overclocking - needed to set frequency above standard levels.

The LAB governor itself uses infrastructure (work_struct) from ondemand.
The ondemand calculates the highest load among all available CPUs. The LAB
adjusts the freq characteristics depending on the number of idle CPUs.

The LAB governor shall be used with either:
- Vincent Guittot's "packing small tasks" patch
- Alex Shi's power-aware scheduling patch

Those patches help with putting to idle as much CPUs as possible.

Tested at 3.8 linux kernel, Exynos4412 Device

Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Kconfig       |   26 +++
 drivers/cpufreq/Makefile      |    1 +
 drivers/cpufreq/cpufreq_lab.c |  450 +++++++++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h       |    3 +
 4 files changed, 480 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 5a1c236..81d7ea7 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -109,6 +109,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
 	  Be aware that not all cpufreq drivers support the conservative
 	  governor. If unsure have a look at the help section of the
 	  driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_LAB
+	bool "lab"
+	select CPU_FREQ_GOV_LAB
+	select CPU_FREQ_GOV_PERFORMANCE
+	help
+	  Use the CPUFreq governor 'lab' as default. This allows
+	  you to get a full dynamic frequency capable system by simply
+	  loading your cpufreq low-level hardware driver.
+	  Be aware that not all cpufreq drivers support the lab governor.
+	  If unsure have a look at the help section of the driver.
+	  Fallback governor will be the performance governor.
 endchoice
 
 config CPU_FREQ_GOV_PERFORMANCE
@@ -191,6 +203,20 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+config CPU_FREQ_GOV_LAB
+	tristate "'lab' cpufreq policy governor"
+	select CPU_FREQ_TABLE
+	select CPU_FREQ_GOV_COMMON
+	help
+	  'lab' - This driver adds a dynamic cpufreq policy governor.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called cpufreq_ondemand.
+
+	  For details, take a look at linux/Documentation/cpu-freq.
+
+	  If in doubt, say N.
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 315b923..d8252a7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)	+= cpufreq_powersave.o
 obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE)	+= cpufreq_userspace.o
 obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)	+= cpufreq_ondemand.o
 obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)	+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB)		+= cpufreq_lab.o
 obj-$(CONFIG_CPU_FREQ_GOV_COMMON)		+= cpufreq_governor.o
 
 # CPUfreq cross-arch helpers
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 0000000..e992810
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,450 @@
+/*
+ *  drivers/cpufreq/cpufreq_lab.c
+ *
+ *  LAB(Legacy Application Boost) cpufreq governor
+ *
+ *  Copyright (C) SAMSUNG Electronics. CO.
+ *		Jonghwa Lee <jonghw3.lee@samusng.com>
+ *		Lukasz Majewski <l.majewski@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kernel_stat.h>
+#include <linux/kobject.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/percpu-defs.h>
+#include <linux/sysfs.h>
+#include <linux/tick.h>
+#include <linux/types.h>
+#include <linux/cpuidle.h>
+#include <linux/slab.h>
+
+#include "cpufreq_governor.h"
+
+#define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
+#define DEF_FREQUENCY_UP_THRESHOLD		(80)
+#define DEF_SAMPLING_DOWN_FACTOR		(1)
+#define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
+#define MICRO_FREQUENCY_UP_THRESHOLD		(95)
+#define MICRO_FREQUENCY_MIN_SAMPLE_RATE		(10000)
+
+#define MAX_HIST		5
+#define FREQ_STEP		50000
+#define IDLE_THRESHOLD		90
+#define OVERCLK_THRESHOLD       90
+
+/* Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int **idle_hist;
+
+static struct dbs_data lb_dbs_data;
+static DEFINE_PER_CPU(struct lb_cpu_dbs_info_s, lb_cpu_dbs_info);
+
+#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+static struct cpufreq_governor cpufreq_gov_lab;
+#endif
+
+/* Single polynomial approx -> all CPUs busy */
+static int a_all = -6, b_all = 1331;
+/* Single polynomial approx -> one CPUs busy */
+static int a_one = 10, b_one = 205;
+/* Single polynomial approx -> 2,3... CPUs busy */
+static int a_rest = 4, b_rest1 = 100, b_rest2 = 300;
+/* Polynomial divider */
+static int poly_div = 1024;
+
+static struct od_dbs_tuners lb_tuners = {
+	.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
+	.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
+	.down_differential = DEF_FREQUENCY_DOWN_DIFFERENTIAL,
+	.ignore_nice = 0,
+};
+
+/**
+ * cpufreq_overclock_notifier - notifier callback for cpufreq policy change.
+ * @nb:	struct notifier_block * with callback info.
+ * @event: value showing cpufreq event for which this function invoked.
+ * @data: callback-specific data
+ */
+static int cpufreq_overclk_notifier(struct notifier_block *nb,
+				    unsigned long event, void *data)
+{
+	struct cpufreq_policy *policy = data;
+
+	if (event == CPUFREQ_INCOMPATIBLE &&
+	    cpufreq_overclk_max() == policy->cur) {
+		pr_info("NOTIFIER OVERCLOCK: MAX: %d e:%lu cpu: %d\n",
+			policy->max, event, policy->cpu);
+		cpufreq_overclk_dis(policy);
+	}
+
+	return 0;
+}
+
+/* Notifier for cpufreq policy change */
+static struct notifier_block cpufreq_overclk_notifier_block = {
+	.notifier_call = cpufreq_overclk_notifier,
+};
+
+static void dbs_freq_increase(struct cpufreq_policy *p, unsigned int freq)
+{
+	if (p->cur == freq)
+		return;
+
+	__cpufreq_driver_target(p, freq, CPUFREQ_RELATION_L);
+}
+
+/* Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+	int i, sum;
+
+	for (i = 0, sum = 0; i < size; p++, i++) {
+		sum += *p;
+		*p >>= 1;
+	}
+	sum *= 100;
+
+	return (int) (sum / history_weight_sum[size]);
+}
+
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load_freq)
+{
+	struct lb_cpu_dbs_info_s *dbs_info = &per_cpu(lb_cpu_dbs_info, cpu);
+	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+	int i, idx, idle_cpus = 0, b = 0;
+	static int cnt = 0;
+	unsigned int freq = 0;
+
+	idx = cnt++ % MAX_HIST;
+
+	for_each_possible_cpu(i) {
+		struct lb_cpu_dbs_info_s *dbs_cpu_info =
+			&per_cpu(lb_cpu_dbs_info, i);
+
+		idle_hist[i][idx] = dbs_cpu_info->idle_time;
+		idle_avg[i] = cpu_idle_calc_avg(idle_hist[i],
+					cnt < MAX_HIST ? cnt : MAX_HIST);
+
+		if (idle_avg[i] > IDLE_THRESHOLD)
+			idle_cpus++;
+	}
+#if 0
+	pr_info("load_freq: %d idle: %d\n", load_freq, idle_cpus);
+#endif
+	if (idle_cpus < 0 || idle_cpus > NR_CPUS) {
+		pr_warn("idle_cpus: %d out of range\n", idle_cpus);
+		return;
+	}
+
+	if (idle_cpus == 0) { /* Full load -> reduce freq */
+		freq = policy->max * (a_all * load_freq + b_all) / poly_div;
+
+	} else if (idle_cpus == NR_CPUS) { /* Idle cpus */
+		cpufreq_overclk_dis(policy);
+		freq = policy->min;
+
+	} else if (idle_cpus == (NR_CPUS - 1)) {
+		/* Enable overclocking */
+		if(load_freq > OVERCLK_THRESHOLD)
+			cpufreq_overclk_en(policy);
+
+		freq = policy->max * (a_one * load_freq + b_one) / poly_div;
+
+	} else {
+		/* Adjust frequency with number of available CPUS */
+		/* smaller idle_cpus -> smaller frequency */
+		b = ((idle_cpus - 1) * b_rest1) + b_rest2;
+		freq = policy->max * (a_rest * load_freq + b) / poly_div;
+	}
+#if 1
+	if (!idx)
+		pr_info("p->max:%d,freq: %d,idle_cpus: %d,avg : %d %d %d %d load_f: %d\n",
+		       policy->max, freq, idle_cpus, idle_avg[0], idle_avg[1],
+			idle_avg[2], idle_avg[3], load_freq);
+#endif
+
+	dbs_freq_increase(policy, freq);
+}
+
+static void lb_dbs_timer(struct work_struct *work)
+{
+	struct delayed_work *dw = to_delayed_work(work);
+	struct lb_cpu_dbs_info_s *dbs_info =
+		container_of(work, struct lb_cpu_dbs_info_s, cdbs.work.work);
+	unsigned int cpu = dbs_info->cdbs.cur_policy->cpu;
+	struct lb_cpu_dbs_info_s *core_dbs_info = &per_cpu(lb_cpu_dbs_info,
+			cpu);
+	int delay, sample_type = core_dbs_info->sample_type;
+
+	mutex_lock(&core_dbs_info->cdbs.timer_mutex);
+
+	/* Common NORMAL_SAMPLE setup */
+	core_dbs_info->sample_type = OD_NORMAL_SAMPLE;
+	if (sample_type == OD_SUB_SAMPLE) {
+		delay = core_dbs_info->freq_lo_jiffies;
+		__cpufreq_driver_target(core_dbs_info->cdbs.cur_policy,
+			core_dbs_info->freq_lo, CPUFREQ_RELATION_H);
+	} else {
+		dbs_check_cpu(&lb_dbs_data, cpu);
+		if (core_dbs_info->freq_lo) {
+			/* Setup timer for SUB_SAMPLE */
+			core_dbs_info->sample_type = OD_SUB_SAMPLE;
+			delay = core_dbs_info->freq_hi_jiffies;
+		} else {
+			delay = delay_for_sampling_rate(lb_tuners.sampling_rate
+						* core_dbs_info->rate_mult);
+		}
+	}
+
+	dbs_info->last_sampling_rate = jiffies_to_usecs(delay);
+
+	schedule_delayed_work_on(smp_processor_id(), dw, delay);
+	mutex_unlock(&core_dbs_info->cdbs.timer_mutex);
+}
+
+/************************** sysfs interface ************************/
+
+static ssize_t show_sampling_rate_min(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_dbs_data.min_sampling_rate);
+}
+
+/**
+ * update_sampling_rate - update sampling rate effective immediately if needed.
+ * @new_rate: new sampling rate
+ *
+ * If new rate is smaller than the old, simply updating
+ * dbs_tuners_int.sampling_rate might not be appropriate. For example, if the
+ * original sampling_rate was 1 second and the requested new sampling rate is 10
+ * ms because the user needs immediate reaction from lab governor, but not
+ * sure if higher frequency will be required or not, then, the governor may
+ * change the sampling rate too late; up to 1 second later. Thus, if we are
+ * reducing the sampling rate, we need to make the new value effective
+ * immediately.
+ */
+static void update_sampling_rate(unsigned int new_rate)
+{
+	int cpu;
+
+	lb_tuners.sampling_rate = new_rate = max(new_rate,
+			lb_dbs_data.min_sampling_rate);
+
+	for_each_online_cpu(cpu) {
+		struct cpufreq_policy *policy;
+		struct lb_cpu_dbs_info_s *dbs_info;
+		unsigned long next_sampling, appointed_at;
+
+		policy = cpufreq_cpu_get(cpu);
+		if (!policy)
+			continue;
+		if (policy->governor != &cpufreq_gov_lab) {
+			cpufreq_cpu_put(policy);
+			continue;
+		}
+		dbs_info = &per_cpu(lb_cpu_dbs_info, cpu);
+		cpufreq_cpu_put(policy);
+
+		mutex_lock(&dbs_info->cdbs.timer_mutex);
+
+		if (!delayed_work_pending(&dbs_info->cdbs.work)) {
+			mutex_unlock(&dbs_info->cdbs.timer_mutex);
+			continue;
+		}
+
+		next_sampling = jiffies + usecs_to_jiffies(new_rate);
+		appointed_at = dbs_info->cdbs.work.timer.expires;
+
+		if (time_before(next_sampling, appointed_at)) {
+
+			mutex_unlock(&dbs_info->cdbs.timer_mutex);
+			cancel_delayed_work_sync(&dbs_info->cdbs.work);
+			mutex_lock(&dbs_info->cdbs.timer_mutex);
+
+			schedule_delayed_work_on(cpu, &dbs_info->cdbs.work,
+					usecs_to_jiffies(new_rate));
+
+		}
+		mutex_unlock(&dbs_info->cdbs.timer_mutex);
+	}
+}
+
+static ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
+				   const char *buf, size_t count)
+{
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+	if (ret != 1)
+		return -EINVAL;
+	update_sampling_rate(input);
+	return count;
+}
+
+show_one(lb, sampling_rate, sampling_rate);
+define_one_global_rw(sampling_rate);
+define_one_global_ro(sampling_rate_min);
+
+static struct attribute *dbs_attributes[] = {
+	&sampling_rate_min.attr,
+	&sampling_rate.attr,
+	NULL
+};
+
+static struct attribute_group lb_attr_group = {
+	.attrs = dbs_attributes,
+	.name = "lab",
+};
+
+/************************** sysfs end ************************/
+
+static unsigned int powersave_bias_target(struct cpufreq_policy *policy,
+		unsigned int freq_next, unsigned int relation)
+{
+	return 0;
+}
+
+static void powersave_bias_init_cpu(int cpu)
+{
+}
+
+static int should_io_be_busy(void)
+{
+	return 0;
+}
+
+define_get_cpu_dbs_routines(lb_cpu_dbs_info);
+
+static struct od_ops lb_ops = {
+	.io_busy = should_io_be_busy,
+	.powersave_bias_init_cpu = powersave_bias_init_cpu,
+	.powersave_bias_target = powersave_bias_target,
+	.freq_increase = dbs_freq_increase,
+};
+
+static struct dbs_data lb_dbs_data = {
+	.governor = GOV_LAB,
+	.attr_group = &lb_attr_group,
+	.tuners = &lb_tuners,
+	.get_cpu_cdbs = get_cpu_cdbs,
+	.get_cpu_dbs_info_s = get_cpu_dbs_info_s,
+	.gov_dbs_timer = lb_dbs_timer,
+	.gov_check_cpu = lb_check_cpu,
+	.gov_ops = &lb_ops,
+};
+
+static int lb_cpufreq_governor_dbs(struct cpufreq_policy *policy,
+		unsigned int event)
+{
+	return cpufreq_governor_dbs(&lb_dbs_data, policy, event);
+}
+
+#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+static
+#endif
+struct cpufreq_governor cpufreq_gov_lab = {
+	.name			= "lab",
+	.governor		= lb_cpufreq_governor_dbs,
+	.max_transition_latency	= TRANSITION_LATENCY_LIMIT,
+	.owner			= THIS_MODULE,
+};
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+	u64 idle_time;
+	int i, cpu = get_cpu(), ret;
+
+	mutex_init(&lb_dbs_data.mutex);
+	idle_time = get_cpu_idle_time_us(cpu, NULL);
+	put_cpu();
+	if (idle_time != -1ULL) {
+		/* Idle micro accounting is supported. Use finer thresholds */
+		lb_tuners.up_threshold = MICRO_FREQUENCY_UP_THRESHOLD;
+		lb_tuners.down_differential = MICRO_FREQUENCY_DOWN_DIFFERENTIAL;
+		/*
+		 * In nohz/micro accounting case we set the minimum frequency
+		 * not depending on HZ, but fixed (very low). The deferred
+		 * timer might skip some samples if idle/sleeping as needed.
+		*/
+		lb_dbs_data.min_sampling_rate = MICRO_FREQUENCY_MIN_SAMPLE_RATE;
+	} else {
+		/* For correct statistics, we need 10 ticks for each measure */
+		lb_dbs_data.min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
+			jiffies_to_usecs(10);
+	}
+
+	/* Initialize arrays */
+	idle_avg = kzalloc(GFP_KERNEL,
+			num_possible_cpus() * sizeof(unsigned int));
+	idle_hist = kzalloc(GFP_KERNEL,
+			num_possible_cpus() * sizeof(unsigned int *));
+	for (i = 0; i < num_possible_cpus(); i++)
+		idle_hist[i] = kzalloc(GFP_KERNEL,
+					MAX_HIST * sizeof(unsigned int));
+
+	ret = cpufreq_register_notifier(&cpufreq_overclk_notifier_block,
+					CPUFREQ_POLICY_NOTIFIER);
+	if (ret) {
+		pr_err("CPUFREQ notifier not registered.\n");
+		return ret;
+	}
+
+	return cpufreq_register_governor(&cpufreq_gov_lab);
+}
+
+static void __exit cpufreq_gov_dbs_exit(void)
+{
+	int i;
+
+	if (!idle_avg)
+		kfree(idle_avg);
+	if (!idle_hist) {
+		for (i = 0; i < num_possible_cpus(); i++) {
+			if (!idle_hist[i])
+				kfree(idle_hist[i]);
+		}
+		kfree(idle_hist);
+	}
+
+	cpufreq_unregister_governor(&cpufreq_gov_lab);
+}
+
+MODULE_AUTHOR("Jonghwa Lee <jonghwa3.lee@samsung.com>");
+MODULE_AUTHOR("Lukasz Majewski <l.majewski@samsung.com>");
+MODULE_DESCRIPTION("'cpufreq_lab' - A dynamic cpufreq governor for "
+		"Legacy Application Boosting");
+MODULE_LICENSE("GPL");
+
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+fs_initcall(cpufreq_gov_dbs_init);
+#else
+module_init(cpufreq_gov_dbs_init);
+#endif
+module_exit(cpufreq_gov_dbs_exit);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 8c185d6..513f44f 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -411,6 +411,9 @@ extern struct cpufreq_governor cpufreq_gov_ondemand;
 #elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE)
 extern struct cpufreq_governor cpufreq_gov_conservative;
 #define CPUFREQ_DEFAULT_GOVERNOR	(&cpufreq_gov_conservative)
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_LAB)
+extern struct cpufreq_governor cpufreq_gov_lab;
+#define CPUFREQ_DEFAULT_GOVERNOR	(&cpufreq_gov_lab)
 #endif
 
 
-- 
1.7.9.5

[RFC v2 3/3] cpufreq:LAB: Modify cpufreq_governor to support LAB Governor

[Jonghwa Lee]

From: Lukasz Majewski <l.majewski@samsung.com>

Store idle_time information at newly created, per CPU struct lb_cpu_dbs_info_s
Moreover new governor #define - GOV_LAB has been added

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.c |    7 +++++++
 drivers/cpufreq/cpufreq_governor.h |   15 +++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 443442d..ab34edf 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -143,6 +143,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 			idle_time += jiffies_to_usecs(cur_nice_jiffies);
 		}
 
+		if (dbs_data->governor == GOV_LAB) {
+			struct lb_cpu_dbs_info_s *lb_dbs_info =
+				dbs_data->get_cpu_dbs_info_s(j);
+
+			lb_dbs_info->idle_time = (100 * idle_time) / wall_time;
+		}
+
 		if (unlikely(!wall_time || wall_time < idle_time))
 			continue;
 
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 8ac3353..6bf7dcb 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -163,6 +163,20 @@ struct cs_cpu_dbs_info_s {
 	unsigned int enable:1;
 };
 
+struct lb_cpu_dbs_info_s {
+	struct cpu_dbs_common_info cdbs;
+	u64 prev_cpu_iowait;
+	struct cpufreq_frequency_table *freq_table;
+	unsigned int freq_lo;
+	unsigned int freq_lo_jiffies;
+	unsigned int freq_hi_jiffies;
+	unsigned int rate_mult;
+	unsigned int sample_type:1;
+
+	unsigned int last_sampling_rate;
+	unsigned int idle_time;
+};
+
 /* Per policy Governers sysfs tunables */
 struct od_dbs_tuners {
 	unsigned int ignore_nice;
@@ -189,6 +203,7 @@ struct common_dbs_data {
 	/* Common across governors */
 	#define GOV_ONDEMAND		0
 	#define GOV_CONSERVATIVE	1
+	#define GOV_LAB			2
 	int governor;
 	struct attribute_group *attr_group_gov_sys; /* one governor - system */
 	struct attribute_group *attr_group_gov_pol; /* one governor - policy */
-- 
1.7.9.5

Re: [RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[Viresh Kumar]

On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:
> From: Lukasz Majewski <l.majewski@samsung.com>

> 2. New LAB governor.
> It calculates number of idle CPUs (based on scheduler data). On this basis it
> chose proper first level polynomial function for approximation.
> Moreover it enables overclocking when single, heavy loaded CPU is running.

Hi Lukasz,

I am still not sure about this governor. Do you have some results with which
you can tell how is it better than ondemand/conservative?

With or without overclocking. i.e. Apply only overclocking support to
ondemand/conservative..

If you are using Android, maybe check Interactive too (Though it itsn't
mainlined yet).

@Rafael: What do you think about this patchset?

--
viresh

Re: [RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[Lukasz Majewski]

Hi Viresh,

Thanks for reply.

> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:
> > From: Lukasz Majewski <l.majewski@samsung.com>
> 
> > 2. New LAB governor.
> > It calculates number of idle CPUs (based on scheduler data). On
> > this basis it chose proper first level polynomial function for
> > approximation. Moreover it enables overclocking when single, heavy
> > loaded CPU is running.
> 
> Hi Lukasz,
> 
> I am still not sure about this governor. Do you have some results
> with which you can tell how is it better than ondemand/conservative?

I will provide proper test results. As a test platform I've used
Exynos4 CPU (4 cores) with TIZEN OS on it.

> 
> With or without overclocking. i.e. Apply only overclocking support to
> ondemand/conservative..

I think, that overclocking support is crucial here. As you pointed out
- ondemand and conservative benefit from it. Therefore, I would urge
  for its mainline acceptance.

(code for reference)
http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq

In this RFC (patch 1/3), I've decided to put the burden of overclocking
support to platform code (cpufreq/exynos-cpufreq.c and
cpufreq/exynos4x12-cpufreq.c). 

Those changes aren't intrusive for other boards/archs. Moreover
overclocking is closely related to processor clocking/power dissipation
capabilities, so SoC specific code is a good place for it.


What DO need a broad acceptance is the overclocking API proposed at:
include/linux/cpufreq.h 

This introduces interface to which others will be bind. It shouldn't be
difficult to implement overclocking at other SoCs (as it was proposed
for Exynos).

Feedback is welcome, since I might have overlooked oddities present at
other SoCs.



> 
> If you are using Android, maybe check Interactive too (Though it
> itsn't mainlined yet).

I will also delve into "Interactive" governor.




As a side note:

The "core" cpufreq code modification (patch 3/3) counts only 22 lines,
so this patch series definitely is not intrusive.

> 
> @Rafael: What do you think about this patchset?
> 
> --
> viresh

-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[Viresh Kumar]

On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:

> I think, that overclocking support is crucial here. As you pointed out
> - ondemand and conservative benefit from it. Therefore, I would urge
>   for its mainline acceptance.
>
> (code for reference)
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> In this RFC (patch 1/3), I've decided to put the burden of overclocking
> support to platform code (cpufreq/exynos-cpufreq.c and
> cpufreq/exynos4x12-cpufreq.c).
>
> Those changes aren't intrusive for other boards/archs. Moreover
> overclocking is closely related to processor clocking/power dissipation
> capabilities, so SoC specific code is a good place for it.
>
>
> What DO need a broad acceptance is the overclocking API proposed at:
> include/linux/cpufreq.h
>
> This introduces interface to which others will be bind. It shouldn't be
> difficult to implement overclocking at other SoCs (as it was proposed
> for Exynos).
>
> Feedback is welcome, since I might have overlooked oddities present at
> other SoCs.

Hi..

I am not talking about the minute details here... for example I didn't like
the way overclocking support is implemented... It has to be a bit more
framework oriented then driver...

What I am thinking right now is if it is worth to add both the features
you are trying. i.e. overclocking and LAB..

So, requested you to give some figures... of ondemand with and without
overclocking... Leave LAB for now...

Then we can give LAB a try with above...

Re: [RFC v2 0/3] LAB: Support for Legacy Application Booster governor

[Lukasz Majewski]

Hi Viresh,

> On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:
> 
> > I think, that overclocking support is crucial here. As you pointed
> > out
> > - ondemand and conservative benefit from it. Therefore, I would urge
> >   for its mainline acceptance.
> >
> > (code for reference)
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > In this RFC (patch 1/3), I've decided to put the burden of
> > overclocking support to platform code (cpufreq/exynos-cpufreq.c and
> > cpufreq/exynos4x12-cpufreq.c).
> >
> > Those changes aren't intrusive for other boards/archs. Moreover
> > overclocking is closely related to processor clocking/power
> > dissipation capabilities, so SoC specific code is a good place for
> > it.
> >
> >
> > What DO need a broad acceptance is the overclocking API proposed at:
> > include/linux/cpufreq.h
> >
> > This introduces interface to which others will be bind. It
> > shouldn't be difficult to implement overclocking at other SoCs (as
> > it was proposed for Exynos).
> >
> > Feedback is welcome, since I might have overlooked oddities present
> > at other SoCs.
> 
> Hi..
> 
> I am not talking about the minute details here... for example I
> didn't like the way overclocking support is implemented... It has to
> be a bit more framework oriented then driver...

Presented implementation is only RFC. As I've written, I'm open for
suggestion.

> 
> What I am thinking right now is if it is worth to add both the
> features you are trying. i.e. overclocking and LAB..
> 
> So, requested you to give some figures... of ondemand with and without
> overclocking... 

I will provide test results for ondemand with overclocking enabled and
disabled. Thanks for clarification on this matter.

> Leave LAB for now...

Seems fair. One step on a time. Lets focus on overclocking.

> 
> Then we can give LAB a try with above...



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

Hi Viresh,

> On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:
> 
> > I think, that overclocking support is crucial here. As you pointed
> > out
> > - ondemand and conservative benefit from it. Therefore, I would urge
> >   for its mainline acceptance.
> >
> > (code for reference)
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > In this RFC (patch 1/3), I've decided to put the burden of
> > overclocking support to platform code (cpufreq/exynos-cpufreq.c and
> > cpufreq/exynos4x12-cpufreq.c).
> >
> > Those changes aren't intrusive for other boards/archs. Moreover
> > overclocking is closely related to processor clocking/power
> > dissipation capabilities, so SoC specific code is a good place for
> > it.
> >
> >
> > What DO need a broad acceptance is the overclocking API proposed at:
> > include/linux/cpufreq.h
> >
> > This introduces interface to which others will be bind. It
> > shouldn't be difficult to implement overclocking at other SoCs (as
> > it was proposed for Exynos).
> >
> > Feedback is welcome, since I might have overlooked oddities present
> > at other SoCs.
> 
> Hi..
> 
> I am not talking about the minute details here... for example I
> didn't like the way overclocking support is implemented... It has to
> be a bit more framework oriented then driver...
> 
> What I am thinking right now is if it is worth to add both the
> features you are trying. i.e. overclocking and LAB..
> 
> So, requested you to give some figures... of ondemand with and without
> overclocking... Leave LAB for now...
> 
> Then we can give LAB a try with above...

Test HW Exynos4412 (4 Cores):
Kernel 3.8.3

Ondemand max freq: 1.4 GHz
Overclock max freq: 1.5 GHz


Ondemand improvement with and without overclocking (called by us
TurboBoost - TB):

Dhrystone has been built according to:
http://zenit.senecac.on.ca/wiki/index.php/Dhrystone_howto
It's Makefile is also attached.
------------------------------------------------

Dhrystone	# of Threads			
		1	2	3	4
ondemand	2054794	2061855	2097902	2090592
ondemand + TB	2290076	2205882	2281368 2290076

Improvement:	10%	7%	8%	9%
-------------------------------------------------

Electric charge [C]
(Avg) [A] * [second]	# of Threads			
		1	2	3	4
ondemand	1,334	1,837	2,296	3,096
ondemand + TB	1,401	2,2025	2,907	4,34976
								
Power cost:	5%	17%	21%	29%
-------------------------------------------------

Execution time [second]	# of Threads			
		1	2	3	4
ondemand	2,827	2,8	2,787	2,872
ondemand + TB	2,622	2,694	2,667	2,76
				
				
Speedup:	-7%	-4%	-4%	-4%

-------------------------------------------------

"Real life" example:
time tar -czf linux-3.9.1.tar.gz linux-3.9.1/

		Avg current[mA]		Time[s]
Ondemand:	460			153	
Ondemand + TB:	512			144

Result:		+10%			-6%



Conclusion: 

The main use case for TB is to speed up execution of tasks packed to
one core. Other cores are then in IDLE state.

For a single core we can safely overclock, since we will not exceed its
power consumption and thermal limits.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 2180 bytes --]

#
#	Adjust for your system!
#
#	Common options for generic UNIX and Microsoft C (under DOS)
#	are listed here.  You can change them by switching the order,
#	placing the ones you want last.  Pay particular attention to
#	the HZ parameter, which may or may not be listed in some
#	header file on your system, such as <sys/param.h> or <limits.h>
#	(as CLK_TCK).  Even if it is listed, it may be incorrect.
#	Also, some operating systems (notably some (all?) versions
#	of Microport UNIX) lie about the time.  Sanity check with a
#	stopwatch.
#
#	For Microsoft C under DOS, you need a real make, not MSC make,
#	to run this Makefile.  The public domain "ndmake" will suffice.
#
CC=		cl			# C compiler name goes here (MSC)
CC=		cc			# C compiler name goes here (UNIX)
GCC=		arm-gcc

PROGS=		unix			# Programs to build (UNIX)

#TIME_FUNC=	-DMSC_CLOCK		# Use Microsoft clock() for measurement
#TIME_FUNC=	-DTIME			# Use time(2) for measurement
TIME_FUNC=	-DTIMES			# Use times(2) for measurement
#HZ=		50			# Frequency of times(2) clock ticks
HZ=		60			# Frequency of times(2) clock ticks
#HZ=		100			# Frequency of times(2) clock ticks
#HZ=		1			# Give bogus result unless changed!

STRUCTASSIGN=	-DNOSTRUCTASSIGN	# Compiler cannot assign structs
STRUCTASSIGN=				# Compiler can assign structs

ENUMS=		-DNOENUMS		# Compiler doesn't have enum type
ENUMS=					# Compiler does have enum type

OPTIMIZE=	-Ox -G2			# Optimization Level (MSC, 80286)
OPTIMIZE=	-O4			# Optimization Level (generic UNIX)
GCCOPTIM=       -O

LFLAGS=					#Loader Flags

CFLAGS=	$(OPTIMIZE) $(TIME_FUNC) -DHZ=$(HZ) $(ENUMS) $(STRUCTASSIGN) $(CFL)
GCCFLAGS= $(GCCOPTIM) $(TIME_FUNC) -DHZ=$(HZ) $(ENUMS) $(STRUCTASSIGN) $(CFL)

#
#		You shouldn't need to touch the rest
#
SRC=		dhry_1.c dhry_2.c
HDR=		dhry.h

UNIX_PROGS=	gcc_dry2 gcc_dry2reg

# Files added by rer:
FILES1=		README.RER clarify.doc Makefile submit.frm pure2_1.dif \
		dhry_c.dif
# Reinhold's files:
FILES2=		README RATIONALE $(HDR) $(SRC)
FILES3=		dhry.p

all:	$(PROGS)

unix:	$(UNIX_PROGS)

gcc_dry2:		$(SRC) $(HDR)
		$(GCC) $(GCCFLAGS) $(SRC) $(LFLAGS) -o $@

gcc_dry2reg:	$(SRC) $(HDR)
		$(GCC) $(GCCFLAGS) -DREG=register $(SRC) $(LFLAGS) -o $@

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> 
> > On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com>
> > >> wrote:
> > 
> > > I think, that overclocking support is crucial here. As you pointed
> > > out
> > > - ondemand and conservative benefit from it. Therefore, I would
> > > urge for its mainline acceptance.
> > >
> > > (code for reference)
> > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >
> > > In this RFC (patch 1/3), I've decided to put the burden of
> > > overclocking support to platform code (cpufreq/exynos-cpufreq.c
> > > and cpufreq/exynos4x12-cpufreq.c).
> > >
> > > Those changes aren't intrusive for other boards/archs. Moreover
> > > overclocking is closely related to processor clocking/power
> > > dissipation capabilities, so SoC specific code is a good place for
> > > it.
> > >
> > >
> > > What DO need a broad acceptance is the overclocking API proposed
> > > at: include/linux/cpufreq.h
> > >
> > > This introduces interface to which others will be bind. It
> > > shouldn't be difficult to implement overclocking at other SoCs (as
> > > it was proposed for Exynos).
> > >
> > > Feedback is welcome, since I might have overlooked oddities
> > > present at other SoCs.
> > 
> > Hi..
> > 
> > I am not talking about the minute details here... for example I
> > didn't like the way overclocking support is implemented... It has to
> > be a bit more framework oriented then driver...
> > 
> > What I am thinking right now is if it is worth to add both the
> > features you are trying. i.e. overclocking and LAB..
> > 
> > So, requested you to give some figures... of ondemand with and
> > without overclocking... Leave LAB for now...

As you wished, I've provided relevant data for overclocking.

Would you be so kind and comment on them?



> > 
> > Then we can give LAB a try with above...
> 
> Test HW Exynos4412 (4 Cores):
> Kernel 3.8.3
> 
> Ondemand max freq: 1.4 GHz
> Overclock max freq: 1.5 GHz
> 
> 
> Ondemand improvement with and without overclocking (called by us
> TurboBoost - TB):
> 
> Dhrystone has been built according to:
> http://zenit.senecac.on.ca/wiki/index.php/Dhrystone_howto
> It's Makefile is also attached.
> ------------------------------------------------
> 
> Dhrystone	# of Threads			
> 		1	2	3	4
> ondemand	2054794	2061855	2097902	2090592
> ondemand + TB	2290076	2205882	2281368 2290076
> 
> Improvement:	10%	7%	8%	9%
> -------------------------------------------------
> 
> Electric charge [C]
> (Avg) [A] * [second]	# of Threads			
> 		1	2	3	4
> ondemand	1,334	1,837	2,296	3,096
> ondemand + TB	1,401	2,2025	2,907	4,34976
> 								
> Power cost:	5%	17%	21%	29%
> -------------------------------------------------
> 
> Execution time [second]	# of Threads			
> 		1	2	3	4
> ondemand	2,827	2,8	2,787	2,872
> ondemand + TB	2,622	2,694	2,667	2,76
> 				
> 				
> Speedup:	-7%	-4%	-4%	-4%
> 
> -------------------------------------------------
> 
> "Real life" example:
> time tar -czf linux-3.9.1.tar.gz linux-3.9.1/
> 
> 		Avg current[mA]		Time[s]
> Ondemand:	460			153	
> Ondemand + TB:	512			144
> 
> Result:		+10%			-6%
> 
> 
> 
> Conclusion: 
> 
> The main use case for TB is to speed up execution of tasks packed to
> one core. Other cores are then in IDLE state.
> 
> For a single core we can safely overclock, since we will not exceed
> its power consumption and thermal limits.
> 
> 


-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 24 May 2013 11:26, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> > On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com>
> As you wished, I've provided relevant data for overclocking.
>
> Would you be so kind and comment on them?

I was about to reply ... was busy with some other backlog :)

>> Test HW Exynos4412 (4 Cores):
>> Kernel 3.8.3
>>
>> Ondemand max freq: 1.4 GHz
>> Overclock max freq: 1.5 GHz
>>
>>
>> Ondemand improvement with and without overclocking (called by us
>> TurboBoost - TB):
>>
>> Dhrystone has been built according to:
>> http://zenit.senecac.on.ca/wiki/index.php/Dhrystone_howto
>> It's Makefile is also attached.
>> ------------------------------------------------
>>
>> Dhrystone     # of Threads
>>               1       2       3       4
>> ondemand      2054794 2061855 2097902 2090592
>> ondemand + TB 2290076 2205882 2281368 2290076
>>
>> Improvement:  10%     7%      8%      9%
>> -------------------------------------------------
>>
>> Electric charge [C]
>> (Avg) [A] * [second]  # of Threads
>>               1       2       3       4
>> ondemand      1,334   1,837   2,296   3,096
>> ondemand + TB 1,401   2,2025  2,907   4,34976
>>
>> Power cost:   5%      17%     21%     29%
>> -------------------------------------------------
>>
>> Execution time [second]       # of Threads
>>               1       2       3       4
>> ondemand      2,827   2,8     2,787   2,872
>> ondemand + TB 2,622   2,694   2,667   2,76
>>
>>
>> Speedup:      -7%     -4%     -4%     -4%
>>
>> -------------------------------------------------
>>
>> "Real life" example:
>> time tar -czf linux-3.9.1.tar.gz linux-3.9.1/
>>
>>               Avg current[mA]         Time[s]
>> Ondemand:     460                     153
>> Ondemand + TB:        512                     144
>>
>> Result:               +10%                    -6%
>>
>> Conclusion:
>>
>> The main use case for TB is to speed up execution of tasks packed to
>> one core. Other cores are then in IDLE state.
>>
>> For a single core we can safely overclock, since we will not exceed
>> its power consumption and thermal limits.

Hmm... So its ultraclear that higher clock rates have given us better
performance numbers, obviously at the cost of power.

Now, why don't we simply add this high end frequency in the available
frequencies list? And then ondemand can set it whenever the load is
high? Why do we need additional core support for it?

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> On 24 May 2013 11:26, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> > On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com>
> > As you wished, I've provided relevant data for overclocking.
> >
> > Would you be so kind and comment on them?
> 
> I was about to reply ... was busy with some other backlog :)
> 
> >> Test HW Exynos4412 (4 Cores):
> >> Kernel 3.8.3
> >>
> >> Ondemand max freq: 1.4 GHz
> >> Overclock max freq: 1.5 GHz
> >>
> >>
> >> Ondemand improvement with and without overclocking (called by us
> >> TurboBoost - TB):
> >>
> >> Dhrystone has been built according to:
> >> http://zenit.senecac.on.ca/wiki/index.php/Dhrystone_howto
> >> It's Makefile is also attached.
> >> ------------------------------------------------
> >>
> >> Dhrystone     # of Threads
> >>               1       2       3       4
> >> ondemand      2054794 2061855 2097902 2090592
> >> ondemand + TB 2290076 2205882 2281368 2290076
> >>
> >> Improvement:  10%     7%      8%      9%
> >> -------------------------------------------------
> >>
> >> Electric charge [C]
> >> (Avg) [A] * [second]  # of Threads
> >>               1       2       3       4
> >> ondemand      1,334   1,837   2,296   3,096
> >> ondemand + TB 1,401   2,2025  2,907   4,34976
> >>
> >> Power cost:   5%      17%     21%     29%
> >> -------------------------------------------------
> >>
> >> Execution time [second]       # of Threads
> >>               1       2       3       4
> >> ondemand      2,827   2,8     2,787   2,872
> >> ondemand + TB 2,622   2,694   2,667   2,76
> >>
> >>
> >> Speedup:      -7%     -4%     -4%     -4%
> >>
> >> -------------------------------------------------
> >>
> >> "Real life" example:
> >> time tar -czf linux-3.9.1.tar.gz linux-3.9.1/
> >>
> >>               Avg current[mA]         Time[s]
> >> Ondemand:     460                     153
> >> Ondemand + TB:        512                     144
> >>
> >> Result:               +10%                    -6%
> >>
> >> Conclusion:
> >>
> >> The main use case for TB is to speed up execution of tasks packed
> >> to one core. Other cores are then in IDLE state.
> >>
> >> For a single core we can safely overclock, since we will not exceed
> >> its power consumption and thermal limits.
> 
> Hmm... So its ultraclear that higher clock rates have given us better
> performance numbers, obviously at the cost of power.

Yep, no magic here.

> 
> Now, why don't we simply add this high end frequency in the available
> frequencies list? And then ondemand can set it whenever the load is
> high? Why do we need additional core support for it?

The overclock frequency (1.5 GHz) is possible to set as an ordinary,
available frequency (policy->max) for ondemand. 

Unfortunately with our load patterns, this frequency rapidly increases
internal chip temperature (chip goes out of available power/thermal
dissipation range), and consumes extra power when not needed. 

The core idea with overclock is to increase ("boost") the frequency
when conditions allow to do it (for example load is affined to a single
core, other are idle). Then we will not exceed power/thermal budget, but
increase performance (and even save power).


Overclocking is efficiently utilized by LAB, which relies on a number of
idle cpus. Thus, we can easily asses if we can enable it. 

I also foresee potential use of overclocking, when scheduler will take a
major role of power saver for mobile (ARM) linux. Since it will try to
pack as much tasks as possible to a single core - it will need a
framework/API to "boost" their execution.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> The overclock frequency (1.5 GHz) is possible to set as an ordinary,
> available frequency (policy->max) for ondemand.
>
> Unfortunately with our load patterns, this frequency rapidly increases
> internal chip temperature (chip goes out of available power/thermal
> dissipation range), and consumes extra power when not needed.
>
> The core idea with overclock is to increase ("boost") the frequency
> when conditions allow to do it (for example load is affined to a single
> core, other are idle). Then we will not exceed power/thermal budget, but
> increase performance (and even save power).
>
>
> Overclocking is efficiently utilized by LAB, which relies on a number of
> idle cpus. Thus, we can easily asses if we can enable it.
>
> I also foresee potential use of overclocking, when scheduler will take a
> major role of power saver for mobile (ARM) linux. Since it will try to
> pack as much tasks as possible to a single core - it will need a
> framework/API to "boost" their execution.

Okay.. so its exactly what I thought the reason would be.

What I would have done if I was in your place is:

Add following sysfs tunables to ondemand governor:

- overdrive_freq: We will go over this frequency only when
number of busy cores is <= overdrive_cores..
For your case it will be 1.4 GHz

- overdrive_cores: We will enable overdrive frequencies only if no. of
busy cores is <= overdrive_cores. Zero by default (So, that this feature
is disabled by default) and 1 for your case.

And your driver will include all the available frequencies in the freq
table.

I hope this will be the most generic solution to your problem..

What do you say?

--
viresh

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Daniel Lezcano]

On 05/24/2013 10:51 AM, Viresh Kumar wrote:
> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> The overclock frequency (1.5 GHz) is possible to set as an ordinary,
>> available frequency (policy->max) for ondemand.
>>
>> Unfortunately with our load patterns, this frequency rapidly increases
>> internal chip temperature (chip goes out of available power/thermal
>> dissipation range), and consumes extra power when not needed.
>>
>> The core idea with overclock is to increase ("boost") the frequency
>> when conditions allow to do it (for example load is affined to a single
>> core, other are idle). Then we will not exceed power/thermal budget, but
>> increase performance (and even save power).
>>
>>
>> Overclocking is efficiently utilized by LAB, which relies on a number of
>> idle cpus. Thus, we can easily asses if we can enable it.
>>
>> I also foresee potential use of overclocking, when scheduler will take a
>> major role of power saver for mobile (ARM) linux. Since it will try to
>> pack as much tasks as possible to a single core - it will need a
>> framework/API to "boost" their execution.
> 
> Okay.. so its exactly what I thought the reason would be.
> 
> What I would have done if I was in your place is:
> 
> Add following sysfs tunables to ondemand governor:
> 
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
> 
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this feature
> is disabled by default) and 1 for your case.
> 
> And your driver will include all the available frequencies in the freq
> table.
> 
> I hope this will be the most generic solution to your problem..

I agree with Viresh, a new governor is not necessary here for that.

There is the /sys/devices/system/cpufreq/boost option existing for x86
platform, why do not reuse it ? It is supposed to do exactly what you
want to achieve.

IMO, the logic of boosting one core when the other are idle should be in
the driver itself and certainly not setup by the user, except if we
consider acceptable the user can burn its board ... :)

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Daniel Lezcano]

On 05/24/2013 10:51 AM, Viresh Kumar wrote:
> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> The overclock frequency (1.5 GHz) is possible to set as an ordinary,
>> available frequency (policy->max) for ondemand.
>>
>> Unfortunately with our load patterns, this frequency rapidly increases
>> internal chip temperature (chip goes out of available power/thermal
>> dissipation range), and consumes extra power when not needed.
>>
>> The core idea with overclock is to increase ("boost") the frequency
>> when conditions allow to do it (for example load is affined to a single
>> core, other are idle). Then we will not exceed power/thermal budget, but
>> increase performance (and even save power).
>>
>>
>> Overclocking is efficiently utilized by LAB, which relies on a number of
>> idle cpus. Thus, we can easily asses if we can enable it.
>>
>> I also foresee potential use of overclocking, when scheduler will take a
>> major role of power saver for mobile (ARM) linux. Since it will try to
>> pack as much tasks as possible to a single core - it will need a
>> framework/API to "boost" their execution.
> 
> Okay.. so its exactly what I thought the reason would be.
> 
> What I would have done if I was in your place is:
> 
> Add following sysfs tunables to ondemand governor:
> 
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
> 
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this feature
> is disabled by default) and 1 for your case.
> 
> And your driver will include all the available frequencies in the freq
> table.
> 
> I hope this will be the most generic solution to your problem..

I agree with Viresh, a new governor is not necessary here for that.

There is the /sys/devices/system/cpufreq/boost option existing for x86
platform, why do not reuse it ? It is supposed to do exactly what you
want to achieve.

IMO, the logic of boosting one core when the other are idle should be in
the driver itself and certainly not setup by the user, except if we
consider acceptable the user can burn its board ... :)

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> I agree with Viresh, a new governor is not necessary here for that.

Their patchset had two parts.. One is LAB and other is overclocking.
We are trying to solve overclocking for which they never wanted a
new governor. :)

> There is the /sys/devices/system/cpufreq/boost option existing for x86
> platform, why do not reuse it ? It is supposed to do exactly what you
> want to achieve.

The problem is that it was added at the wrong place.. It should have
been at cpu/cpuX/cpufreq/boost...

Consider how will we achieve it for big LITTLE.. We know we can
go to overdrive only for a single core in big but for two cores in
LITTLE at the same time.. So, we need that in the location I just
mentioned...

Over that.. I believe it is governor specific too.. It shouldn't be part
of conservative as it should be conservative rather then aggressive :)

> IMO, the logic of boosting one core when the other are idle should be in
> the driver itself and certainly not setup by the user, except if we
> consider acceptable the user can burn its board ... :)

I didn't get it completely.. So, with the options I gave user can only
say.. boost if required and only when few cores are active. User
can't just set max freq continuously if he wishes..

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Daniel Lezcano]

On 05/24/2013 11:13 AM, Viresh Kumar wrote:
> On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> I agree with Viresh, a new governor is not necessary here for that.
> 
> Their patchset had two parts.. One is LAB and other is overclocking.
> We are trying to solve overclocking for which they never wanted a
> new governor. :)
> 
>> There is the /sys/devices/system/cpufreq/boost option existing for x86
>> platform, why do not reuse it ? It is supposed to do exactly what you
>> want to achieve.
> 
> The problem is that it was added at the wrong place.. It should have
> been at cpu/cpuX/cpufreq/boost...

Yes, I saw in the commit log (615b7300717b9ad5c23d1f391843484fe30f6c12),
that should be done.

> Consider how will we achieve it for big LITTLE.. We know we can
> go to overdrive only for a single core in big but for two cores in
> LITTLE at the same time.. So, we need that in the location I just
> mentioned...

I thought the constraints should be hardcoded in the driver and only one
option is exposed to the userspace. If the user sets
ondemand|performance + boost, then the exynos's or b.L's drivers know
when they can go to boost (1x core, 1x big core, 2x little core, ...).

> Over that.. I believe it is governor specific too.. It shouldn't be part
> of conservative as it should be conservative rather then aggressive :)

Yes, it is part of the governor policy and maybe that could fall in the
common cpufreq framework.

>> IMO, the logic of boosting one core when the other are idle should be in
>> the driver itself and certainly not setup by the user, except if we
>> consider acceptable the user can burn its board ... :)
> 
> I didn't get it completely.. So, with the options I gave user can only
> say.. boost if required and only when few cores are active. User
> can't just set max freq continuously if he wishes..

Ok, may be I misunderstood. You suggested to define 'overdrive_cores'
where the user can setup when to overdrive a core. If the user set an
incorrect value, IIUC, the thermal value can go beyond the thermal limit
and break the board. I am just worried this option is dangerous.




-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Daniel Lezcano]

On 05/24/2013 11:13 AM, Viresh Kumar wrote:
> On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> I agree with Viresh, a new governor is not necessary here for that.
> 
> Their patchset had two parts.. One is LAB and other is overclocking.
> We are trying to solve overclocking for which they never wanted a
> new governor. :)
> 
>> There is the /sys/devices/system/cpufreq/boost option existing for x86
>> platform, why do not reuse it ? It is supposed to do exactly what you
>> want to achieve.
> 
> The problem is that it was added at the wrong place.. It should have
> been at cpu/cpuX/cpufreq/boost...

Yes, I saw in the commit log (615b7300717b9ad5c23d1f391843484fe30f6c12),
that should be done.

> Consider how will we achieve it for big LITTLE.. We know we can
> go to overdrive only for a single core in big but for two cores in
> LITTLE at the same time.. So, we need that in the location I just
> mentioned...

I thought the constraints should be hardcoded in the driver and only one
option is exposed to the userspace. If the user sets
ondemand|performance + boost, then the exynos's or b.L's drivers know
when they can go to boost (1x core, 1x big core, 2x little core, ...).

> Over that.. I believe it is governor specific too.. It shouldn't be part
> of conservative as it should be conservative rather then aggressive :)

Yes, it is part of the governor policy and maybe that could fall in the
common cpufreq framework.

>> IMO, the logic of boosting one core when the other are idle should be in
>> the driver itself and certainly not setup by the user, except if we
>> consider acceptable the user can burn its board ... :)
> 
> I didn't get it completely.. So, with the options I gave user can only
> say.. boost if required and only when few cores are active. User
> can't just set max freq continuously if he wishes..

Ok, may be I misunderstood. You suggested to define 'overdrive_cores'
where the user can setup when to overdrive a core. If the user set an
incorrect value, IIUC, the thermal value can go beyond the thermal limit
and break the board. I am just worried this option is dangerous.




-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 24 May 2013 15:58, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 05/24/2013 11:13 AM, Viresh Kumar wrote:

>> Consider how will we achieve it for big LITTLE.. We know we can
>> go to overdrive only for a single core in big but for two cores in
>> LITTLE at the same time.. So, we need that in the location I just
>> mentioned...
>
> I thought the constraints should be hardcoded in the driver and only one
> option is exposed to the userspace. If the user sets
> ondemand|performance + boost, then the exynos's or b.L's drivers know
> when they can go to boost (1x core, 1x big core, 2x little core, ...).

Cpufreq Drivers don't take a decision on cpu frequency. They just provide
a mechanism to cpufreq core.. Decision must come from governor all the
time.

>> I didn't get it completely.. So, with the options I gave user can only
>> say.. boost if required and only when few cores are active. User
>> can't just set max freq continuously if he wishes..
>
> Ok, may be I misunderstood. You suggested to define 'overdrive_cores'
> where the user can setup when to overdrive a core. If the user set an
> incorrect value, IIUC, the thermal value can go beyond the thermal limit
> and break the board. I am just worried this option is dangerous.

Yes.. if we set 4 at that place.. 4 cores may run together in overdrive
mode. And that is risky :) ... Maybe a max limit from driver will be another
option along with this.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > The overclock frequency (1.5 GHz) is possible to set as an ordinary,
> > available frequency (policy->max) for ondemand.
> >
> > Unfortunately with our load patterns, this frequency rapidly
> > increases internal chip temperature (chip goes out of available
> > power/thermal dissipation range), and consumes extra power when not
> > needed.
> >
> > The core idea with overclock is to increase ("boost") the frequency
> > when conditions allow to do it (for example load is affined to a
> > single core, other are idle). Then we will not exceed power/thermal
> > budget, but increase performance (and even save power).
> >
> >
> > Overclocking is efficiently utilized by LAB, which relies on a
> > number of idle cpus. Thus, we can easily asses if we can enable it.
> >
> > I also foresee potential use of overclocking, when scheduler will
> > take a major role of power saver for mobile (ARM) linux. Since it
> > will try to pack as much tasks as possible to a single core - it
> > will need a framework/API to "boost" their execution.
> 
> Okay.. so its exactly what I thought the reason would be.
> 
> What I would have done if I was in your place is:
> 
> Add following sysfs tunables to ondemand governor:
> 
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
> 
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this
> feature is disabled by default) and 1 for your case.
> 
> And your driver will include all the available frequencies in the freq
> table.

This is not safe IMHO to add permanently overclocked frequency to the
freq table. Since, for example, thermal framework also asks for
reference to this table. 

The idea beneath overclocking is to add "dangerous" frequency to the
frequency table only when necessary (and remove it when not needed). 

In this way, the thermal framework (as it is done at our platform) will
decrease the frequency (according to thermal governor :-) ) to safe
level.



Overclocking is disabled in 2 ways (at our setup): 
- thermal framework is here to help us
- lab governor disables the overclocking when favorable conditions are
  gone.

One more remark - enabling tb_en_over_clk at sysfs (echo 1
> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
adds overclock frequency to frequency table and updates policy. 

It doesn't switch frequency to overclock value. This switching is done
only when proper conditions are in place (in ondemand or LAB). 

> 
> I hope this will be the most generic solution to your problem..
> 
> What do you say?

Another issue is the current ondemand implementation:

It choose the highest load of all running cpus. This is not optimal in
terms of power consumption at multicore SoCs.

This is the ondemand legacy API (lb_check_cpu(int cpu, unsigned int
load_freq)).

I'm afraid, that ondemand would get polluted by the attempt to
implement LAB's logic into it.

In the end we would have "ondemand", which based on a runtime flag
value uses maximal load of a single processor, or counts number of
idle cpus (and filter them) to switch frequency.

To avoid such clash, we have decided to develop new governor with
minimal changes to core.

Such approach keeps logic clear.



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org>
> wrote:
> > I agree with Viresh, a new governor is not necessary here for that.
> 
> Their patchset had two parts.. One is LAB and other is overclocking.
> We are trying to solve overclocking for which they never wanted a
> new governor. :)

Overclocking can be uses as a standalone feature. However it is crucial
for effective LAB operation.

> 
> > There is the /sys/devices/system/cpufreq/boost option existing for
> > x86 platform, why do not reuse it ? It is supposed to do exactly
> > what you want to achieve.
> 
> The problem is that it was added at the wrong place.. It should have
> been at cpu/cpuX/cpufreq/boost...
> 
> Consider how will we achieve it for big LITTLE.. We know we can
> go to overdrive only for a single core in big but for two cores in
> LITTLE at the same time.. So, we need that in the location I just
> mentioned...

I think that power/thermal envelope here is a key. We can overclock as
many cores as we want if we don't exceed limits :-)

Scheduler assignment of tasks to cores and core type decision on which
it would run is a different story for b.L. 

> 
> Over that.. I believe it is governor specific too.. It shouldn't be
> part of conservative as it should be conservative rather then
> aggressive :)
> 
> > IMO, the logic of boosting one core when the other are idle should
> > be in the driver itself and certainly not setup by the user, except
> > if we consider acceptable the user can burn its board ... :)

Sysfs entry can be read only and governor code can be responsible for
enabling overclocking.

Overclocking patch provides API implemented at cpufreq.h file to allow
in-kernel overclocking.

> 
> I didn't get it completely.. So, with the options I gave user can only
> say.. boost if required and only when few cores are active. User
> can't just set max freq continuously if he wishes..



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 24 May 2013 16:50, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:

> This is not safe IMHO to add permanently overclocked frequency to the
> freq table. Since, for example, thermal framework also asks for
> reference to this table.

Yes, its wrong. Even adding it permanently this way would be a problem
if governor is changed to performance. :)

> The idea beneath overclocking is to add "dangerous" frequency to the
> frequency table only when necessary (and remove it when not needed).

Hmm.. probably the idea beneath is to use dangerous frequency only
when we are assured that we will not break system.. It doesn't have
anything to do with cpufreq table entries :)

> In this way, the thermal framework (as it is done at our platform) will
> decrease the frequency (according to thermal governor :-) ) to safe
> level.
>
> Overclocking is disabled in 2 ways (at our setup):
> - thermal framework is here to help us
> - lab governor disables the overclocking when favorable conditions are
>   gone.

I don't want to discuss OR think about LAB for now.. Want to get
overclocking feature in first.

> One more remark - enabling tb_en_over_clk at sysfs (echo 1
>> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
> adds overclock frequency to frequency table and updates policy.

What if it is enabled and governor is changed to performance
without disabling it... Who will take care of disabling dangerous
frequencies?

One thing I am certain about is to make overclocking a generic and
core feature, rather than platform specific...

What about adding overdrive frequencies in freq table permanently
but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ??

This way we will use frequencies marked with
CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking
enabled. And not at other times?

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> On 24 May 2013 16:50, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com>
> >> wrote:
> 
> > This is not safe IMHO to add permanently overclocked frequency to
> > the freq table. Since, for example, thermal framework also asks for
> > reference to this table.
> 
> Yes, its wrong. Even adding it permanently this way would be a problem
> if governor is changed to performance. :)
> 
> > The idea beneath overclocking is to add "dangerous" frequency to the
> > frequency table only when necessary (and remove it when not needed).
> 
> Hmm.. probably the idea beneath is to use dangerous frequency only
> when we are assured that we will not break system.. 

Exactly, this is the idea.

> It doesn't have
> anything to do with cpufreq table entries :)
> 
> > In this way, the thermal framework (as it is done at our platform)
> > will decrease the frequency (according to thermal governor :-) ) to
> > safe level.
> >
> > Overclocking is disabled in 2 ways (at our setup):
> > - thermal framework is here to help us
> > - lab governor disables the overclocking when favorable conditions
> > are gone.
> 
> I don't want to discuss OR think about LAB for now.. Want to get
> overclocking feature in first.
> 
> > One more remark - enabling tb_en_over_clk at sysfs (echo 1
> >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
> > adds overclock frequency to frequency table and updates policy.
> 
> What if it is enabled and governor is changed to performance
> without disabling it... Who will take care of disabling dangerous
> frequencies?

So we could disable overclocking by default when policy is changed, or
when we remove governor (at cpufreq_unregister_governor()).

> 
> One thing I am certain about is to make overclocking a generic and
> core feature, rather than platform specific...

Ok, I see your point. I will prepare appropriate patches to rewrite
overclocking as a generic framework.

> 
> What about adding overdrive frequencies in freq table permanently
> but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ??
> 
> This way we will use frequencies marked with
> CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking
> enabled. And not at other times?

It seems to be a good idea. In this way we could solve some other
problems as well (like specifying not single overclocked frequency,
make sysfs entries read only).

As I've stated above, I will prepare only overclocking patches, with
new generic approach.



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Rafael J. Wysocki]

On Monday, May 27, 2013 11:03:38 AM Viresh Kumar wrote:
> On 24 May 2013 16:50, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
> 
> > This is not safe IMHO to add permanently overclocked frequency to the
> > freq table. Since, for example, thermal framework also asks for
> > reference to this table.
> 
> Yes, its wrong. Even adding it permanently this way would be a problem
> if governor is changed to performance. :)
> 
> > The idea beneath overclocking is to add "dangerous" frequency to the
> > frequency table only when necessary (and remove it when not needed).
> 
> Hmm.. probably the idea beneath is to use dangerous frequency only
> when we are assured that we will not break system.. It doesn't have
> anything to do with cpufreq table entries :)
> 
> > In this way, the thermal framework (as it is done at our platform) will
> > decrease the frequency (according to thermal governor :-) ) to safe
> > level.
> >
> > Overclocking is disabled in 2 ways (at our setup):
> > - thermal framework is here to help us
> > - lab governor disables the overclocking when favorable conditions are
> >   gone.
> 
> I don't want to discuss OR think about LAB for now.. Want to get
> overclocking feature in first.
> 
> > One more remark - enabling tb_en_over_clk at sysfs (echo 1
> >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
> > adds overclock frequency to frequency table and updates policy.
> 
> What if it is enabled and governor is changed to performance
> without disabling it... Who will take care of disabling dangerous
> frequencies?
> 
> One thing I am certain about is to make overclocking a generic and
> core feature, rather than platform specific...
> 
> What about adding overdrive frequencies in freq table permanently
> but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ??
> 
> This way we will use frequencies marked with
> CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking
> enabled. And not at other times?

Well, this really looks like software turbo modes, so let's call them
"TURBO" instead of "OVERDRIVE" and I seem to remember having a switch for
disabling/enabling turbo modes already.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Rafael,

> On Monday, May 27, 2013 11:03:38 AM Viresh Kumar wrote:
> > On 24 May 2013 16:50, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com>
> > >> wrote:
> > 
> > > This is not safe IMHO to add permanently overclocked frequency to
> > > the freq table. Since, for example, thermal framework also asks
> > > for reference to this table.
> > 
> > Yes, its wrong. Even adding it permanently this way would be a
> > problem if governor is changed to performance. :)
> > 
> > > The idea beneath overclocking is to add "dangerous" frequency to
> > > the frequency table only when necessary (and remove it when not
> > > needed).
> > 
> > Hmm.. probably the idea beneath is to use dangerous frequency only
> > when we are assured that we will not break system.. It doesn't have
> > anything to do with cpufreq table entries :)
> > 
> > > In this way, the thermal framework (as it is done at our
> > > platform) will decrease the frequency (according to thermal
> > > governor :-) ) to safe level.
> > >
> > > Overclocking is disabled in 2 ways (at our setup):
> > > - thermal framework is here to help us
> > > - lab governor disables the overclocking when favorable
> > > conditions are gone.
> > 
> > I don't want to discuss OR think about LAB for now.. Want to get
> > overclocking feature in first.
> > 
> > > One more remark - enabling tb_en_over_clk at sysfs (echo 1
> > >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
> > > adds overclock frequency to frequency table and updates policy.
> > 
> > What if it is enabled and governor is changed to performance
> > without disabling it... Who will take care of disabling dangerous
> > frequencies?
> > 
> > One thing I am certain about is to make overclocking a generic and
> > core feature, rather than platform specific...
> > 
> > What about adding overdrive frequencies in freq table permanently
> > but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ??
> > 
> > This way we will use frequencies marked with
> > CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking
> > enabled. And not at other times?
> 
> Well, this really looks like software turbo modes, so let's call them
> "TURBO" instead of "OVERDRIVE" and I seem to remember having a switch
> for disabling/enabling turbo modes already.

Indeed, overclocking is a software implemented TURBO mode. I can stick
to CPUFREQ_ENTRY_TURBO name.

I will check the disable/enable flag. Thanks for pointing out.

> 
> Thanks,
> Rafael
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Well, this really looks like software turbo modes, so let's call them
> "TURBO" instead of "OVERDRIVE"

Yes, it looks better.

> and I seem to remember having a switch for
> disabling/enabling turbo modes already.

This was added in intel_pstate driver and shows up in
/sys/devices/system/cpu/cpufreq/ directory..

But this feature belongs to a governor instance and so
will be present inside governor directory..

Specially for big LITTLE we want it to be per policy
specific. So may need to add a new one.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Rafael J. Wysocki]

On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Well, this really looks like software turbo modes, so let's call them
> > "TURBO" instead of "OVERDRIVE"
> 
> Yes, it looks better.
> 
> > and I seem to remember having a switch for
> > disabling/enabling turbo modes already.
> 
> This was added in intel_pstate driver and shows up in
> /sys/devices/system/cpu/cpufreq/ directory..
> 
> But this feature belongs to a governor instance and so
> will be present inside governor directory..
> 
> Specially for big LITTLE we want it to be per policy
> specific. So may need to add a new one.

I was talking about /sys/devices/system/cpu/cpufreq/boost that appears to
have been added by commit 615b730 (acpi-cpufreq: Add support for disabling
dynamic overclocking).

That's in acpi-cpufreq, but since that setting seems to be generally useful,
it may be a good idea to move it to the core somehow.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Rafael,

> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > Well, this really looks like software turbo modes, so let's call
> > > them "TURBO" instead of "OVERDRIVE"
> > 
> > Yes, it looks better.
> > 
> > > and I seem to remember having a switch for
> > > disabling/enabling turbo modes already.
> > 
> > This was added in intel_pstate driver and shows up in
> > /sys/devices/system/cpu/cpufreq/ directory..
> > 
> > But this feature belongs to a governor instance and so
> > will be present inside governor directory..
> > 
> > Specially for big LITTLE we want it to be per policy
> > specific. So may need to add a new one.
> 
> I was talking about /sys/devices/system/cpu/cpufreq/boost that
> appears to have been added by commit 615b730 (acpi-cpufreq: Add
> support for disabling dynamic overclocking).
> 
> That's in acpi-cpufreq, but since that setting seems to be generally
> useful, it may be a good idea to move it to the core somehow.

I think that Viresh wanted to add "boost" option to 
/sys/devices/system/cpu/cpuX/cpufreq/ to be able to control boost
at separate cores (policies).

The localization, which you have proposed:
/sys/devices/system/cpu/cpufreq/boost

implies, that boost is a global feature (enabled for all cores and for
all available policies).

Which approach shall be used then? 


> 
> Thanks,
> Rafael
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 28 May 2013 12:10, Lukasz Majewski <l.majewski@samsung.com> wrote:
> On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote: <manually added by viresh>
>> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
>> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> I was talking about /sys/devices/system/cpu/cpufreq/boost that
>> appears to have been added by commit 615b730 (acpi-cpufreq: Add
>> support for disabling dynamic overclocking).
>>
>> That's in acpi-cpufreq, but since that setting seems to be generally
>> useful, it may be a good idea to move it to the core somehow.

Problem is in breaking existing cpufreq userspace for this driver.
Is this allowed?

> I think that Viresh wanted to add "boost" option to
> /sys/devices/system/cpu/cpuX/cpufreq/ to be able to control boost
> at separate cores (policies).
>
> The localization, which you have proposed:
> /sys/devices/system/cpu/cpufreq/boost
>
> implies, that boost is a global feature (enabled for all cores and for
> all available policies).
>
> Which approach shall be used then?

We can use: get_governor_parent_kobj() to get the best location
for boost. But I had some other issues in mind:
- boost is governor dependent.. i.e. It is only required for ondemand
governor (And LAB if it makes it to mainline :) ).. Other governors
doesn't need it. So, it would be better to add it in governor's directory.
- This will break existing users of acpi-cpufreq driver.

@Rafael: Please suggest what to do here.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Rafael J. Wysocki]

On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> On 28 May 2013 12:10, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote: <manually added by viresh>
> >> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> >> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> I was talking about /sys/devices/system/cpu/cpufreq/boost that
> >> appears to have been added by commit 615b730 (acpi-cpufreq: Add
> >> support for disabling dynamic overclocking).
> >>
> >> That's in acpi-cpufreq, but since that setting seems to be generally
> >> useful, it may be a good idea to move it to the core somehow.
> 
> Problem is in breaking existing cpufreq userspace for this driver.
> Is this allowed?
> 
> > I think that Viresh wanted to add "boost" option to
> > /sys/devices/system/cpu/cpuX/cpufreq/ to be able to control boost
> > at separate cores (policies).
> >
> > The localization, which you have proposed:
> > /sys/devices/system/cpu/cpufreq/boost
> >
> > implies, that boost is a global feature (enabled for all cores and for
> > all available policies).
> >
> > Which approach shall be used then?
> 
> We can use: get_governor_parent_kobj() to get the best location
> for boost. But I had some other issues in mind:
> - boost is governor dependent.. i.e. It is only required for ondemand
> governor (And LAB if it makes it to mainline :) ).. Other governors
> doesn't need it. So, it would be better to add it in governor's directory.

I'm not sure about that.  On x86 boost will be used with all governors if
enabled (as currently defined in acpi-cpufreq).

Also it looks like this depends on the driver too, because if the driver
doesn't have "turbo" frequencies, the governor won't be able use "turbo"
anyway.

> - This will break existing users of acpi-cpufreq driver.
> 
> @Rafael: Please suggest what to do here.

So first, it would make sense to use a per-driver "boost" attribute indicating
whether or not the given driver should present any "turbo" frequencies to the
governor.  That'd work along the lines of the acpi-cpufreq "boost", but I don't
think that the global_boost attribute should be created by the driver (it'd be
better if the driver provided methods to the core for handling that).

Second, I'm not sure if an additional knob for the governor is necessary.  It
may just use the turbo frequencies if available (and if the governor cannot use
them, it simply won't use them).

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh, Rafael,

> On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> > On 28 May 2013 12:10, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > <manually added by viresh>
> > >> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> > >> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > >> I was talking about /sys/devices/system/cpu/cpufreq/boost that
> > >> appears to have been added by commit 615b730 (acpi-cpufreq: Add
> > >> support for disabling dynamic overclocking).
> > >>
> > >> That's in acpi-cpufreq, but since that setting seems to be
> > >> generally useful, it may be a good idea to move it to the core
> > >> somehow.
> > 
> > Problem is in breaking existing cpufreq userspace for this driver.
> > Is this allowed?
> > 
> > > I think that Viresh wanted to add "boost" option to
> > > /sys/devices/system/cpu/cpuX/cpufreq/ to be able to control boost
> > > at separate cores (policies).
> > >
> > > The localization, which you have proposed:
> > > /sys/devices/system/cpu/cpufreq/boost
> > >
> > > implies, that boost is a global feature (enabled for all cores
> > > and for all available policies).
> > >
> > > Which approach shall be used then?
> > 
> > We can use: get_governor_parent_kobj() to get the best location
> > for boost. But I had some other issues in mind:
> > - boost is governor dependent.. i.e. It is only required for
> > ondemand governor (And LAB if it makes it to mainline :) ).. Other
> > governors doesn't need it. So, it would be better to add it in
> > governor's directory.
> 


> I'm not sure about that.  On x86 boost will be used with all
> governors if enabled (as currently defined in acpi-cpufreq).

All governors can benefit from the overclocking code.


> 
> Also it looks like this depends on the driver too, because if the
> driver doesn't have "turbo" frequencies, the governor won't be able
> use "turbo" anyway.
> 

Rafael is correct here. The overclocking framework depends on
cpufreq_driver (exynos-cpufreq in my case) to switch to overclocked
frequency.


> > - This will break existing users of acpi-cpufreq driver.
> > 
> > @Rafael: Please suggest what to do here.
> 
> So first, it would make sense to use a per-driver "boost" attribute
> indicating whether or not the given driver should present any "turbo"
> frequencies to the governor.

Now I'm using a device tree's cpufreq section (defined at
exynos4412-redwood.dts) with overclocking = "okay" attribute defined.
Then, on this basis, we could decide at cpufreq init time if we will
export any overclocking related sysfs entries (or init overclocking at
all). It would assure clearer code.


>  That'd work along the lines of the
> acpi-cpufreq "boost", but I don't think that the global_boost
> attribute should be created by the driver (it'd be better if the
> driver provided methods to the core for handling that).

I think that global cpufreq device tree attribute shall be defined. The
overclocking will be an integral part of the cpufreq framework.

> 
> Second, I'm not sure if an additional knob for the governor is
> necessary.  It may just use the turbo frequencies if available (and
> if the governor cannot use them, it simply won't use them).

I cannot agree. It is welcome to be able to enable/disable the feature
when needed. Turbo frequencies shall not be "available" for use all the
time. For me this situation is far more dangerous.

> 
> Thanks,
> Rafael
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Rafael J. Wysocki]

On Tuesday, May 28, 2013 03:26:25 PM Lukasz Majewski wrote:
> Hi Viresh, Rafael,
> 
> > On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> > > On 28 May 2013 12:10, Lukasz Majewski <l.majewski@samsung.com>
> > > wrote:
> > > > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > > <manually added by viresh>
> > > >> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> > > >> > On 27 May 2013 17:30, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > >> I was talking about /sys/devices/system/cpu/cpufreq/boost that
> > > >> appears to have been added by commit 615b730 (acpi-cpufreq: Add
> > > >> support for disabling dynamic overclocking).
> > > >>
> > > >> That's in acpi-cpufreq, but since that setting seems to be
> > > >> generally useful, it may be a good idea to move it to the core
> > > >> somehow.
> > > 
> > > Problem is in breaking existing cpufreq userspace for this driver.
> > > Is this allowed?
> > > 
> > > > I think that Viresh wanted to add "boost" option to
> > > > /sys/devices/system/cpu/cpuX/cpufreq/ to be able to control boost
> > > > at separate cores (policies).
> > > >
> > > > The localization, which you have proposed:
> > > > /sys/devices/system/cpu/cpufreq/boost
> > > >
> > > > implies, that boost is a global feature (enabled for all cores
> > > > and for all available policies).
> > > >
> > > > Which approach shall be used then?
> > > 
> > > We can use: get_governor_parent_kobj() to get the best location
> > > for boost. But I had some other issues in mind:
> > > - boost is governor dependent.. i.e. It is only required for
> > > ondemand governor (And LAB if it makes it to mainline :) ).. Other
> > > governors doesn't need it. So, it would be better to add it in
> > > governor's directory.
> > 
> 
> 
> > I'm not sure about that.  On x86 boost will be used with all
> > governors if enabled (as currently defined in acpi-cpufreq).
> 
> All governors can benefit from the overclocking code.
> 
> 
> > 
> > Also it looks like this depends on the driver too, because if the
> > driver doesn't have "turbo" frequencies, the governor won't be able
> > use "turbo" anyway.
> > 
> 
> Rafael is correct here. The overclocking framework depends on
> cpufreq_driver (exynos-cpufreq in my case) to switch to overclocked
> frequency.
> 
> 
> > > - This will break existing users of acpi-cpufreq driver.
> > > 
> > > @Rafael: Please suggest what to do here.
> > 
> > So first, it would make sense to use a per-driver "boost" attribute
> > indicating whether or not the given driver should present any "turbo"
> > frequencies to the governor.
> 
> Now I'm using a device tree's cpufreq section (defined at
> exynos4412-redwood.dts) with overclocking = "okay" attribute defined.
> Then, on this basis, we could decide at cpufreq init time if we will
> export any overclocking related sysfs entries (or init overclocking at
> all). It would assure clearer code.

Well, what about users?  Don't you want them to be able to decide whether
or not to use "turbo"?

> >  That'd work along the lines of the
> > acpi-cpufreq "boost", but I don't think that the global_boost
> > attribute should be created by the driver (it'd be better if the
> > driver provided methods to the core for handling that).
> 
> I think that global cpufreq device tree attribute shall be defined.

What do you mean by "device tree attribute"?  If you mean FDTs as used by
ARM for system configuration description, that wouldn't be portable, because
DTs aren't used for that on the (majority of) x86 systems.

> The overclocking will be an integral part of the cpufreq framework.

Well, to be precise, I was thinking about moving the management of the
/sys/devices/system/cpu/cpufreq/boost attribute from acpi-cpufreq to the
code so that other drivers may use it too.  Does that make sense to you?

> > 
> > Second, I'm not sure if an additional knob for the governor is
> > necessary.  It may just use the turbo frequencies if available (and
> > if the governor cannot use them, it simply won't use them).
> 
> I cannot agree. It is welcome to be able to enable/disable the feature
> when needed. Turbo frequencies shall not be "available" for use all the
> time.

Well, they won't.  The "boost" attribute above may be used to turn "turbo"
off in that case.  I'm not sure why one more attribute is needed here.

Can you please explain how you the whole mechanism is supposed to work on
your platform, in general terms?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 29 May 2013 03:18, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, May 28, 2013 03:26:25 PM Lukasz Majewski wrote:
>> Hi Viresh, Rafael,
>>
>> > On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:

>> > I'm not sure about that.  On x86 boost will be used with all
>> > governors if enabled (as currently defined in acpi-cpufreq).
>>
>> All governors can benefit from the overclocking code.

Yeah.

>> > Also it looks like this depends on the driver too, because if the
>> > driver doesn't have "turbo" frequencies, the governor won't be able
>> > use "turbo" anyway.

Yes.

>> > So first, it would make sense to use a per-driver "boost" attribute
>> > indicating whether or not the given driver should present any "turbo"
>> > frequencies to the governor.

@Lukasz: So, you need to add another field in struct cpufreq_driver,
which will be called "turbo_mode" or something better.

>> Now I'm using a device tree's cpufreq section (defined at
>> exynos4412-redwood.dts) with overclocking = "okay" attribute defined.
>> Then, on this basis, we could decide at cpufreq init time if we will
>> export any overclocking related sysfs entries (or init overclocking at
>> all). It would assure clearer code.
>
> Well, what about users?  Don't you want them to be able to decide whether
> or not to use "turbo"?

I believe Lukasz was saying that we can have two levels of enabling it..
Firstly the driver can say if it supports turbo_mode or not and so will
register cpufreq_driver with appropriate parameters..

Now if turbo_mode == true, then sysfs entry will be created by cpufreq
core which users can enable/disable...

And this is what I had in mind too.

>> I think that global cpufreq device tree attribute shall be defined.
>
> What do you mean by "device tree attribute"?  If you mean FDTs as used by
> ARM for system configuration description, that wouldn't be portable, because
> DTs aren't used for that on the (majority of) x86 systems.

So, drivers should pass correct value in boost_mode in struct cpufreq_driver.
They get it from DT or is hard coded doesn't matter at all to the core. But
yes getting a single name for DT bindings would be good. We should use
the same name at that place too: turbo_mode

>> The overclocking will be an integral part of the cpufreq framework.
>
> Well, to be precise, I was thinking about moving the management of the
> /sys/devices/system/cpu/cpufreq/boost attribute from acpi-cpufreq to the
> code so that other drivers may use it too.  Does that make sense to you?

Obviously yes. The sysfs related code from acpi-cpufreq should be moved
to cpufreq.c and will be functional once cpufreq_driver has boost_mode set
as true.

>> > Second, I'm not sure if an additional knob for the governor is
>> > necessary.  It may just use the turbo frequencies if available (and
>> > if the governor cannot use them, it simply won't use them).
>>
>> I cannot agree. It is welcome to be able to enable/disable the feature
>> when needed. Turbo frequencies shall not be "available" for use all the
>> time.

Yes, you can disable that from userspace once your driver said: "I support
turbo mode"..

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh, Rafael,

> On 29 May 2013 03:18, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, May 28, 2013 03:26:25 PM Lukasz Majewski wrote:
> >> Hi Viresh, Rafael,
> >>
> >> > On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> 
> >> > I'm not sure about that.  On x86 boost will be used with all
> >> > governors if enabled (as currently defined in acpi-cpufreq).
> >>
> >> All governors can benefit from the overclocking code.
> 
> Yeah.
> 
> >> > Also it looks like this depends on the driver too, because if the
> >> > driver doesn't have "turbo" frequencies, the governor won't be
> >> > able use "turbo" anyway.
> 
> Yes.
> 
> >> > So first, it would make sense to use a per-driver "boost"
> >> > attribute indicating whether or not the given driver should
> >> > present any "turbo" frequencies to the governor.
> 
> @Lukasz: So, you need to add another field in struct cpufreq_driver,
> which will be called "turbo_mode" or something better.

This is my intention - to extend cpufreq_driver structure. When
turbo_mode=1, then we will export knobs to sysfs.

For ARM, it is also convenient to define proper attribute at device
tree, per-board source file. It will be parsed at cpufreq driver and
set turbo_mode accordingly.

> 
> >> Now I'm using a device tree's cpufreq section (defined at
> >> exynos4412-redwood.dts) with overclocking = "okay" attribute
> >> defined. Then, on this basis, we could decide at cpufreq init time
> >> if we will export any overclocking related sysfs entries (or init
> >> overclocking at all). It would assure clearer code.
> >
> > Well, what about users?  Don't you want them to be able to decide
> > whether or not to use "turbo"?
> 
> I believe Lukasz was saying that we can have two levels of enabling
> it.. Firstly the driver can say if it supports turbo_mode or not and
> so will register cpufreq_driver with appropriate parameters..
> 
> Now if turbo_mode == true, then sysfs entry will be created by cpufreq
> core which users can enable/disable...
> 
Yes, this is the point. Sorry for blur description.

> And this is what I had in mind too.
> 
> >> I think that global cpufreq device tree attribute shall be defined.
> >
> > What do you mean by "device tree attribute"?  If you mean FDTs as
> > used by ARM for system configuration description, that wouldn't be
> > portable, because DTs aren't used for that on the (majority of) x86
> > systems.
> 
> So, drivers should pass correct value in boost_mode in struct
> cpufreq_driver. They get it from DT or is hard coded doesn't matter
> at all to the core. But yes getting a single name for DT bindings
> would be good. We should use the same name at that place too:
> turbo_mode
> 

Yes, this is my goal. For prototype (on which I'm now working) I've
used overclock attribute. But, I will change its name to turbo_mode. 

> >> The overclocking will be an integral part of the cpufreq framework.
> >
> > Well, to be precise, I was thinking about moving the management of
> > the /sys/devices/system/cpu/cpufreq/boost attribute from
> > acpi-cpufreq to the code so that other drivers may use it too.
> > Does that make sense to you?
> 
> Obviously yes. The sysfs related code from acpi-cpufreq should be
> moved to cpufreq.c and will be functional once cpufreq_driver has
> boost_mode set as true.

I also agree. Moreover, I think that there should be only one set of
"boost" sysfs entries either it is supported by HW (Intel) or SW (ARM).

I can think of two "basic" one: 
- max_turbo_freq (ro)
- turbo_mode/boost (rw)

But I cannot figure out where those entries shall be finally placed [*]:
- /sys/devices/system/cpu/cpuX/cpufreq/

or 

- /sys/devices/system/cpu/cpufreq/boost

Second option would be better, if we assume that boost is a global
option - as at Intel (I might be wrong here...) and ARM exynos4 SoC.

On the other hand first option would be used with systems, where
per-core (or core sets) frequency setting is possible (b.L, Snapdragon
S4)

> 
> >> > Second, I'm not sure if an additional knob for the governor is
> >> > necessary.  It may just use the turbo frequencies if available
> >> > (and if the governor cannot use them, it simply won't use them).
> >>
> >> I cannot agree. It is welcome to be able to enable/disable the
> >> feature when needed. Turbo frequencies shall not be "available"
> >> for use all the time.
> 
> Yes, you can disable that from userspace once your driver said: "I
> support turbo mode"..

To sum up - the idea is as follow:

1. cpufreq_driver exports turbo_mode=1 when it supports overclocking
(this support can be hardcoded or read from device tree)

2. Then proper entries are exported to sysfs.

3. User via sysfs (at [*]) can enable/disable the feature on demand 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Viresh Kumar]

On 29 May 2013 12:39, Lukasz Majewski <l.majewski@samsung.com> wrote:
> I also agree. Moreover, I think that there should be only one set of
> "boost" sysfs entries either it is supported by HW (Intel) or SW (ARM).

Yes, you need to change acpi-cpufreq driver too to use this common
infrastructure.

> I can think of two "basic" one:
> - max_turbo_freq (ro)

This is surely per policy as two separate clusters can have separate values.
And probably a better one would be scaling_boost_frequencies, that will
list all boost frequencies.

> - turbo_mode/boost (rw)

I am confused with these two names: boost and turbo.. Probably we
should use a single name everywhere. Because acpi-cpufreq is already
using boost, we might shift to that.

> - /sys/devices/system/cpu/cpufreq/boost

Obviously this one.

> On the other hand first option would be used with systems, where
> per-core (or core sets) frequency setting is possible (b.L, Snapdragon
> S4)

For now this feature would be enabled on all clusters and controlled
by cpu/cpufreq/boost.

> To sum up - the idea is as follow:
>
> 1. cpufreq_driver exports turbo_mode=1 when it supports overclocking
> (this support can be hardcoded or read from device tree)
>
> 2. Then proper entries are exported to sysfs.
>
> 3. User via sysfs (at [*]) can enable/disable the feature on demand

Bingo!!

Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski]

Hi Viresh,

> On 29 May 2013 12:39, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > I also agree. Moreover, I think that there should be only one set of
> > "boost" sysfs entries either it is supported by HW (Intel) or SW
> > (ARM).
> 
> Yes, you need to change acpi-cpufreq driver too to use this common
> infrastructure.

Ok, thanks for pointing out.

> 
> > I can think of two "basic" one:
> > - max_turbo_freq (ro)
> 
> This is surely per policy as two separate clusters can have separate
> values. And probably a better one would be scaling_boost_frequencies,
> that will list all boost frequencies.

Ok,

> 
> > - turbo_mode/boost (rw)
> 
> I am confused with these two names: boost and turbo.. Probably we
> should use a single name everywhere. Because acpi-cpufreq is already
> using boost, we might shift to that.
> 
> > - /sys/devices/system/cpu/cpufreq/boost
> 
> Obviously this one.
> 
> > On the other hand first option would be used with systems, where
> > per-core (or core sets) frequency setting is possible (b.L,
> > Snapdragon S4)
> 
> For now this feature would be enabled on all clusters and controlled
> by cpu/cpufreq/boost.

This will simplify considerably the driver code.

> 
> > To sum up - the idea is as follow:
> >
> > 1. cpufreq_driver exports turbo_mode=1 when it supports overclocking
> > (this support can be hardcoded or read from device tree)
> >
> > 2. Then proper entries are exported to sysfs.
> >
> > 3. User via sysfs (at [*]) can enable/disable the feature on demand
> 
> Bingo!!

Thanks for suggestions. I'm now working on a prototype code. I plan to
post it at the beginning of next week.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Despite this patch set is working and applicable on top of 3.14-rc5, 
please regard it solely as a pure RFC.

This patch provides support for LAB governor build on top of ondemand.
Previous version of LAB can be found here:
http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq

LAB short reminder:

LAB uses information about how many cores are in "idle" state (the core 
idleness is represented as the value between 0 and 100) and the overall 
load of the system (from 0 to 100) to decide about frequency to be set.
It is extremely useful with SoCs like Exynos4412, which can set only one
frequency for all cores.

Important design decisions:

- Reuse well established ondemand governor's internal code. To do this
  I had to expose some previously static internal ondemand code. 
  This allowed smaller LAB code when compared to previous version.
	
- LAB works on top of ondemand, which means that one via device tree
  attributes can specify if and when e.g. BOOST shall be enabled or if 
  any particular frequency shall be imposed. For situation NOT important 
  from the power consumption reduction viewpoint the ondemand is used to 
  set proper frequency.

- It is only possible to either compile in or not the LAB into the kernel. 
  There is no "M" option for Kconfig. It is done on purpose, since ondemand 
  itself can be also compiled as a module and then it would be possible to
  remove ondemand when LAB is working on top of it.

- The LAB operation is specified (and thereof extendable) via device tree
  lab-ctrl-freq attribute defined at /cpus/cpu0.


Problems:
- How the governor will work for big.LITTLE systems (especially Global Task
  Scheduling).
- Will there be agreement to expose internal ondemand code to be reused for
  more specialized governors.

Test HW:
	Exynos4412 - Trats2 board.
Above patches were posted on top of Linux 3.14-rc5
(SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)

Lukasz Majewski (5):
  cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
  cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support
    LAB
  cpufreq:LAB:lab Add LAB governor code
  cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
  cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

 arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
 drivers/cpufreq/Kconfig                 |   28 ++
 drivers/cpufreq/Makefile                |    1 +
 drivers/cpufreq/cpufreq_governor.c      |    7 +
 drivers/cpufreq/cpufreq_governor.h      |   12 +
 drivers/cpufreq/cpufreq_lab.c           |  457 +++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_ondemand.c      |   24 +-
 7 files changed, 550 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

-- 
1.7.10.4

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Despite this patch set is working and applicable on top of 3.14-rc5, 
please regard it solely as a pure RFC.

This patch provides support for LAB governor build on top of ondemand.
Previous version of LAB can be found here:
http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq

LAB short reminder:

LAB uses information about how many cores are in "idle" state (the core 
idleness is represented as the value between 0 and 100) and the overall 
load of the system (from 0 to 100) to decide about frequency to be set.
It is extremely useful with SoCs like Exynos4412, which can set only one
frequency for all cores.

Important design decisions:

- Reuse well established ondemand governor's internal code. To do this
  I had to expose some previously static internal ondemand code. 
  This allowed smaller LAB code when compared to previous version.
	
- LAB works on top of ondemand, which means that one via device tree
  attributes can specify if and when e.g. BOOST shall be enabled or if 
  any particular frequency shall be imposed. For situation NOT important 
  from the power consumption reduction viewpoint the ondemand is used to 
  set proper frequency.

- It is only possible to either compile in or not the LAB into the kernel. 
  There is no "M" option for Kconfig. It is done on purpose, since ondemand 
  itself can be also compiled as a module and then it would be possible to
  remove ondemand when LAB is working on top of it.

- The LAB operation is specified (and thereof extendable) via device tree
  lab-ctrl-freq attribute defined at /cpus/cpu0.


Problems:
- How the governor will work for big.LITTLE systems (especially Global Task
  Scheduling).
- Will there be agreement to expose internal ondemand code to be reused for
  more specialized governors.

Test HW:
	Exynos4412 - Trats2 board.
Above patches were posted on top of Linux 3.14-rc5
(SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)

Lukasz Majewski (5):
  cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
  cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support
    LAB
  cpufreq:LAB:lab Add LAB governor code
  cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
  cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

 arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
 drivers/cpufreq/Kconfig                 |   28 ++
 drivers/cpufreq/Makefile                |    1 +
 drivers/cpufreq/cpufreq_governor.c      |    7 +
 drivers/cpufreq/cpufreq_governor.h      |   12 +
 drivers/cpufreq/cpufreq_lab.c           |  457 +++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq_ondemand.c      |   24 +-
 7 files changed, 550 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

-- 
1.7.10.4

[RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods

[Lukasz Majewski]

Ondemand code needed to be slightly adjusted to allow its reusage.
Mostly one needed to remove static qualifiers and provide some hacks to
allow its working with LAB.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.h |   10 ++++++++++
 drivers/cpufreq/cpufreq_ondemand.c |   24 ++++++++++++++++--------
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index bfb9ae1..34b1cf2 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -270,4 +270,14 @@ void od_register_powersave_bias_handler(unsigned int (*f)
 		(struct cpufreq_policy *, unsigned int, unsigned int),
 		unsigned int powersave_bias);
 void od_unregister_powersave_bias_handler(void);
+
+/* COMMON CODE FOR DEMAND BASED SWITCHING */
+void od_dbs_timer(struct work_struct *work);
+int od_init(struct dbs_data *dbs_data);
+void od_exit(struct dbs_data *dbs_data);
+void od_check_cpu(int cpu, unsigned int load_freq);
+void update_sampling_rate(struct dbs_data *dbs_data,
+			  unsigned int new_rate);
+
+extern struct od_ops od_ops;
 #endif /* _CPUFREQ_GOVERNOR_H */
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 18d4091..a27326d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -27,9 +27,9 @@
 #define MIN_FREQUENCY_UP_THRESHOLD		(11)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)
 
-static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
 
-static struct od_ops od_ops;
+struct od_ops od_ops;
 
 #ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
 static struct cpufreq_governor cpufreq_gov_ondemand;
@@ -152,7 +152,7 @@ static void dbs_freq_increase(struct cpufreq_policy *policy, unsigned int freq)
  * (default), then we try to increase frequency. Else, we adjust the frequency
  * proportional to load.
  */
-static void od_check_cpu(int cpu, unsigned int load)
+void od_check_cpu(int cpu, unsigned int load)
 {
 	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
@@ -188,7 +188,7 @@ static void od_check_cpu(int cpu, unsigned int load)
 	}
 }
 
-static void od_dbs_timer(struct work_struct *work)
+void od_dbs_timer(struct work_struct *work)
 {
 	struct od_cpu_dbs_info_s *dbs_info =
 		container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
@@ -233,6 +233,9 @@ max_delay:
 /************************** sysfs interface ************************/
 static struct common_dbs_data od_dbs_cdata;
 
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+extern struct cpufreq_governor cpufreq_gov_lab;
+#endif
 /**
  * update_sampling_rate - update sampling rate effective immediately if needed.
  * @new_rate: new sampling rate
@@ -246,7 +249,7 @@ static struct common_dbs_data od_dbs_cdata;
  * reducing the sampling rate, we need to make the new value effective
  * immediately.
  */
-static void update_sampling_rate(struct dbs_data *dbs_data,
+void update_sampling_rate(struct dbs_data *dbs_data,
 		unsigned int new_rate)
 {
 	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
@@ -263,7 +266,12 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 		policy = cpufreq_cpu_get(cpu);
 		if (!policy)
 			continue;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+		if (policy->governor != &cpufreq_gov_ondemand &&
+		    policy->governor != &cpufreq_gov_lab) {
+#else
 		if (policy->governor != &cpufreq_gov_ondemand) {
+#endif
 			cpufreq_cpu_put(policy);
 			continue;
 		}
@@ -472,7 +480,7 @@ static struct attribute_group od_attr_group_gov_pol = {
 
 /************************** sysfs end ************************/
 
-static int od_init(struct dbs_data *dbs_data)
+int od_init(struct dbs_data *dbs_data)
 {
 	struct od_dbs_tuners *tuners;
 	u64 idle_time;
@@ -514,14 +522,14 @@ static int od_init(struct dbs_data *dbs_data)
 	return 0;
 }
 
-static void od_exit(struct dbs_data *dbs_data)
+void od_exit(struct dbs_data *dbs_data)
 {
 	kfree(dbs_data->tuners);
 }
 
 define_get_cpu_dbs_routines(od_cpu_dbs_info);
 
-static struct od_ops od_ops = {
+struct od_ops od_ops = {
 	.powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu,
 	.powersave_bias_target = generic_powersave_bias_target,
 	.freq_increase = dbs_freq_increase,
-- 
1.7.10.4

[RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods

[Lukasz Majewski]

Ondemand code needed to be slightly adjusted to allow its reusage.
Mostly one needed to remove static qualifiers and provide some hacks to
allow its working with LAB.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.h |   10 ++++++++++
 drivers/cpufreq/cpufreq_ondemand.c |   24 ++++++++++++++++--------
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index bfb9ae1..34b1cf2 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -270,4 +270,14 @@ void od_register_powersave_bias_handler(unsigned int (*f)
 		(struct cpufreq_policy *, unsigned int, unsigned int),
 		unsigned int powersave_bias);
 void od_unregister_powersave_bias_handler(void);
+
+/* COMMON CODE FOR DEMAND BASED SWITCHING */
+void od_dbs_timer(struct work_struct *work);
+int od_init(struct dbs_data *dbs_data);
+void od_exit(struct dbs_data *dbs_data);
+void od_check_cpu(int cpu, unsigned int load_freq);
+void update_sampling_rate(struct dbs_data *dbs_data,
+			  unsigned int new_rate);
+
+extern struct od_ops od_ops;
 #endif /* _CPUFREQ_GOVERNOR_H */
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 18d4091..a27326d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -27,9 +27,9 @@
 #define MIN_FREQUENCY_UP_THRESHOLD		(11)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)
 
-static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
 
-static struct od_ops od_ops;
+struct od_ops od_ops;
 
 #ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
 static struct cpufreq_governor cpufreq_gov_ondemand;
@@ -152,7 +152,7 @@ static void dbs_freq_increase(struct cpufreq_policy *policy, unsigned int freq)
  * (default), then we try to increase frequency. Else, we adjust the frequency
  * proportional to load.
  */
-static void od_check_cpu(int cpu, unsigned int load)
+void od_check_cpu(int cpu, unsigned int load)
 {
 	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
@@ -188,7 +188,7 @@ static void od_check_cpu(int cpu, unsigned int load)
 	}
 }
 
-static void od_dbs_timer(struct work_struct *work)
+void od_dbs_timer(struct work_struct *work)
 {
 	struct od_cpu_dbs_info_s *dbs_info =
 		container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
@@ -233,6 +233,9 @@ max_delay:
 /************************** sysfs interface ************************/
 static struct common_dbs_data od_dbs_cdata;
 
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+extern struct cpufreq_governor cpufreq_gov_lab;
+#endif
 /**
  * update_sampling_rate - update sampling rate effective immediately if needed.
  * @new_rate: new sampling rate
@@ -246,7 +249,7 @@ static struct common_dbs_data od_dbs_cdata;
  * reducing the sampling rate, we need to make the new value effective
  * immediately.
  */
-static void update_sampling_rate(struct dbs_data *dbs_data,
+void update_sampling_rate(struct dbs_data *dbs_data,
 		unsigned int new_rate)
 {
 	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
@@ -263,7 +266,12 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 		policy = cpufreq_cpu_get(cpu);
 		if (!policy)
 			continue;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+		if (policy->governor != &cpufreq_gov_ondemand &&
+		    policy->governor != &cpufreq_gov_lab) {
+#else
 		if (policy->governor != &cpufreq_gov_ondemand) {
+#endif
 			cpufreq_cpu_put(policy);
 			continue;
 		}
@@ -472,7 +480,7 @@ static struct attribute_group od_attr_group_gov_pol = {
 
 /************************** sysfs end ************************/
 
-static int od_init(struct dbs_data *dbs_data)
+int od_init(struct dbs_data *dbs_data)
 {
 	struct od_dbs_tuners *tuners;
 	u64 idle_time;
@@ -514,14 +522,14 @@ static int od_init(struct dbs_data *dbs_data)
 	return 0;
 }
 
-static void od_exit(struct dbs_data *dbs_data)
+void od_exit(struct dbs_data *dbs_data)
 {
 	kfree(dbs_data->tuners);
 }
 
 define_get_cpu_dbs_routines(od_cpu_dbs_info);
 
-static struct od_ops od_ops = {
+struct od_ops od_ops = {
 	.powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu,
 	.powersave_bias_target = generic_powersave_bias_target,
 	.freq_increase = dbs_freq_increase,
-- 
1.7.10.4

[RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB

[Lukasz Majewski]

Some minor adjustments were needed to support LAB operation in the
cpufreq_governor.[h|c] files.

Most notably, code for proper estimation of the idle time for each CPU is
added here.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.c |    7 +++++++
 drivers/cpufreq/cpufreq_governor.h |    2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index ba43991..99fc3e8 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -98,6 +98,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 
 		load = 100 * (wall_time - idle_time) / wall_time;
 
+		if (dbs_data->cdata->governor == GOV_LAB) {
+			struct od_cpu_dbs_info_s *od_dbs_info =
+				dbs_data->cdata->get_cpu_dbs_info_s(j);
+
+			od_dbs_info->idle_time = (100 * idle_time) / wall_time;
+		}
+
 		if (load > max_load)
 			max_load = load;
 	}
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 34b1cf2..82a519f 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -152,6 +152,7 @@ struct od_cpu_dbs_info_s {
 	unsigned int freq_lo_jiffies;
 	unsigned int freq_hi_jiffies;
 	unsigned int rate_mult;
+	unsigned int idle_time;
 	unsigned int sample_type:1;
 };
 
@@ -187,6 +188,7 @@ struct common_dbs_data {
 	/* Common across governors */
 	#define GOV_ONDEMAND		0
 	#define GOV_CONSERVATIVE	1
+	#define GOV_LAB                 2
 	int governor;
 	struct attribute_group *attr_group_gov_sys; /* one governor - system */
 	struct attribute_group *attr_group_gov_pol; /* one governor - policy */
-- 
1.7.10.4

[RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB

[Lukasz Majewski]

Some minor adjustments were needed to support LAB operation in the
cpufreq_governor.[h|c] files.

Most notably, code for proper estimation of the idle time for each CPU is
added here.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/cpufreq_governor.c |    7 +++++++
 drivers/cpufreq/cpufreq_governor.h |    2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index ba43991..99fc3e8 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -98,6 +98,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 
 		load = 100 * (wall_time - idle_time) / wall_time;
 
+		if (dbs_data->cdata->governor == GOV_LAB) {
+			struct od_cpu_dbs_info_s *od_dbs_info =
+				dbs_data->cdata->get_cpu_dbs_info_s(j);
+
+			od_dbs_info->idle_time = (100 * idle_time) / wall_time;
+		}
+
 		if (load > max_load)
 			max_load = load;
 	}
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 34b1cf2..82a519f 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -152,6 +152,7 @@ struct od_cpu_dbs_info_s {
 	unsigned int freq_lo_jiffies;
 	unsigned int freq_hi_jiffies;
 	unsigned int rate_mult;
+	unsigned int idle_time;
 	unsigned int sample_type:1;
 };
 
@@ -187,6 +188,7 @@ struct common_dbs_data {
 	/* Common across governors */
 	#define GOV_ONDEMAND		0
 	#define GOV_CONSERVATIVE	1
+	#define GOV_LAB                 2
 	int governor;
 	struct attribute_group *attr_group_gov_sys; /* one governor - system */
 	struct attribute_group *attr_group_gov_pol; /* one governor - policy */
-- 
1.7.10.4

[RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code

[Lukasz Majewski]

This patch adds code for LAB governor. It shall be noted, that it reuses
a lot of ondemand code.

The main difference is that it works on top of ondemand, and this code is
able to "call" ondemand when needed. This means that all ondemand "backing"
data are properly updated.

Such approach has one major advantage - with LAB we can focus on saving
energy and leave the "normal" cpufreq management to well tested ondemand.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Makefile      |    1 +
 drivers/cpufreq/cpufreq_lab.c |  457 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 458 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..64bff8dc 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)	+= cpufreq_powersave.o
 obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE)	+= cpufreq_userspace.o
 obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)	+= cpufreq_ondemand.o
 obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)	+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB)		+= cpufreq_lab.o
 obj-$(CONFIG_CPU_FREQ_GOV_COMMON)		+= cpufreq_governor.o
 
 obj-$(CONFIG_GENERIC_CPUFREQ_CPU0)	+= cpufreq-cpu0.o
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 0000000..153c06b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *		Jonghwa Lee <jonghw3.lee@samusng.com>
+ *		Lukasz Majewski <l.majewski@samsung.com>
+ *
+ * LAB (Legacy Application Boost) cpufreq governor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kernel_stat.h>
+#include <linux/kobject.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/percpu-defs.h>
+#include <linux/sysfs.h>
+#include <linux/tick.h>
+#include <linux/types.h>
+#include <linux/cpuidle.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+
+#include "cpufreq_governor.h"
+
+#define MAX_HIST		5
+
+#define LB_BOOST_ENABLE        ~0UL
+#define LB_MIN_FREQ            ~1UL
+#define LB_ONDEMAND             0
+
+/*
+ * Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int *idle_hist;
+static int idle_cpus, lb_threshold = 90;
+static unsigned int *lb_ctrl_table, lb_load;
+static int lb_ctrl_table_size, lb_num_of_states;
+static bool boost_init_state;
+
+static DECLARE_BITMAP(boost_hist, MAX_HIST);
+DECLARE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+
+struct cpufreq_governor cpufreq_gov_lab;
+
+
+static struct lb_wq_boost_data {
+	bool state;
+	struct work_struct work;
+} lb_boost_data;
+
+/*
+ * Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+	int i, sum;
+
+	for (i = 0, sum = 0; i < size; p++, i++) {
+		sum += *p;
+		*p >>= 1;
+	}
+	sum *= 100;
+
+	return (int) (sum / history_weight_sum[size - 1]);
+}
+
+static unsigned int lb_chose_freq(unsigned int load, int idle_cpus)
+{
+	unsigned int p, q = 100 / lb_num_of_states;
+	int idx;
+
+	for (idx = 0, p = q; idx < lb_num_of_states; idx++, p += q)
+		if (load <= p)
+			break;
+
+	return *(lb_ctrl_table + (lb_num_of_states * idle_cpus) + idx);
+}
+
+static void lb_cpufreq_boost_work(struct work_struct *work)
+{
+	struct lb_wq_boost_data *d = container_of(work,
+						  struct lb_wq_boost_data,
+						  work);
+	cpufreq_boost_trigger_state(d->state);
+}
+
+static struct common_dbs_data lb_dbs_cdata;
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load)
+{
+	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
+	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+	unsigned int freq = 0, op;
+	static int cnt;
+	int i, idx, bs;
+
+	idle_cpus = 0;
+	lb_load = load;
+	idx = cnt++ % MAX_HIST;
+
+	for_each_possible_cpu(i) {
+		struct od_cpu_dbs_info_s *dbs_cpu_info =
+			&per_cpu(od_cpu_dbs_info, i);
+
+		idle_hist[i * MAX_HIST + idx] = dbs_cpu_info->idle_time;
+		idle_avg[i] = cpu_idle_calc_avg(&idle_hist[i * MAX_HIST],
+					cnt < MAX_HIST ? cnt : MAX_HIST);
+
+		if (idle_avg[i] > lb_threshold)
+			idle_cpus++;
+	}
+
+	if (idle_cpus < 0 || idle_cpus > num_possible_cpus()) {
+		pr_warn("%s: idle_cpus: %d out of range\n", __func__,
+			idle_cpus);
+		return;
+	}
+
+	if (!lb_ctrl_table)
+		return;
+
+	op = lb_chose_freq(load, idle_cpus);
+	if (op == LB_BOOST_ENABLE)
+		set_bit(idx, boost_hist);
+	else
+		clear_bit(idx, boost_hist);
+
+	bs = cpufreq_boost_enabled();
+	/*
+	 * - To disable boost -
+	 *
+	 * Operation different than LB_BOOST_ENABLE is
+	 * required for at least MAX_HIST previous operations
+	 */
+	if (bs && bitmap_empty(boost_hist, MAX_HIST)) {
+		lb_boost_data.state = false;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	/*
+	 * - To enable boost -
+	 *
+	 * Only (MAX_HIST - 1) bits are required. This allows entering
+	 * BOOST mode earlier, since we skip one "round" of LAB operation
+	 * before work is executed.
+	 */
+	if (!bs &&
+	    (bitmap_weight(boost_hist, MAX_HIST) == (MAX_HIST - 1))) {
+		lb_boost_data.state = true;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	switch (op) {
+	case LB_BOOST_ENABLE:
+		freq = policy->max;
+		break;
+
+	case LB_MIN_FREQ:
+		freq = policy->min;
+		break;
+
+	case LB_ONDEMAND:
+		od_check_cpu(cpu, load);
+		return;
+
+	default:
+		freq = op;
+	}
+
+	if (policy->cur == freq)
+		return;
+
+	__cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
+}
+
+static ssize_t show_load(struct kobject *kobj,
+			 struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_load);
+}
+define_one_global_ro(load);
+
+static ssize_t show_idle_cpus_num(struct kobject *kobj,
+				  struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", idle_cpus);
+}
+define_one_global_ro(idle_cpus_num);
+
+static ssize_t show_idle_avg_cpus_val(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	char off;
+	int i;
+
+	for (i = 0, off = 0; i < num_possible_cpus(); i++)
+		off += sprintf(buf + off, "%u ", idle_avg[i]);
+
+	*(buf + off - 1) = '\n';
+
+	return off;
+}
+define_one_global_ro(idle_avg_cpus_val);
+
+static ssize_t show_idle_threshold(struct kobject *kobj,
+				   struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_threshold);
+}
+
+static ssize_t store_idle_threshold(struct kobject *a, struct attribute *b,
+				    const char *buf, size_t count)
+{
+	unsigned int val;
+	int ret;
+
+	ret = sscanf(buf, "%u", &val);
+	if (ret != 1)
+		return -EINVAL;
+
+	if (val < 0 || val > 100) {
+		pr_err("%s: Only value in a range 0 to 100 accepted\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	lb_threshold = val;
+	return count;
+}
+define_one_global_rw(idle_threshold);
+
+ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
+				   const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+	if (ret != 1)
+		return -EINVAL;
+
+	update_sampling_rate(dbs_data, input);
+	return count;
+}
+
+static ssize_t show_sampling_rate(struct kobject *kobj, struct attribute *attr,
+				  char *buf)
+{
+	struct od_dbs_tuners *tuners = lb_dbs_cdata.gdbs_data->tuners;
+
+	return sprintf(buf, "%u\n", tuners->sampling_rate);
+}
+define_one_global_rw(sampling_rate);
+
+static ssize_t show_sampling_rate_min(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+
+	return sprintf(buf, "%u\n", dbs_data->min_sampling_rate);
+}
+define_one_global_ro(sampling_rate_min);
+
+static struct attribute *dbs_attributes_gov_sys[] = {
+	&sampling_rate_min.attr,
+	&idle_avg_cpus_val.attr,
+	&idle_threshold.attr,
+	&idle_cpus_num.attr,
+	&sampling_rate.attr,
+	&load.attr,
+	NULL
+};
+
+static struct attribute_group lb_attr_group_gov_sys = {
+	.attrs = dbs_attributes_gov_sys,
+	.name = "lab",
+};
+
+static int lb_ctrl_table_of_init(struct device_node *dn,
+				 unsigned int **ctrl_tab, int size)
+{
+	struct property *pp;
+	int len;
+
+	pp = of_find_property(dn, "lab-ctrl-freq", &len);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-ctrl-freq'  not found\n", __func__);
+		return -ENODEV;
+	}
+
+	if (len != (size * sizeof(**ctrl_tab))) {
+		pr_err("%s: Wrong 'lab-ctrl-freq' size\n", __func__);
+		return -EINVAL;
+	}
+
+	*ctrl_tab = kzalloc(len, GFP_KERNEL);
+	if (!*ctrl_tab) {
+		pr_err("%s: Not enough memory for LAB control structure\n",
+		       __func__);
+		return -ENOMEM;
+	}
+
+	if (of_property_read_u32_array(dn, pp->name, *ctrl_tab, size)) {
+		pr_err("Property: %s cannot be read!\n", pp->name);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int lb_of_init(void)
+{
+	struct device_node *dn;
+	struct property *pp;
+	int ret;
+
+	dn = of_find_node_by_path("/cpus/cpu@0");
+	if (!dn) {
+		pr_err("%s: Node: '/cpus/cpu@0/' not found\n", __func__);
+		return -ENODEV;
+	}
+
+	pp = of_find_property(dn, "lab-num-of-states", NULL);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-num-of-states'  not found\n",
+		       __func__);
+		ret = -ENODEV;
+		goto dn_err;
+	}
+	lb_num_of_states = be32_to_cpup(pp->value);
+
+	lb_ctrl_table_size = lb_num_of_states * (num_possible_cpus() + 1);
+	ret = lb_ctrl_table_of_init(dn, &lb_ctrl_table, lb_ctrl_table_size);
+	if (ret) {
+		kfree(lb_ctrl_table);
+		lb_ctrl_table = NULL;
+		pr_err("%s: Cannot parse LAB control structure from OF\n",
+		       __func__);
+		return ret;
+	}
+
+dn_err:
+	of_node_put(dn);
+	return ret;
+}
+
+static int lb_init(struct dbs_data *dbs_data)
+{
+	int ret;
+
+	idle_avg = kzalloc(num_possible_cpus() * sizeof(*idle_avg), GFP_KERNEL);
+	if (!idle_avg) {
+		pr_err("%s: Not enough memory", __func__);
+		return -ENOMEM;
+	}
+
+	idle_hist = kzalloc(num_possible_cpus() * MAX_HIST * sizeof(*idle_hist),
+			    GFP_KERNEL);
+	if (!idle_hist) {
+		pr_err("%s: Not enough memory", __func__);
+		ret = -ENOMEM;
+		goto err_idle_avg;
+	}
+
+	ret = lb_of_init();
+	if (ret)
+		goto err_idle_hist;
+
+	boost_init_state = cpufreq_boost_enabled();
+	if (boost_init_state)
+		cpufreq_boost_trigger_state(false);
+
+	od_init(dbs_data);
+
+	INIT_WORK(&lb_boost_data.work, lb_cpufreq_boost_work);
+
+	return 0;
+
+err_idle_hist:
+	kfree(idle_hist);
+err_idle_avg:
+	kfree(idle_avg);
+
+	return ret;
+}
+
+void lb_exit(struct dbs_data *dbs_data)
+{
+	od_exit(dbs_data);
+
+	kfree(lb_ctrl_table);
+	lb_ctrl_table = NULL;
+
+	cpufreq_boost_trigger_state(boost_init_state);
+
+	kfree(idle_avg);
+	kfree(idle_hist);
+}
+
+define_get_cpu_dbs_routines(od_cpu_dbs_info);
+
+static struct common_dbs_data lb_dbs_cdata = {
+	.governor = GOV_LAB,
+	.attr_group_gov_sys = &lb_attr_group_gov_sys,
+	.get_cpu_cdbs = get_cpu_cdbs,
+	.get_cpu_dbs_info_s = get_cpu_dbs_info_s,
+	.gov_dbs_timer = od_dbs_timer,
+	.gov_check_cpu = lb_check_cpu,
+	.gov_ops = &od_ops,
+	.init = lb_init,
+	.exit = lb_exit,
+};
+
+static int lb_cpufreq_governor_dbs(struct cpufreq_policy *policy,
+		unsigned int event)
+{
+	return cpufreq_governor_dbs(policy, &lb_dbs_cdata, event);
+}
+
+struct cpufreq_governor cpufreq_gov_lab = {
+	.name			= "lab",
+	.governor		= lb_cpufreq_governor_dbs,
+	.max_transition_latency = TRANSITION_LATENCY_LIMIT,
+	.owner			= THIS_MODULE,
+};
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+	return cpufreq_register_governor(&cpufreq_gov_lab);
+}
+
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+fs_initcall(cpufreq_gov_dbs_init);
+#else
+module_init(cpufreq_gov_dbs_init);
+#endif
-- 
1.7.10.4

[RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code

[Lukasz Majewski]

This patch adds code for LAB governor. It shall be noted, that it reuses
a lot of ondemand code.

The main difference is that it works on top of ondemand, and this code is
able to "call" ondemand when needed. This means that all ondemand "backing"
data are properly updated.

Such approach has one major advantage - with LAB we can focus on saving
energy and leave the "normal" cpufreq management to well tested ondemand.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Makefile      |    1 +
 drivers/cpufreq/cpufreq_lab.c |  457 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 458 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..64bff8dc 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)	+= cpufreq_powersave.o
 obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE)	+= cpufreq_userspace.o
 obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)	+= cpufreq_ondemand.o
 obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)	+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB)		+= cpufreq_lab.o
 obj-$(CONFIG_CPU_FREQ_GOV_COMMON)		+= cpufreq_governor.o
 
 obj-$(CONFIG_GENERIC_CPUFREQ_CPU0)	+= cpufreq-cpu0.o
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 0000000..153c06b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *		Jonghwa Lee <jonghw3.lee@samusng.com>
+ *		Lukasz Majewski <l.majewski@samsung.com>
+ *
+ * LAB (Legacy Application Boost) cpufreq governor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kernel_stat.h>
+#include <linux/kobject.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/percpu-defs.h>
+#include <linux/sysfs.h>
+#include <linux/tick.h>
+#include <linux/types.h>
+#include <linux/cpuidle.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+
+#include "cpufreq_governor.h"
+
+#define MAX_HIST		5
+
+#define LB_BOOST_ENABLE        ~0UL
+#define LB_MIN_FREQ            ~1UL
+#define LB_ONDEMAND             0
+
+/*
+ * Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int *idle_hist;
+static int idle_cpus, lb_threshold = 90;
+static unsigned int *lb_ctrl_table, lb_load;
+static int lb_ctrl_table_size, lb_num_of_states;
+static bool boost_init_state;
+
+static DECLARE_BITMAP(boost_hist, MAX_HIST);
+DECLARE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+
+struct cpufreq_governor cpufreq_gov_lab;
+
+
+static struct lb_wq_boost_data {
+	bool state;
+	struct work_struct work;
+} lb_boost_data;
+
+/*
+ * Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+	int i, sum;
+
+	for (i = 0, sum = 0; i < size; p++, i++) {
+		sum += *p;
+		*p >>= 1;
+	}
+	sum *= 100;
+
+	return (int) (sum / history_weight_sum[size - 1]);
+}
+
+static unsigned int lb_chose_freq(unsigned int load, int idle_cpus)
+{
+	unsigned int p, q = 100 / lb_num_of_states;
+	int idx;
+
+	for (idx = 0, p = q; idx < lb_num_of_states; idx++, p += q)
+		if (load <= p)
+			break;
+
+	return *(lb_ctrl_table + (lb_num_of_states * idle_cpus) + idx);
+}
+
+static void lb_cpufreq_boost_work(struct work_struct *work)
+{
+	struct lb_wq_boost_data *d = container_of(work,
+						  struct lb_wq_boost_data,
+						  work);
+	cpufreq_boost_trigger_state(d->state);
+}
+
+static struct common_dbs_data lb_dbs_cdata;
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load)
+{
+	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
+	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+	unsigned int freq = 0, op;
+	static int cnt;
+	int i, idx, bs;
+
+	idle_cpus = 0;
+	lb_load = load;
+	idx = cnt++ % MAX_HIST;
+
+	for_each_possible_cpu(i) {
+		struct od_cpu_dbs_info_s *dbs_cpu_info =
+			&per_cpu(od_cpu_dbs_info, i);
+
+		idle_hist[i * MAX_HIST + idx] = dbs_cpu_info->idle_time;
+		idle_avg[i] = cpu_idle_calc_avg(&idle_hist[i * MAX_HIST],
+					cnt < MAX_HIST ? cnt : MAX_HIST);
+
+		if (idle_avg[i] > lb_threshold)
+			idle_cpus++;
+	}
+
+	if (idle_cpus < 0 || idle_cpus > num_possible_cpus()) {
+		pr_warn("%s: idle_cpus: %d out of range\n", __func__,
+			idle_cpus);
+		return;
+	}
+
+	if (!lb_ctrl_table)
+		return;
+
+	op = lb_chose_freq(load, idle_cpus);
+	if (op == LB_BOOST_ENABLE)
+		set_bit(idx, boost_hist);
+	else
+		clear_bit(idx, boost_hist);
+
+	bs = cpufreq_boost_enabled();
+	/*
+	 * - To disable boost -
+	 *
+	 * Operation different than LB_BOOST_ENABLE is
+	 * required for at least MAX_HIST previous operations
+	 */
+	if (bs && bitmap_empty(boost_hist, MAX_HIST)) {
+		lb_boost_data.state = false;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	/*
+	 * - To enable boost -
+	 *
+	 * Only (MAX_HIST - 1) bits are required. This allows entering
+	 * BOOST mode earlier, since we skip one "round" of LAB operation
+	 * before work is executed.
+	 */
+	if (!bs &&
+	    (bitmap_weight(boost_hist, MAX_HIST) == (MAX_HIST - 1))) {
+		lb_boost_data.state = true;
+		schedule_work_on(cpu, &lb_boost_data.work);
+	}
+
+	switch (op) {
+	case LB_BOOST_ENABLE:
+		freq = policy->max;
+		break;
+
+	case LB_MIN_FREQ:
+		freq = policy->min;
+		break;
+
+	case LB_ONDEMAND:
+		od_check_cpu(cpu, load);
+		return;
+
+	default:
+		freq = op;
+	}
+
+	if (policy->cur == freq)
+		return;
+
+	__cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
+}
+
+static ssize_t show_load(struct kobject *kobj,
+			 struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_load);
+}
+define_one_global_ro(load);
+
+static ssize_t show_idle_cpus_num(struct kobject *kobj,
+				  struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", idle_cpus);
+}
+define_one_global_ro(idle_cpus_num);
+
+static ssize_t show_idle_avg_cpus_val(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	char off;
+	int i;
+
+	for (i = 0, off = 0; i < num_possible_cpus(); i++)
+		off += sprintf(buf + off, "%u ", idle_avg[i]);
+
+	*(buf + off - 1) = '\n';
+
+	return off;
+}
+define_one_global_ro(idle_avg_cpus_val);
+
+static ssize_t show_idle_threshold(struct kobject *kobj,
+				   struct attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", lb_threshold);
+}
+
+static ssize_t store_idle_threshold(struct kobject *a, struct attribute *b,
+				    const char *buf, size_t count)
+{
+	unsigned int val;
+	int ret;
+
+	ret = sscanf(buf, "%u", &val);
+	if (ret != 1)
+		return -EINVAL;
+
+	if (val < 0 || val > 100) {
+		pr_err("%s: Only value in a range 0 to 100 accepted\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	lb_threshold = val;
+	return count;
+}
+define_one_global_rw(idle_threshold);
+
+ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
+				   const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+	if (ret != 1)
+		return -EINVAL;
+
+	update_sampling_rate(dbs_data, input);
+	return count;
+}
+
+static ssize_t show_sampling_rate(struct kobject *kobj, struct attribute *attr,
+				  char *buf)
+{
+	struct od_dbs_tuners *tuners = lb_dbs_cdata.gdbs_data->tuners;
+
+	return sprintf(buf, "%u\n", tuners->sampling_rate);
+}
+define_one_global_rw(sampling_rate);
+
+static ssize_t show_sampling_rate_min(struct kobject *kobj,
+				      struct attribute *attr, char *buf)
+{
+	struct dbs_data *dbs_data = lb_dbs_cdata.gdbs_data;
+
+	return sprintf(buf, "%u\n", dbs_data->min_sampling_rate);
+}
+define_one_global_ro(sampling_rate_min);
+
+static struct attribute *dbs_attributes_gov_sys[] = {
+	&sampling_rate_min.attr,
+	&idle_avg_cpus_val.attr,
+	&idle_threshold.attr,
+	&idle_cpus_num.attr,
+	&sampling_rate.attr,
+	&load.attr,
+	NULL
+};
+
+static struct attribute_group lb_attr_group_gov_sys = {
+	.attrs = dbs_attributes_gov_sys,
+	.name = "lab",
+};
+
+static int lb_ctrl_table_of_init(struct device_node *dn,
+				 unsigned int **ctrl_tab, int size)
+{
+	struct property *pp;
+	int len;
+
+	pp = of_find_property(dn, "lab-ctrl-freq", &len);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-ctrl-freq'  not found\n", __func__);
+		return -ENODEV;
+	}
+
+	if (len != (size * sizeof(**ctrl_tab))) {
+		pr_err("%s: Wrong 'lab-ctrl-freq' size\n", __func__);
+		return -EINVAL;
+	}
+
+	*ctrl_tab = kzalloc(len, GFP_KERNEL);
+	if (!*ctrl_tab) {
+		pr_err("%s: Not enough memory for LAB control structure\n",
+		       __func__);
+		return -ENOMEM;
+	}
+
+	if (of_property_read_u32_array(dn, pp->name, *ctrl_tab, size)) {
+		pr_err("Property: %s cannot be read!\n", pp->name);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int lb_of_init(void)
+{
+	struct device_node *dn;
+	struct property *pp;
+	int ret;
+
+	dn = of_find_node_by_path("/cpus/cpu@0");
+	if (!dn) {
+		pr_err("%s: Node: '/cpus/cpu@0/' not found\n", __func__);
+		return -ENODEV;
+	}
+
+	pp = of_find_property(dn, "lab-num-of-states", NULL);
+	if (!pp) {
+		pr_err("%s: Property: 'lab-num-of-states'  not found\n",
+		       __func__);
+		ret = -ENODEV;
+		goto dn_err;
+	}
+	lb_num_of_states = be32_to_cpup(pp->value);
+
+	lb_ctrl_table_size = lb_num_of_states * (num_possible_cpus() + 1);
+	ret = lb_ctrl_table_of_init(dn, &lb_ctrl_table, lb_ctrl_table_size);
+	if (ret) {
+		kfree(lb_ctrl_table);
+		lb_ctrl_table = NULL;
+		pr_err("%s: Cannot parse LAB control structure from OF\n",
+		       __func__);
+		return ret;
+	}
+
+dn_err:
+	of_node_put(dn);
+	return ret;
+}
+
+static int lb_init(struct dbs_data *dbs_data)
+{
+	int ret;
+
+	idle_avg = kzalloc(num_possible_cpus() * sizeof(*idle_avg), GFP_KERNEL);
+	if (!idle_avg) {
+		pr_err("%s: Not enough memory", __func__);
+		return -ENOMEM;
+	}
+
+	idle_hist = kzalloc(num_possible_cpus() * MAX_HIST * sizeof(*idle_hist),
+			    GFP_KERNEL);
+	if (!idle_hist) {
+		pr_err("%s: Not enough memory", __func__);
+		ret = -ENOMEM;
+		goto err_idle_avg;
+	}
+
+	ret = lb_of_init();
+	if (ret)
+		goto err_idle_hist;
+
+	boost_init_state = cpufreq_boost_enabled();
+	if (boost_init_state)
+		cpufreq_boost_trigger_state(false);
+
+	od_init(dbs_data);
+
+	INIT_WORK(&lb_boost_data.work, lb_cpufreq_boost_work);
+
+	return 0;
+
+err_idle_hist:
+	kfree(idle_hist);
+err_idle_avg:
+	kfree(idle_avg);
+
+	return ret;
+}
+
+void lb_exit(struct dbs_data *dbs_data)
+{
+	od_exit(dbs_data);
+
+	kfree(lb_ctrl_table);
+	lb_ctrl_table = NULL;
+
+	cpufreq_boost_trigger_state(boost_init_state);
+
+	kfree(idle_avg);
+	kfree(idle_hist);
+}
+
+define_get_cpu_dbs_routines(od_cpu_dbs_info);
+
+static struct common_dbs_data lb_dbs_cdata = {
+	.governor = GOV_LAB,
+	.attr_group_gov_sys = &lb_attr_group_gov_sys,
+	.get_cpu_cdbs = get_cpu_cdbs,
+	.get_cpu_dbs_info_s = get_cpu_dbs_info_s,
+	.gov_dbs_timer = od_dbs_timer,
+	.gov_check_cpu = lb_check_cpu,
+	.gov_ops = &od_ops,
+	.init = lb_init,
+	.exit = lb_exit,
+};
+
+static int lb_cpufreq_governor_dbs(struct cpufreq_policy *policy,
+		unsigned int event)
+{
+	return cpufreq_governor_dbs(policy, &lb_dbs_cdata, event);
+}
+
+struct cpufreq_governor cpufreq_gov_lab = {
+	.name			= "lab",
+	.governor		= lb_cpufreq_governor_dbs,
+	.max_transition_latency = TRANSITION_LATENCY_LIMIT,
+	.owner			= THIS_MODULE,
+};
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+	return cpufreq_register_governor(&cpufreq_gov_lab);
+}
+
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_LAB
+fs_initcall(cpufreq_gov_dbs_init);
+#else
+module_init(cpufreq_gov_dbs_init);
+#endif
-- 
1.7.10.4

[RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig

[Lukasz Majewski]

Provide support for LAB governor for the Kbuild.

It is important to note, that LAB is not possible to be compiled in as
a module since we cannot assure (in the kernel) that backing ondemand
module will not be removed without notice to LAB.

For this reason the LAB can be only compiled into the kernel without
possibility to be compiled as a module.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Kconfig |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..3a870ea 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -102,6 +102,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
 	  Be aware that not all cpufreq drivers support the conservative
 	  governor. If unsure have a look at the help section of the
 	  driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_LAB
+	bool "lab"
+	select CPU_FREQ_GOV_LAB
+	select CPU_FREQ_GOV_PERFORMANCE
+	help
+	  Use the CPUFreq governor 'lab' as default. This allows
+	  you to get a full dynamic frequency capable system by simply
+	  loading your cpufreq low-level hardware driver.
+	  Be aware that not all cpufreq drivers support the lab governor.
+	  If unsure have a look at the help section of the driver.
+	  Fallback governor will be the performance governor.
 endchoice
 
 config CPU_FREQ_GOV_PERFORMANCE
@@ -183,6 +195,22 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+config CPU_FREQ_GOV_LAB
+	bool "'lab' cpufreq policy governor - ONDEMAND extension"
+	select CPU_FREQ_TABLE
+	select CPU_FREQ_GOV_COMMON
+	select CPU_FREQ_GOV_ONDEMAND
+	help
+	  'lab' - This driver adds a dynamic cpufreq policy governor.
+
+	  LAB governor shall be regarded as an extension of the ONDEMAND on
+	  platforms with very weak HW support for power management.
+
+	  LAB governor can be either compiled in or not. It is not possible to
+	  compile it as module because of explicit ONDEMAND dependency.
+
+	  If in doubt, say N.
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
-- 
1.7.10.4

[RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig

[Lukasz Majewski]

Provide support for LAB governor for the Kbuild.

It is important to note, that LAB is not possible to be compiled in as
a module since we cannot assure (in the kernel) that backing ondemand
module will not be removed without notice to LAB.

For this reason the LAB can be only compiled into the kernel without
possibility to be compiled as a module.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 drivers/cpufreq/Kconfig |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..3a870ea 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -102,6 +102,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
 	  Be aware that not all cpufreq drivers support the conservative
 	  governor. If unsure have a look at the help section of the
 	  driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_LAB
+	bool "lab"
+	select CPU_FREQ_GOV_LAB
+	select CPU_FREQ_GOV_PERFORMANCE
+	help
+	  Use the CPUFreq governor 'lab' as default. This allows
+	  you to get a full dynamic frequency capable system by simply
+	  loading your cpufreq low-level hardware driver.
+	  Be aware that not all cpufreq drivers support the lab governor.
+	  If unsure have a look at the help section of the driver.
+	  Fallback governor will be the performance governor.
 endchoice
 
 config CPU_FREQ_GOV_PERFORMANCE
@@ -183,6 +195,22 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 	  If in doubt, say N.
 
+config CPU_FREQ_GOV_LAB
+	bool "'lab' cpufreq policy governor - ONDEMAND extension"
+	select CPU_FREQ_TABLE
+	select CPU_FREQ_GOV_COMMON
+	select CPU_FREQ_GOV_ONDEMAND
+	help
+	  'lab' - This driver adds a dynamic cpufreq policy governor.
+
+	  LAB governor shall be regarded as an extension of the ONDEMAND on
+	  platforms with very weak HW support for power management.
+
+	  LAB governor can be either compiled in or not. It is not possible to
+	  compile it as module because of explicit ONDEMAND dependency.
+
+	  If in doubt, say N.
+
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
-- 
1.7.10.4

[RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

[Lukasz Majewski]

Adds LAB attributes to proper CPU0 node.
The lab-num-of-states attribute shows how many compartments will be used.
The LAB code is prepared to be more fine grained.

The lab-ctrl-freq defines how the LAB governor will be controlled:
	- 0xFFFFFFFE 		- use the minimal frequency
	- 0xFFFFFFFF 		- enable boost
	- non zero 		- set the frequency specified
	- zero		- use ondemand to specify output frequency

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..9eeeb38 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -511,6 +511,35 @@
 		};
 	};
 
+	cpus {
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			lab-num-of-states = <5>;
+			lab-ctrl-freq = < 0          0          0          1300000    1200000
+					  0          0          0          0          1300000
+					  0          0          0          0          0xFFFFFFFF
+					  0          0          0          0xFFFFFFFF 0xFFFFFFFF
+					  0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE
+				>;
+		};
+
+		cpu@1 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@2 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@3 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+	};
+
 	camera {
 		pinctrl-0 = <&cam_port_b_clk_active>;
 		pinctrl-names = "default";
-- 
1.7.10.4

[RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

[Lukasz Majewski]

Adds LAB attributes to proper CPU0 node.
The lab-num-of-states attribute shows how many compartments will be used.
The LAB code is prepared to be more fine grained.

The lab-ctrl-freq defines how the LAB governor will be controlled:
	- 0xFFFFFFFE 		- use the minimal frequency
	- 0xFFFFFFFF 		- enable boost
	- non zero 		- set the frequency specified
	- zero		- use ondemand to specify output frequency

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..9eeeb38 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -511,6 +511,35 @@
 		};
 	};
 
+	cpus {
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			lab-num-of-states = <5>;
+			lab-ctrl-freq = < 0          0          0          1300000    1200000
+					  0          0          0          0          1300000
+					  0          0          0          0          0xFFFFFFFF
+					  0          0          0          0xFFFFFFFF 0xFFFFFFFF
+					  0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE 0xFFFFFFFE
+				>;
+		};
+
+		cpu@1 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@2 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+
+		cpu@3 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+		};
+	};
+
 	camera {
 		pinctrl-0 = <&cam_port_b_clk_active>;
 		pinctrl-names = "default";
-- 
1.7.10.4

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Dear all,

> Despite this patch set is working and applicable on top of 3.14-rc5, 
> please regard it solely as a pure RFC.
> 
> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> 
> LAB short reminder:
> 
> LAB uses information about how many cores are in "idle" state (the
> core idleness is represented as the value between 0 and 100) and the
> overall load of the system (from 0 to 100) to decide about frequency
> to be set. It is extremely useful with SoCs like Exynos4412, which
> can set only one frequency for all cores.
> 
> Important design decisions:
> 
> - Reuse well established ondemand governor's internal code. To do this
>   I had to expose some previously static internal ondemand code. 
>   This allowed smaller LAB code when compared to previous version.
> 	
> - LAB works on top of ondemand, which means that one via device tree
>   attributes can specify if and when e.g. BOOST shall be enabled or
> if any particular frequency shall be imposed. For situation NOT
> important from the power consumption reduction viewpoint the ondemand
> is used to set proper frequency.
> 
> - It is only possible to either compile in or not the LAB into the
> kernel. There is no "M" option for Kconfig. It is done on purpose,
> since ondemand itself can be also compiled as a module and then it
> would be possible to remove ondemand when LAB is working on top of it.
> 
> - The LAB operation is specified (and thereof extendable) via device
> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> 
> 
> Problems:
> - How the governor will work for big.LITTLE systems (especially
> Global Task Scheduling).
> - Will there be agreement to expose internal ondemand code to be
> reused for more specialized governors.
> 
> Test HW:
> 	Exynos4412 - Trats2 board.
> Above patches were posted on top of Linux 3.14-rc5
> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> 

Any comments about those patches?

> Lukasz Majewski (5):
>   cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
>   cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to
> support LAB
>   cpufreq:LAB:lab Add LAB governor code
>   cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
>   cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
>  drivers/cpufreq/Kconfig                 |   28 ++
>  drivers/cpufreq/Makefile                |    1 +
>  drivers/cpufreq/cpufreq_governor.c      |    7 +
>  drivers/cpufreq/cpufreq_governor.h      |   12 +
>  drivers/cpufreq/cpufreq_lab.c           |  457
> +++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq_ondemand.c      |   24 +- 7 files changed,
> 550 insertions(+), 8 deletions(-) create mode 100644
> drivers/cpufreq/cpufreq_lab.c
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Dear all,

> Despite this patch set is working and applicable on top of 3.14-rc5, 
> please regard it solely as a pure RFC.
> 
> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> 
> LAB short reminder:
> 
> LAB uses information about how many cores are in "idle" state (the
> core idleness is represented as the value between 0 and 100) and the
> overall load of the system (from 0 to 100) to decide about frequency
> to be set. It is extremely useful with SoCs like Exynos4412, which
> can set only one frequency for all cores.
> 
> Important design decisions:
> 
> - Reuse well established ondemand governor's internal code. To do this
>   I had to expose some previously static internal ondemand code. 
>   This allowed smaller LAB code when compared to previous version.
> 	
> - LAB works on top of ondemand, which means that one via device tree
>   attributes can specify if and when e.g. BOOST shall be enabled or
> if any particular frequency shall be imposed. For situation NOT
> important from the power consumption reduction viewpoint the ondemand
> is used to set proper frequency.
> 
> - It is only possible to either compile in or not the LAB into the
> kernel. There is no "M" option for Kconfig. It is done on purpose,
> since ondemand itself can be also compiled as a module and then it
> would be possible to remove ondemand when LAB is working on top of it.
> 
> - The LAB operation is specified (and thereof extendable) via device
> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> 
> 
> Problems:
> - How the governor will work for big.LITTLE systems (especially
> Global Task Scheduling).
> - Will there be agreement to expose internal ondemand code to be
> reused for more specialized governors.
> 
> Test HW:
> 	Exynos4412 - Trats2 board.
> Above patches were posted on top of Linux 3.14-rc5
> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> 

Any comments about those patches?

> Lukasz Majewski (5):
>   cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
>   cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to
> support LAB
>   cpufreq:LAB:lab Add LAB governor code
>   cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
>   cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
>  drivers/cpufreq/Kconfig                 |   28 ++
>  drivers/cpufreq/Makefile                |    1 +
>  drivers/cpufreq/cpufreq_governor.c      |    7 +
>  drivers/cpufreq/cpufreq_governor.h      |   12 +
>  drivers/cpufreq/cpufreq_lab.c           |  457
> +++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq_ondemand.c      |   24 +- 7 files changed,
> 550 insertions(+), 8 deletions(-) create mode 100644
> drivers/cpufreq/cpufreq_lab.c
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Dear all,

> Despite this patch set is working and applicable on top of 3.14-rc5, 
> please regard it solely as a pure RFC.
> 
> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> 
> LAB short reminder:
> 
> LAB uses information about how many cores are in "idle" state (the
> core idleness is represented as the value between 0 and 100) and the
> overall load of the system (from 0 to 100) to decide about frequency
> to be set. It is extremely useful with SoCs like Exynos4412, which
> can set only one frequency for all cores.
> 
> Important design decisions:
> 
> - Reuse well established ondemand governor's internal code. To do this
>   I had to expose some previously static internal ondemand code. 
>   This allowed smaller LAB code when compared to previous version.
> 	
> - LAB works on top of ondemand, which means that one via device tree
>   attributes can specify if and when e.g. BOOST shall be enabled or
> if any particular frequency shall be imposed. For situation NOT
> important from the power consumption reduction viewpoint the ondemand
> is used to set proper frequency.
> 
> - It is only possible to either compile in or not the LAB into the
> kernel. There is no "M" option for Kconfig. It is done on purpose,
> since ondemand itself can be also compiled as a module and then it
> would be possible to remove ondemand when LAB is working on top of it.
> 
> - The LAB operation is specified (and thereof extendable) via device
> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> 
> 
> Problems:
> - How the governor will work for big.LITTLE systems (especially
> Global Task Scheduling).
> - Will there be agreement to expose internal ondemand code to be
> reused for more specialized governors.
> 
> Test HW:
> 	Exynos4412 - Trats2 board.
> Above patches were posted on top of Linux 3.14-rc5
> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> 

Any comments about those patches?

> Lukasz Majewski (5):
>   cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
>   cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to
> support LAB
>   cpufreq:LAB:lab Add LAB governor code
>   cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
>   cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
>  drivers/cpufreq/Kconfig                 |   28 ++
>  drivers/cpufreq/Makefile                |    1 +
>  drivers/cpufreq/cpufreq_governor.c      |    7 +
>  drivers/cpufreq/cpufreq_governor.h      |   12 +
>  drivers/cpufreq/cpufreq_lab.c           |  457
> +++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq_ondemand.c      |   24 +- 7 files changed,
> 550 insertions(+), 8 deletions(-) create mode 100644
> drivers/cpufreq/cpufreq_lab.c
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Despite this patch set is working and applicable on top of 3.14-rc5,
>> please regard it solely as a pure RFC.
>>
>> This patch provides support for LAB governor build on top of ondemand.
>> Previous version of LAB can be found here:
>> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>>
>> LAB short reminder:
>>
>> LAB uses information about how many cores are in "idle" state (the
>> core idleness is represented as the value between 0 and 100) and the
>> overall load of the system (from 0 to 100) to decide about frequency
>> to be set. It is extremely useful with SoCs like Exynos4412, which
>> can set only one frequency for all cores.
>>
>> Important design decisions:
>>
>> - Reuse well established ondemand governor's internal code. To do this
>>   I had to expose some previously static internal ondemand code.
>>   This allowed smaller LAB code when compared to previous version.
>>
>> - LAB works on top of ondemand, which means that one via device tree
>>   attributes can specify if and when e.g. BOOST shall be enabled or
>> if any particular frequency shall be imposed. For situation NOT
>> important from the power consumption reduction viewpoint the ondemand
>> is used to set proper frequency.
>>
>> - It is only possible to either compile in or not the LAB into the
>> kernel. There is no "M" option for Kconfig. It is done on purpose,
>> since ondemand itself can be also compiled as a module and then it
>> would be possible to remove ondemand when LAB is working on top of it.
>>
>> - The LAB operation is specified (and thereof extendable) via device
>> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
>>
>>
>> Problems:
>> - How the governor will work for big.LITTLE systems (especially
>> Global Task Scheduling).
>> - Will there be agreement to expose internal ondemand code to be
>> reused for more specialized governors.
>>
>> Test HW:
>>       Exynos4412 - Trats2 board.
>> Above patches were posted on top of Linux 3.14-rc5
>> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
>>
>
> Any comments about those patches?

Sorry for being late on reviewing these..

I tried to go through the patches but didn't looked at the minutest
of the details. Its been a long time when you first sent this patchset.
And the memories have corrupted by now :) ..

To get context back, can we discuss again the fundamentals behind
this new governor you are proposing. And then we can discuss about
it again, its pros/cons, etc..

I tried to go to earlier threads but I think we better do it again..

People are reluctant in getting another governor in and want to give
existing governors a try if possible.

So, please explain the basics behind your governor again and then
we can put our arguments again..

--
viresh

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Despite this patch set is working and applicable on top of 3.14-rc5,
>> please regard it solely as a pure RFC.
>>
>> This patch provides support for LAB governor build on top of ondemand.
>> Previous version of LAB can be found here:
>> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>>
>> LAB short reminder:
>>
>> LAB uses information about how many cores are in "idle" state (the
>> core idleness is represented as the value between 0 and 100) and the
>> overall load of the system (from 0 to 100) to decide about frequency
>> to be set. It is extremely useful with SoCs like Exynos4412, which
>> can set only one frequency for all cores.
>>
>> Important design decisions:
>>
>> - Reuse well established ondemand governor's internal code. To do this
>>   I had to expose some previously static internal ondemand code.
>>   This allowed smaller LAB code when compared to previous version.
>>
>> - LAB works on top of ondemand, which means that one via device tree
>>   attributes can specify if and when e.g. BOOST shall be enabled or
>> if any particular frequency shall be imposed. For situation NOT
>> important from the power consumption reduction viewpoint the ondemand
>> is used to set proper frequency.
>>
>> - It is only possible to either compile in or not the LAB into the
>> kernel. There is no "M" option for Kconfig. It is done on purpose,
>> since ondemand itself can be also compiled as a module and then it
>> would be possible to remove ondemand when LAB is working on top of it.
>>
>> - The LAB operation is specified (and thereof extendable) via device
>> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
>>
>>
>> Problems:
>> - How the governor will work for big.LITTLE systems (especially
>> Global Task Scheduling).
>> - Will there be agreement to expose internal ondemand code to be
>> reused for more specialized governors.
>>
>> Test HW:
>>       Exynos4412 - Trats2 board.
>> Above patches were posted on top of Linux 3.14-rc5
>> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
>>
>
> Any comments about those patches?

Sorry for being late on reviewing these..

I tried to go through the patches but didn't looked at the minutest
of the details. Its been a long time when you first sent this patchset.
And the memories have corrupted by now :) ..

To get context back, can we discuss again the fundamentals behind
this new governor you are proposing. And then we can discuss about
it again, its pros/cons, etc..

I tried to go to earlier threads but I think we better do it again..

People are reluctant in getting another governor in and want to give
existing governors a try if possible.

So, please explain the basics behind your governor again and then
we can put our arguments again..

--
viresh

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Despite this patch set is working and applicable on top of 3.14-rc5,
>> please regard it solely as a pure RFC.
>>
>> This patch provides support for LAB governor build on top of ondemand.
>> Previous version of LAB can be found here:
>> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>>
>> LAB short reminder:
>>
>> LAB uses information about how many cores are in "idle" state (the
>> core idleness is represented as the value between 0 and 100) and the
>> overall load of the system (from 0 to 100) to decide about frequency
>> to be set. It is extremely useful with SoCs like Exynos4412, which
>> can set only one frequency for all cores.
>>
>> Important design decisions:
>>
>> - Reuse well established ondemand governor's internal code. To do this
>>   I had to expose some previously static internal ondemand code.
>>   This allowed smaller LAB code when compared to previous version.
>>
>> - LAB works on top of ondemand, which means that one via device tree
>>   attributes can specify if and when e.g. BOOST shall be enabled or
>> if any particular frequency shall be imposed. For situation NOT
>> important from the power consumption reduction viewpoint the ondemand
>> is used to set proper frequency.
>>
>> - It is only possible to either compile in or not the LAB into the
>> kernel. There is no "M" option for Kconfig. It is done on purpose,
>> since ondemand itself can be also compiled as a module and then it
>> would be possible to remove ondemand when LAB is working on top of it.
>>
>> - The LAB operation is specified (and thereof extendable) via device
>> tree lab-ctrl-freq attribute defined at /cpus/cpu0.
>>
>>
>> Problems:
>> - How the governor will work for big.LITTLE systems (especially
>> Global Task Scheduling).
>> - Will there be agreement to expose internal ondemand code to be
>> reused for more specialized governors.
>>
>> Test HW:
>>       Exynos4412 - Trats2 board.
>> Above patches were posted on top of Linux 3.14-rc5
>> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
>>
>
> Any comments about those patches?

Sorry for being late on reviewing these..

I tried to go through the patches but didn't looked at the minutest
of the details. Its been a long time when you first sent this patchset.
And the memories have corrupted by now :) ..

To get context back, can we discuss again the fundamentals behind
this new governor you are proposing. And then we can discuss about
it again, its pros/cons, etc..

I tried to go to earlier threads but I think we better do it again..

People are reluctant in getting another governor in and want to give
existing governors a try if possible.

So, please explain the basics behind your governor again and then
we can put our arguments again..

--
viresh

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> wrote:
> >> Despite this patch set is working and applicable on top of
> >> 3.14-rc5, please regard it solely as a pure RFC.
> >>
> >> This patch provides support for LAB governor build on top of
> >> ondemand. Previous version of LAB can be found here:
> >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >>
> >> LAB short reminder:
> >>
> >> LAB uses information about how many cores are in "idle" state (the
> >> core idleness is represented as the value between 0 and 100) and
> >> the overall load of the system (from 0 to 100) to decide about
> >> frequency to be set. It is extremely useful with SoCs like
> >> Exynos4412, which can set only one frequency for all cores.
> >>
> >> Important design decisions:
> >>
> >> - Reuse well established ondemand governor's internal code. To do
> >> this I had to expose some previously static internal ondemand code.
> >>   This allowed smaller LAB code when compared to previous version.
> >>
> >> - LAB works on top of ondemand, which means that one via device
> >> tree attributes can specify if and when e.g. BOOST shall be
> >> enabled or if any particular frequency shall be imposed. For
> >> situation NOT important from the power consumption reduction
> >> viewpoint the ondemand is used to set proper frequency.
> >>
> >> - It is only possible to either compile in or not the LAB into the
> >> kernel. There is no "M" option for Kconfig. It is done on purpose,
> >> since ondemand itself can be also compiled as a module and then it
> >> would be possible to remove ondemand when LAB is working on top of
> >> it.
> >>
> >> - The LAB operation is specified (and thereof extendable) via
> >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> >>
> >>
> >> Problems:
> >> - How the governor will work for big.LITTLE systems (especially
> >> Global Task Scheduling).
> >> - Will there be agreement to expose internal ondemand code to be
> >> reused for more specialized governors.
> >>
> >> Test HW:
> >>       Exynos4412 - Trats2 board.
> >> Above patches were posted on top of Linux 3.14-rc5
> >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> >>
> >
> > Any comments about those patches?
> 
> Sorry for being late on reviewing these..
> 
> I tried to go through the patches but didn't looked at the minutest
> of the details. Its been a long time when you first sent this
> patchset. And the memories have corrupted by now :) ..

Unfortunately memory is volatile ... since LAB governor is a follow up
of BOOST, which review and inclusion took considerable time, some
details could be forgotten. 

> 
> To get context back, can we discuss again the fundamentals behind
> this new governor you are proposing. And then we can discuss about
> it again, its pros/cons, etc..

Please consider following links:

The original implementation - threads:
http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab


LAB justification data:
http://article.gmane.org/gmane.linux.kernel/1472381


> People are reluctant in getting another governor in and want to give
> existing governors a try if possible.

As I've stated in the covering letter, this code is an extension of
Ondemand.

This is totally different from what have been posted previously (v1,
v2).
The first LAB proposal was written with some parts copied from Ondemand.
It was a separate, standalone governor.


The approach proposed in those patches is very different. It simply
reuses Ondemand code as much as possible (timers, default attributes
exported to sysfs, etc.).

On top of the Ondemand we have the LAB, which thereof is its optional
extension. The existing code is reused and can be easily extracted as a
common code.

> 
> So, please explain the basics behind your governor again and then
> we can put our arguments again..
> 

I hope that provided overview is sufficient. More in depth
information can be found in posted patches or provided LKML archives.

> --
> viresh

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> wrote:
> >> Despite this patch set is working and applicable on top of
> >> 3.14-rc5, please regard it solely as a pure RFC.
> >>
> >> This patch provides support for LAB governor build on top of
> >> ondemand. Previous version of LAB can be found here:
> >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >>
> >> LAB short reminder:
> >>
> >> LAB uses information about how many cores are in "idle" state (the
> >> core idleness is represented as the value between 0 and 100) and
> >> the overall load of the system (from 0 to 100) to decide about
> >> frequency to be set. It is extremely useful with SoCs like
> >> Exynos4412, which can set only one frequency for all cores.
> >>
> >> Important design decisions:
> >>
> >> - Reuse well established ondemand governor's internal code. To do
> >> this I had to expose some previously static internal ondemand code.
> >>   This allowed smaller LAB code when compared to previous version.
> >>
> >> - LAB works on top of ondemand, which means that one via device
> >> tree attributes can specify if and when e.g. BOOST shall be
> >> enabled or if any particular frequency shall be imposed. For
> >> situation NOT important from the power consumption reduction
> >> viewpoint the ondemand is used to set proper frequency.
> >>
> >> - It is only possible to either compile in or not the LAB into the
> >> kernel. There is no "M" option for Kconfig. It is done on purpose,
> >> since ondemand itself can be also compiled as a module and then it
> >> would be possible to remove ondemand when LAB is working on top of
> >> it.
> >>
> >> - The LAB operation is specified (and thereof extendable) via
> >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> >>
> >>
> >> Problems:
> >> - How the governor will work for big.LITTLE systems (especially
> >> Global Task Scheduling).
> >> - Will there be agreement to expose internal ondemand code to be
> >> reused for more specialized governors.
> >>
> >> Test HW:
> >>       Exynos4412 - Trats2 board.
> >> Above patches were posted on top of Linux 3.14-rc5
> >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> >>
> >
> > Any comments about those patches?
> 
> Sorry for being late on reviewing these..
> 
> I tried to go through the patches but didn't looked at the minutest
> of the details. Its been a long time when you first sent this
> patchset. And the memories have corrupted by now :) ..

Unfortunately memory is volatile ... since LAB governor is a follow up
of BOOST, which review and inclusion took considerable time, some
details could be forgotten. 

> 
> To get context back, can we discuss again the fundamentals behind
> this new governor you are proposing. And then we can discuss about
> it again, its pros/cons, etc..

Please consider following links:

The original implementation - threads:
http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab


LAB justification data:
http://article.gmane.org/gmane.linux.kernel/1472381


> People are reluctant in getting another governor in and want to give
> existing governors a try if possible.

As I've stated in the covering letter, this code is an extension of
Ondemand.

This is totally different from what have been posted previously (v1,
v2).
The first LAB proposal was written with some parts copied from Ondemand.
It was a separate, standalone governor.


The approach proposed in those patches is very different. It simply
reuses Ondemand code as much as possible (timers, default attributes
exported to sysfs, etc.).

On top of the Ondemand we have the LAB, which thereof is its optional
extension. The existing code is reused and can be easily extracted as a
common code.

> 
> So, please explain the basics behind your governor again and then
> we can put our arguments again..
> 

I hope that provided overview is sufficient. More in depth
information can be found in posted patches or provided LKML archives.

> --
> viresh

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> wrote:
> >> Despite this patch set is working and applicable on top of
> >> 3.14-rc5, please regard it solely as a pure RFC.
> >>
> >> This patch provides support for LAB governor build on top of
> >> ondemand. Previous version of LAB can be found here:
> >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >>
> >> LAB short reminder:
> >>
> >> LAB uses information about how many cores are in "idle" state (the
> >> core idleness is represented as the value between 0 and 100) and
> >> the overall load of the system (from 0 to 100) to decide about
> >> frequency to be set. It is extremely useful with SoCs like
> >> Exynos4412, which can set only one frequency for all cores.
> >>
> >> Important design decisions:
> >>
> >> - Reuse well established ondemand governor's internal code. To do
> >> this I had to expose some previously static internal ondemand code.
> >>   This allowed smaller LAB code when compared to previous version.
> >>
> >> - LAB works on top of ondemand, which means that one via device
> >> tree attributes can specify if and when e.g. BOOST shall be
> >> enabled or if any particular frequency shall be imposed. For
> >> situation NOT important from the power consumption reduction
> >> viewpoint the ondemand is used to set proper frequency.
> >>
> >> - It is only possible to either compile in or not the LAB into the
> >> kernel. There is no "M" option for Kconfig. It is done on purpose,
> >> since ondemand itself can be also compiled as a module and then it
> >> would be possible to remove ondemand when LAB is working on top of
> >> it.
> >>
> >> - The LAB operation is specified (and thereof extendable) via
> >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> >>
> >>
> >> Problems:
> >> - How the governor will work for big.LITTLE systems (especially
> >> Global Task Scheduling).
> >> - Will there be agreement to expose internal ondemand code to be
> >> reused for more specialized governors.
> >>
> >> Test HW:
> >>       Exynos4412 - Trats2 board.
> >> Above patches were posted on top of Linux 3.14-rc5
> >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> >>
> >
> > Any comments about those patches?
> 
> Sorry for being late on reviewing these..
> 
> I tried to go through the patches but didn't looked at the minutest
> of the details. Its been a long time when you first sent this
> patchset. And the memories have corrupted by now :) ..

Unfortunately memory is volatile ... since LAB governor is a follow up
of BOOST, which review and inclusion took considerable time, some
details could be forgotten. 

> 
> To get context back, can we discuss again the fundamentals behind
> this new governor you are proposing. And then we can discuss about
> it again, its pros/cons, etc..

Please consider following links:

The original implementation - threads:
http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab


LAB justification data:
http://article.gmane.org/gmane.linux.kernel/1472381


> People are reluctant in getting another governor in and want to give
> existing governors a try if possible.

As I've stated in the covering letter, this code is an extension of
Ondemand.

This is totally different from what have been posted previously (v1,
v2).
The first LAB proposal was written with some parts copied from Ondemand.
It was a separate, standalone governor.


The approach proposed in those patches is very different. It simply
reuses Ondemand code as much as possible (timers, default attributes
exported to sysfs, etc.).

On top of the Ondemand we have the LAB, which thereof is its optional
extension. The existing code is reused and can be easily extracted as a
common code.

> 
> So, please explain the basics behind your governor again and then
> we can put our arguments again..
> 

I hope that provided overview is sufficient. More in depth
information can be found in posted patches or provided LKML archives.

> --
> viresh

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> Despite this patch set is working and applicable on top of
> > >> 3.14-rc5, please regard it solely as a pure RFC.
> > >>
> > >> This patch provides support for LAB governor build on top of
> > >> ondemand. Previous version of LAB can be found here:
> > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >>
> > >> LAB short reminder:
> > >>
> > >> LAB uses information about how many cores are in "idle" state
> > >> (the core idleness is represented as the value between 0 and
> > >> 100) and the overall load of the system (from 0 to 100) to
> > >> decide about frequency to be set. It is extremely useful with
> > >> SoCs like Exynos4412, which can set only one frequency for all
> > >> cores.
> > >>
> > >> Important design decisions:
> > >>
> > >> - Reuse well established ondemand governor's internal code. To do
> > >> this I had to expose some previously static internal ondemand
> > >> code. This allowed smaller LAB code when compared to previous
> > >> version.
> > >>
> > >> - LAB works on top of ondemand, which means that one via device
> > >> tree attributes can specify if and when e.g. BOOST shall be
> > >> enabled or if any particular frequency shall be imposed. For
> > >> situation NOT important from the power consumption reduction
> > >> viewpoint the ondemand is used to set proper frequency.
> > >>
> > >> - It is only possible to either compile in or not the LAB into
> > >> the kernel. There is no "M" option for Kconfig. It is done on
> > >> purpose, since ondemand itself can be also compiled as a module
> > >> and then it would be possible to remove ondemand when LAB is
> > >> working on top of it.
> > >>
> > >> - The LAB operation is specified (and thereof extendable) via
> > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> > >>
> > >>
> > >> Problems:
> > >> - How the governor will work for big.LITTLE systems (especially
> > >> Global Task Scheduling).
> > >> - Will there be agreement to expose internal ondemand code to be
> > >> reused for more specialized governors.
> > >>
> > >> Test HW:
> > >>       Exynos4412 - Trats2 board.
> > >> Above patches were posted on top of Linux 3.14-rc5
> > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> > >>
> > >
> > > Any comments about those patches?
> > 
> > Sorry for being late on reviewing these..
> > 
> > I tried to go through the patches but didn't looked at the minutest
> > of the details. Its been a long time when you first sent this
> > patchset. And the memories have corrupted by now :) ..
> 
> Unfortunately memory is volatile ... since LAB governor is a follow up
> of BOOST, which review and inclusion took considerable time, some
> details could be forgotten. 
> 
> > 
> > To get context back, can we discuss again the fundamentals behind
> > this new governor you are proposing. And then we can discuss about
> > it again, its pros/cons, etc..
> 
> Please consider following links:
> 
> The original implementation - threads:
> http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab
> 
> 
> LAB justification data:
> http://article.gmane.org/gmane.linux.kernel/1472381
> 
> 
> > People are reluctant in getting another governor in and want to give
> > existing governors a try if possible.
> 
> As I've stated in the covering letter, this code is an extension of
> Ondemand.
> 
> This is totally different from what have been posted previously (v1,
> v2).
> The first LAB proposal was written with some parts copied from
> Ondemand. It was a separate, standalone governor.
> 
> 
> The approach proposed in those patches is very different. It simply
> reuses Ondemand code as much as possible (timers, default attributes
> exported to sysfs, etc.).
> 
> On top of the Ondemand we have the LAB, which thereof is its optional
> extension. The existing code is reused and can be easily extracted as
> a common code.
> 
> > 
> > So, please explain the basics behind your governor again and then
> > we can put our arguments again..
> > 
> 
> I hope that provided overview is sufficient. More in depth
> information can be found in posted patches or provided LKML archives.
> 

Viresh, will you find time for reviewing this RFC in a near future?

> > --
> > viresh
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> Despite this patch set is working and applicable on top of
> > >> 3.14-rc5, please regard it solely as a pure RFC.
> > >>
> > >> This patch provides support for LAB governor build on top of
> > >> ondemand. Previous version of LAB can be found here:
> > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >>
> > >> LAB short reminder:
> > >>
> > >> LAB uses information about how many cores are in "idle" state
> > >> (the core idleness is represented as the value between 0 and
> > >> 100) and the overall load of the system (from 0 to 100) to
> > >> decide about frequency to be set. It is extremely useful with
> > >> SoCs like Exynos4412, which can set only one frequency for all
> > >> cores.
> > >>
> > >> Important design decisions:
> > >>
> > >> - Reuse well established ondemand governor's internal code. To do
> > >> this I had to expose some previously static internal ondemand
> > >> code. This allowed smaller LAB code when compared to previous
> > >> version.
> > >>
> > >> - LAB works on top of ondemand, which means that one via device
> > >> tree attributes can specify if and when e.g. BOOST shall be
> > >> enabled or if any particular frequency shall be imposed. For
> > >> situation NOT important from the power consumption reduction
> > >> viewpoint the ondemand is used to set proper frequency.
> > >>
> > >> - It is only possible to either compile in or not the LAB into
> > >> the kernel. There is no "M" option for Kconfig. It is done on
> > >> purpose, since ondemand itself can be also compiled as a module
> > >> and then it would be possible to remove ondemand when LAB is
> > >> working on top of it.
> > >>
> > >> - The LAB operation is specified (and thereof extendable) via
> > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> > >>
> > >>
> > >> Problems:
> > >> - How the governor will work for big.LITTLE systems (especially
> > >> Global Task Scheduling).
> > >> - Will there be agreement to expose internal ondemand code to be
> > >> reused for more specialized governors.
> > >>
> > >> Test HW:
> > >>       Exynos4412 - Trats2 board.
> > >> Above patches were posted on top of Linux 3.14-rc5
> > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> > >>
> > >
> > > Any comments about those patches?
> > 
> > Sorry for being late on reviewing these..
> > 
> > I tried to go through the patches but didn't looked at the minutest
> > of the details. Its been a long time when you first sent this
> > patchset. And the memories have corrupted by now :) ..
> 
> Unfortunately memory is volatile ... since LAB governor is a follow up
> of BOOST, which review and inclusion took considerable time, some
> details could be forgotten. 
> 
> > 
> > To get context back, can we discuss again the fundamentals behind
> > this new governor you are proposing. And then we can discuss about
> > it again, its pros/cons, etc..
> 
> Please consider following links:
> 
> The original implementation - threads:
> http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab
> 
> 
> LAB justification data:
> http://article.gmane.org/gmane.linux.kernel/1472381
> 
> 
> > People are reluctant in getting another governor in and want to give
> > existing governors a try if possible.
> 
> As I've stated in the covering letter, this code is an extension of
> Ondemand.
> 
> This is totally different from what have been posted previously (v1,
> v2).
> The first LAB proposal was written with some parts copied from
> Ondemand. It was a separate, standalone governor.
> 
> 
> The approach proposed in those patches is very different. It simply
> reuses Ondemand code as much as possible (timers, default attributes
> exported to sysfs, etc.).
> 
> On top of the Ondemand we have the LAB, which thereof is its optional
> extension. The existing code is reused and can be easily extracted as
> a common code.
> 
> > 
> > So, please explain the basics behind your governor again and then
> > we can put our arguments again..
> > 
> 
> I hope that provided overview is sufficient. More in depth
> information can be found in posted patches or provided LKML archives.
> 

Viresh, will you find time for reviewing this RFC in a near future?

> > --
> > viresh
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@samsung.com>
> > wrote:
> > >> Despite this patch set is working and applicable on top of
> > >> 3.14-rc5, please regard it solely as a pure RFC.
> > >>
> > >> This patch provides support for LAB governor build on top of
> > >> ondemand. Previous version of LAB can be found here:
> > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >>
> > >> LAB short reminder:
> > >>
> > >> LAB uses information about how many cores are in "idle" state
> > >> (the core idleness is represented as the value between 0 and
> > >> 100) and the overall load of the system (from 0 to 100) to
> > >> decide about frequency to be set. It is extremely useful with
> > >> SoCs like Exynos4412, which can set only one frequency for all
> > >> cores.
> > >>
> > >> Important design decisions:
> > >>
> > >> - Reuse well established ondemand governor's internal code. To do
> > >> this I had to expose some previously static internal ondemand
> > >> code. This allowed smaller LAB code when compared to previous
> > >> version.
> > >>
> > >> - LAB works on top of ondemand, which means that one via device
> > >> tree attributes can specify if and when e.g. BOOST shall be
> > >> enabled or if any particular frequency shall be imposed. For
> > >> situation NOT important from the power consumption reduction
> > >> viewpoint the ondemand is used to set proper frequency.
> > >>
> > >> - It is only possible to either compile in or not the LAB into
> > >> the kernel. There is no "M" option for Kconfig. It is done on
> > >> purpose, since ondemand itself can be also compiled as a module
> > >> and then it would be possible to remove ondemand when LAB is
> > >> working on top of it.
> > >>
> > >> - The LAB operation is specified (and thereof extendable) via
> > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> > >>
> > >>
> > >> Problems:
> > >> - How the governor will work for big.LITTLE systems (especially
> > >> Global Task Scheduling).
> > >> - Will there be agreement to expose internal ondemand code to be
> > >> reused for more specialized governors.
> > >>
> > >> Test HW:
> > >>       Exynos4412 - Trats2 board.
> > >> Above patches were posted on top of Linux 3.14-rc5
> > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> > >>
> > >
> > > Any comments about those patches?
> > 
> > Sorry for being late on reviewing these..
> > 
> > I tried to go through the patches but didn't looked at the minutest
> > of the details. Its been a long time when you first sent this
> > patchset. And the memories have corrupted by now :) ..
> 
> Unfortunately memory is volatile ... since LAB governor is a follow up
> of BOOST, which review and inclusion took considerable time, some
> details could be forgotten. 
> 
> > 
> > To get context back, can we discuss again the fundamentals behind
> > this new governor you are proposing. And then we can discuss about
> > it again, its pros/cons, etc..
> 
> Please consider following links:
> 
> The original implementation - threads:
> http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab
> 
> 
> LAB justification data:
> http://article.gmane.org/gmane.linux.kernel/1472381
> 
> 
> > People are reluctant in getting another governor in and want to give
> > existing governors a try if possible.
> 
> As I've stated in the covering letter, this code is an extension of
> Ondemand.
> 
> This is totally different from what have been posted previously (v1,
> v2).
> The first LAB proposal was written with some parts copied from
> Ondemand. It was a separate, standalone governor.
> 
> 
> The approach proposed in those patches is very different. It simply
> reuses Ondemand code as much as possible (timers, default attributes
> exported to sysfs, etc.).
> 
> On top of the Ondemand we have the LAB, which thereof is its optional
> extension. The existing code is reused and can be easily extracted as
> a common code.
> 
> > 
> > So, please explain the basics behind your governor again and then
> > we can put our arguments again..
> > 
> 
> I hope that provided overview is sufficient. More in depth
> information can be found in posted patches or provided LKML archives.
> 

Viresh, will you find time for reviewing this RFC in a near future?

> > --
> > viresh
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 24 March 2014 12:17, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Viresh, will you find time for reviewing this RFC in a near future?

Yes. I have been trying hard last week but couldn't find some time
for it. Will try this week for sure.. Sorry to keep you waiting :(

@Rafael: Please see if you can also give them a look..

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 24 March 2014 12:17, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Viresh, will you find time for reviewing this RFC in a near future?

Yes. I have been trying hard last week but couldn't find some time
for it. Will try this week for sure.. Sorry to keep you waiting :(

@Rafael: Please see if you can also give them a look..

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 24 March 2014 12:17, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Viresh, will you find time for reviewing this RFC in a near future?

Yes. I have been trying hard last week but couldn't find some time
for it. Will try this week for sure.. Sorry to keep you waiting :(

@Rafael: Please see if you can also give them a look..

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.

Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fresh mind.
i.e. with zero memories of earlier discussions :)

LAB was: Legacy Application Boost ??

Probably mention that in your new threads as well, so that new readers
know the details. Also, like other governors, just name it "boost" governor.

> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> LAB short reminder:
>
> LAB uses information about how many cores are in "idle" state (the core
> idleness is represented as the value between 0 and 100) and the overall
> load of the system (from 0 to 100) to decide about frequency to be set.
> It is extremely useful with SoCs like Exynos4412, which can set only one
> frequency for all cores.

Probably a description of how exactly these two values come into play
would have been more interesting here for all. Always think of new followers
of your patchset and so add all interesting things about it when you resend
it.

If I remember well the logic was more or less like this:
- More idle cores means run few running cores at high frequency
- Less idle cores means don't run them at very high frequencies

Right?

What about making it as simple as:
- changing the ondemand governor only instead of adding a new governor
- Keeping the bahavior as is for all platforms not publishing boost frequencies
- If more cores are idle, enable switching to boost frequencies and take them
into consideration all the time.
- If less cores are idle, disable boost frequencies..

Lets discuss this first and then I will get into the very details of your
implementation.

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.

Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fresh mind.
i.e. with zero memories of earlier discussions :)

LAB was: Legacy Application Boost ??

Probably mention that in your new threads as well, so that new readers
know the details. Also, like other governors, just name it "boost" governor.

> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> LAB short reminder:
>
> LAB uses information about how many cores are in "idle" state (the core
> idleness is represented as the value between 0 and 100) and the overall
> load of the system (from 0 to 100) to decide about frequency to be set.
> It is extremely useful with SoCs like Exynos4412, which can set only one
> frequency for all cores.

Probably a description of how exactly these two values come into play
would have been more interesting here for all. Always think of new followers
of your patchset and so add all interesting things about it when you resend
it.

If I remember well the logic was more or less like this:
- More idle cores means run few running cores at high frequency
- Less idle cores means don't run them at very high frequencies

Right?

What about making it as simple as:
- changing the ondemand governor only instead of adding a new governor
- Keeping the bahavior as is for all platforms not publishing boost frequencies
- If more cores are idle, enable switching to boost frequencies and take them
into consideration all the time.
- If less cores are idle, disable boost frequencies..

Lets discuss this first and then I will get into the very details of your
implementation.

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.

Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fresh mind.
i.e. with zero memories of earlier discussions :)

LAB was: Legacy Application Boost ??

Probably mention that in your new threads as well, so that new readers
know the details. Also, like other governors, just name it "boost" governor.

> This patch provides support for LAB governor build on top of ondemand.
> Previous version of LAB can be found here:
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
>
> LAB short reminder:
>
> LAB uses information about how many cores are in "idle" state (the core
> idleness is represented as the value between 0 and 100) and the overall
> load of the system (from 0 to 100) to decide about frequency to be set.
> It is extremely useful with SoCs like Exynos4412, which can set only one
> frequency for all cores.

Probably a description of how exactly these two values come into play
would have been more interesting here for all. Always think of new followers
of your patchset and so add all interesting things about it when you resend
it.

If I remember well the logic was more or less like this:
- More idle cores means run few running cores at high frequency
- Less idle cores means don't run them at very high frequencies

Right?

What about making it as simple as:
- changing the ondemand governor only instead of adding a new governor
- Keeping the bahavior as is for all platforms not publishing boost frequencies
- If more cores are idle, enable switching to boost frequencies and take them
into consideration all the time.
- If less cores are idle, disable boost frequencies..

Lets discuss this first and then I will get into the very details of your
implementation.

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
> 
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
> 
> LAB was: Legacy Application Boost ??

Yes, correct.

> 
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.

I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.

> 
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
> 
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
> 
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
> 
> Right?

This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.

> 
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor

My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.

> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies

This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.

> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.

I'm not sure if I have understood you, but something like that is also
performed in the code.

> - If less cores are idle, disable boost frequencies..

As written above.

> 
> Lets discuss this first and then I will get into the very details of
> your implementation.

Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
> 
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
> 
> LAB was: Legacy Application Boost ??

Yes, correct.

> 
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.

I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.

> 
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
> 
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
> 
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
> 
> Right?

This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.

> 
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor

My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.

> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies

This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.

> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.

I'm not sure if I have understood you, but something like that is also
performed in the code.

> - If less cores are idle, disable boost frequencies..

As written above.

> 
> Lets discuss this first and then I will get into the very details of
> your implementation.

Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
> 
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
> 
> LAB was: Legacy Application Boost ??

Yes, correct.

> 
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.

I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.

> 
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
> 
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
> 
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
> 
> Right?

This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.

> 
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor

My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.

> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies

This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.

> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.

I'm not sure if I have understood you, but something like that is also
performed in the code.

> - If less cores are idle, disable boost frequencies..

As written above.

> 
> Lets discuss this first and then I will get into the very details of
> your implementation.

Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]

On 24 March 2014 15:30, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:

> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.

It doesn't matter with Mainline how you do naming initially for your code :)
We need to pick the right name now, and the decision should be made
now (after discussions obviously) :)

>> What about making it as simple as:
>> - changing the ondemand governor only instead of adding a new governor
>
> My goal is to not touch the ondemand code. It has matured, so I would
> like to leave it as it is.

Because the boost feature is already part of CPUFreq core, I think its
better if we enhance current governors to use it. So, I would like to
make this part of existing governors. Not only ondemand but maybe
conservative as well..

Also, I feel we maynot necessarily move this piece of code into cpufreq.
All you are doing is thermal management here :)

If we are sure we will not burn out our SoC (When many cores are idle),
run at max freq (if there is enough load of course :))..

And if there are chances that we might burn our chip (when very few
cores are idle), don't run on boost frequencies..

This is actually a 'cooling' device :)

Think of it this way: CPUFreq will provide a range of frequency which
SoC's can use. And then based on some conditions we may or may not
want to run on these frequencies.

@Zhang/Eduardo: Can we have your inputs here as well ?

This may look hard but we need to design things in the best possible
way for managing things better in future. Lets see what others have
to say on this.

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]

On 24 March 2014 15:30, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:

> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.

It doesn't matter with Mainline how you do naming initially for your code :)
We need to pick the right name now, and the decision should be made
now (after discussions obviously) :)

>> What about making it as simple as:
>> - changing the ondemand governor only instead of adding a new governor
>
> My goal is to not touch the ondemand code. It has matured, so I would
> like to leave it as it is.

Because the boost feature is already part of CPUFreq core, I think its
better if we enhance current governors to use it. So, I would like to
make this part of existing governors. Not only ondemand but maybe
conservative as well..

Also, I feel we maynot necessarily move this piece of code into cpufreq.
All you are doing is thermal management here :)

If we are sure we will not burn out our SoC (When many cores are idle),
run at max freq (if there is enough load of course :))..

And if there are chances that we might burn our chip (when very few
cores are idle), don't run on boost frequencies..

This is actually a 'cooling' device :)

Think of it this way: CPUFreq will provide a range of frequency which
SoC's can use. And then based on some conditions we may or may not
want to run on these frequencies.

@Zhang/Eduardo: Can we have your inputs here as well ?

This may look hard but we need to design things in the best possible
way for managing things better in future. Lets see what others have
to say on this.

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]

On 24 March 2014 15:30, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:

> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.

It doesn't matter with Mainline how you do naming initially for your code :)
We need to pick the right name now, and the decision should be made
now (after discussions obviously) :)

>> What about making it as simple as:
>> - changing the ondemand governor only instead of adding a new governor
>
> My goal is to not touch the ondemand code. It has matured, so I would
> like to leave it as it is.

Because the boost feature is already part of CPUFreq core, I think its
better if we enhance current governors to use it. So, I would like to
make this part of existing governors. Not only ondemand but maybe
conservative as well..

Also, I feel we maynot necessarily move this piece of code into cpufreq.
All you are doing is thermal management here :)

If we are sure we will not burn out our SoC (When many cores are idle),
run at max freq (if there is enough load of course :))..

And if there are chances that we might burn our chip (when very few
cores are idle), don't run on boost frequencies..

This is actually a 'cooling' device :)

Think of it this way: CPUFreq will provide a range of frequency which
SoC's can use. And then based on some conditions we may or may not
want to run on these frequencies.

@Zhang/Eduardo: Can we have your inputs here as well ?

This may look hard but we need to design things in the best possible
way for managing things better in future. Lets see what others have
to say on this.