2013-05-03 14:08:03

by Jonghwa Lee

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

From: Lukasz Majewski <[email protected]>

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

2013-05-03 14:08:07

by Jonghwa Lee

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

From: Lukasz Majewski <[email protected]>

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

2013-05-03 14:08:37

by Jonghwa Lee

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

From: Lukasz Majewski <[email protected]>

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

2013-05-03 14:08:56

by Jonghwa Lee

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

From: Lukasz Majewski <[email protected]>

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 <[email protected]>
Signed-off-by: Lukasz Majewski <[email protected]>
Signed-off-by: Myungjoo Ham <[email protected]>
---
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 <[email protected]>
+ * Lukasz Majewski <[email protected]>
+ *
+ * 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 <[email protected]>");
+MODULE_AUTHOR("Lukasz Majewski <[email protected]>");
+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

2013-05-22 09:07:36

by Viresh Kumar

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

On 3 May 2013 19:37, Jonghwa Lee <[email protected]> wrote:
> From: Lukasz Majewski <[email protected]>

> 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

2013-05-22 10:27:27

by Lukasz Majewski

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

Hi Viresh,

Thanks for reply.

> On 3 May 2013 19:37, Jonghwa Lee <[email protected]> wrote:
> > From: Lukasz Majewski <[email protected]>
>
> > 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

2013-05-22 11:16:35

by Viresh Kumar

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

On 22 May 2013 15:57, Lukasz Majewski <[email protected]> wrote:
>> On 3 May 2013 19:37, Jonghwa Lee <[email protected]> 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...

2013-05-22 12:06:10

by Lukasz Majewski

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

Hi Viresh,

> On 22 May 2013 15:57, Lukasz Majewski <[email protected]> wrote:
> >> On 3 May 2013 19:37, Jonghwa Lee <[email protected]> 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

2013-05-22 14:45:12

by Lukasz Majewski

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

Hi Viresh,

> On 22 May 2013 15:57, Lukasz Majewski <[email protected]> wrote:
> >> On 3 May 2013 19:37, Jonghwa Lee <[email protected]> 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

Attachments:

2013-05-24 05:56:51

by Lukasz Majewski

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

Hi Viresh,

>
> > On 22 May 2013 15:57, Lukasz Majewski <[email protected]>
> > wrote:
> > >> On 3 May 2013 19:37, Jonghwa Lee <[email protected]>
> > >> 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

2013-05-24 07:52:18

by Viresh Kumar

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

On 24 May 2013 11:26, Lukasz Majewski <[email protected]> wrote:
>> > On 22 May 2013 15:57, Lukasz Majewski <[email protected]>
> 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?

2013-05-24 08:16:36

by MyungJoo Ham

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

> On 24 May 2013 11:26, Lukasz Majewski <[email protected]> wrote:
> >> > On 22 May 2013 15:57, Lukasz Majewski <[email protected]>
> > 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?


It is because we cannot use the frequency if there are more running cores.
We can use such frequencies only if the # cores is limited.
(We do not want conventional performance/ondemand/conservative to use
such frequencies.)


Cheers,
MyungJoo

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?

2013-05-24 08:30:47

by Lukasz Majewski

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

Hi Viresh,

> On 24 May 2013 11:26, Lukasz Majewski <[email protected]> wrote:
> >> > On 22 May 2013 15:57, Lukasz Majewski <[email protected]>
> > 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

2013-05-24 08:51:35

by Viresh Kumar

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

On 24 May 2013 14:00, Lukasz Majewski <[email protected]> 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

2013-05-24 09:06:24

by Daniel Lezcano

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

On 05/24/2013 10:51 AM, Viresh Kumar wrote:
> On 24 May 2013 14:00, Lukasz Majewski <[email protected]> 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

2013-05-24 09:13:57

by Viresh Kumar

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

On 24 May 2013 14:36, Daniel Lezcano <[email protected]> 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..

2013-05-24 10:28:48

by Daniel Lezcano

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

On 05/24/2013 11:13 AM, Viresh Kumar wrote:
> On 24 May 2013 14:36, Daniel Lezcano <[email protected]> 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

2013-05-24 10:32:53

by Viresh Kumar

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

On 24 May 2013 15:58, Daniel Lezcano <[email protected]> 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.

2013-05-24 11:21:08

by Lukasz Majewski

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

Hi Viresh,

> On 24 May 2013 14:00, Lukasz Majewski <[email protected]> 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

2013-05-24 11:34:56

by Lukasz Majewski

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

Hi Viresh,

> On 24 May 2013 14:36, Daniel Lezcano <[email protected]>
> 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

2013-05-27 05:33:41

by Viresh Kumar

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

On 24 May 2013 16:50, Lukasz Majewski <[email protected]> wrote:
>> On 24 May 2013 14:00, Lukasz Majewski <[email protected]> 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?

2013-05-27 07:35:07

by Lukasz Majewski

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

Hi Viresh,

> On 24 May 2013 16:50, Lukasz Majewski <[email protected]> wrote:
> >> On 24 May 2013 14:00, Lukasz Majewski <[email protected]>
> >> 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

2013-05-27 11:52:13

by Rafael J. Wysocki

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

On Monday, May 27, 2013 11:03:38 AM Viresh Kumar wrote:
> On 24 May 2013 16:50, Lukasz Majewski <[email protected]> wrote:
> >> On 24 May 2013 14:00, Lukasz Majewski <[email protected]> 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.

2013-05-27 12:16:52

by Lukasz Majewski

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

Hi Rafael,

> On Monday, May 27, 2013 11:03:38 AM Viresh Kumar wrote:
> > On 24 May 2013 16:50, Lukasz Majewski <[email protected]>
> > wrote:
> > >> On 24 May 2013 14:00, Lukasz Majewski <[email protected]>
> > >> 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

2013-05-27 13:24:51

by Viresh Kumar

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

On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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.

2013-05-27 19:40:06

by Rafael J. Wysocki

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

On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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.

2013-05-28 06:40:57

by Lukasz Majewski

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

Hi Rafael,

> On Monday, May 27, 2013 06:54:49 PM Viresh Kumar wrote:
> > On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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

2013-05-28 09:44:29

by Viresh Kumar

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

On 28 May 2013 12:10, Lukasz Majewski <[email protected]> wrote:
> On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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.

2013-05-28 12:21:33

by Rafael J. Wysocki

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

On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> On 28 May 2013 12:10, Lukasz Majewski <[email protected]> wrote:
> > On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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.

2013-05-28 13:27:01

by Lukasz Majewski

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

Hi Viresh, Rafael,

> On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote:
> > On 28 May 2013 12:10, Lukasz Majewski <[email protected]>
> > wrote:
> > > On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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

2013-05-28 21:39:25

by Rafael J. Wysocki

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

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 <[email protected]>
> > > wrote:
> > > > On 27 May 2013 17:30, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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.

2013-05-29 05:23:22

by Viresh Kumar

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

On 29 May 2013 03:18, Rafael J. Wysocki <[email protected]> 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"..

2013-05-29 07:09:43

by Lukasz Majewski

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

Hi Viresh, Rafael,

> On 29 May 2013 03:18, Rafael J. Wysocki <[email protected]> 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

2013-05-29 07:39:44

by Viresh Kumar

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

On 29 May 2013 12:39, Lukasz Majewski <[email protected]> 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!!

2013-05-29 13:46:02

by Lukasz Majewski

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

Hi Viresh,

> On 29 May 2013 12:39, Lukasz Majewski <[email protected]> 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