Re: Issues with ondemand governor
Thanks for running the tests, Vishwa. Your results are what I'd expect but it's good to see independent confirmation. In my benchmarks I saw 95-100% of the performance governor's performance, but the conditions were more favorable and the original ondemand governor was "only" degrading performance 20-30% to begin with. There should be absolutely no changes in power consumption at all for the patch itself, as behavior does not change until you raise sampling_down_factor above 1 (the default). If you set it high, I would expect higher power consumption (but also higher performance) under load and no change in power consumption when idle or close to idle. Setting a high sampling_down_factor causes the governor to reevaluate load less often when at max cpu speed, both to reduce overhead and to let it remain at maximum performance more consistently. Without this change, the ondemand governor jitters a lot in and out of max clock speed when under high loads, which is why its performance can be much worse than the performance governor. Reducing the number of transitions and load evaluations should also improve performance per watt, though the details of that depend on the relative efficiency of the CPU's respective clock speeds. If you want to balance power consumption and performance, a middle setting of sampling_down_factor like "10" should make a noticeable improvement in performance while not having as much impact on power. But if you want to match the performance governor's performance and are less concerned about transient power consumption, you will want to set it higher. Another note: I recommend setting io_is_busy to 1 when using sampling_down_factor above 1, as it improves responsiveness to quick load transients involving some I/O. It's also worth considering lowering up_threshold to 50 or even down to 15-20. David C Niemi Vishwanath Sripathy wrote: > Amit, > > On Tue, Nov 23, 2010 at 8:22 PM, Amit Kucheria > wrote: > >> Vishwa, >> >> Have you had a chance to do some usetime tests with these changes? >> > I did test USB performance with this and I see ondmeand is 90% close > to performance. > >> It would be interesting to measure the power consumption with and >> without these changes. >> > Power consumption impact can vary from usecase to usecase and extra > performance will have some power impact. > However in idle scenario, I feel this should not have much impact > since ondemand timer is a deferrable timer which means that it does > not prevent cpuidle. I will try to measure it for some usecase and > compare the power impact. > > Vishwa > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Issues with ondemand governor
Thanks David. If I would like to fine tune up_threshold and sampling_down_factor for say OMAP platform, is there any way to do it in kernel itself? I know these are configurable via sysfs entries. But if I want to optimize them in kernel itself, is there anyway? I see that default values are set in cpufreq-ondemand.c which is common kernel file. I would like to know if these can be set in platform specific code? Vishwa On Wed, Nov 24, 2010 at 7:42 PM, David C Niemi wrote: > > Thanks for running the tests, Vishwa. Your results are what I'd expect > but it's good to see independent confirmation. In my benchmarks I saw > 95-100% of the performance governor's performance, but the conditions > were more favorable and the original ondemand governor was "only" > degrading performance 20-30% to begin with. > > There should be absolutely no changes in power consumption at all for > the patch itself, as behavior does not change until you raise > sampling_down_factor above 1 (the default). If you set it high, I would > expect higher power consumption (but also higher performance) under load > and no change in power consumption when idle or close to idle. Setting > a high sampling_down_factor causes the governor to reevaluate load less > often when at max cpu speed, both to reduce overhead and to let it > remain at maximum performance more consistently. Without this change, > the ondemand governor jitters a lot in and out of max clock speed when > under high loads, which is why its performance can be much worse than > the performance governor. Reducing the number of transitions and load > evaluations should also improve performance per watt, though the details > of that depend on the relative efficiency of the CPU's respective clock > speeds. > > If you want to balance power consumption and performance, a middle > setting of sampling_down_factor like "10" should make a noticeable > improvement in performance while not having as much impact on power. > But if you want to match the performance governor's performance and are > less concerned about transient power consumption, you will want to set > it higher. > > Another note: I recommend setting io_is_busy to 1 when using > sampling_down_factor above 1, as it improves responsiveness to quick > load transients involving some I/O. It's also worth considering > lowering up_threshold to 50 or even down to 15-20. > > David C Niemi > > Vishwanath Sripathy wrote: >> Amit, >> >> On Tue, Nov 23, 2010 at 8:22 PM, Amit Kucheria >> wrote: >> >>> Vishwa, >>> >>> Have you had a chance to do some usetime tests with these changes? >>> >> I did test USB performance with this and I see ondmeand is 90% close >> to performance. >> >>> It would be interesting to measure the power consumption with and >>> without these changes. >>> >> Power consumption impact can vary from usecase to usecase and extra >> performance will have some power impact. >> However in idle scenario, I feel this should not have much impact >> since ondemand timer is a deferrable timer which means that it does >> not prevent cpuidle. I will try to measure it for some usecase and >> compare the power impact. >> >> Vishwa >> > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] OMAP PM: Optimize cpufreq transition latency
Currently cpufreq transition latency value does not really reflect the actual OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand performance as 40% of performance governor, and with this patch it's around 70% (using below procedure). cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/ Command used for performance testing: cpufreq-bench -l 5 -s 10 -x 5 -y 10 -g ondemand -r 5 -n 5 -v Signed-off-by: Vishwanath BS --- arch/arm/plat-omap/cpu-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) policy->max = policy->cpuinfo.max_freq; policy->cur = omap_getspeed(0); - /* FIXME: what's the actual transition time? */ - policy->cpuinfo.transition_latency = 300 * 1000; + /* Program the actual transition time for worstcase */ + policy->cpuinfo.transition_latency = 30 * 1000; return 0; } -- 1.7.0.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Issues with ondemand governor
On Thursday 25 November 2010 13:05:49 Vishwanath Sripathy wrote:
> Thanks David.
> If I would like to fine tune up_threshold and sampling_down_factor for
> say OMAP platform, is there any way to do it in kernel itself?
> I know these are configurable via sysfs entries. But if I want to
> optimize them in kernel itself, is there anyway? I see that default
> values are set in cpufreq-ondemand.c which is common kernel file. I
> would like to know if these can be set in platform specific code?
Ugly to do...
This should be done global and not per cpu?
If per_cpu it could be added to policy, simlar to latency:
set in driver's init func, evaluated in governor later.
Possibly if in cpufreq.h a struct:
{
unsigned int sampling_down_factor;
...
} cpufreq_governor_hints;
is added which gets filled by the platform driver in the .init func
and then gets evaluated in the governor, but only once also at init
time. Doing this when the governor is already active involves
locking which must get avoided.
Thomas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCHv2] export clock debug information to user space
Hi Jeremy,
Sorry for delay sending out this patch, I was slow down by other
things and eye infection :(
I followed your suggestion to make clock debug interface cleaner and
more independent, like removing unnecessary #ifdef and moving all
operations to kernel/clk.c.
>From 2b6c378c3c42d695f72f987e5e158faa2aac15d5 Mon Sep 17 00:00:00 2001
From: Yong Shen
Date: Thu, 18 Nov 2010 14:54:49 +0800
Subject: [PATCHv2] export clock debug information to user space
create a tree-like directory structure in debugfs so user space
tools like powerdebug can generate readable clock information.
more functions tend to be add in, like individual clock enable/disable
by writing to this debug interface.
Signed-off-by: Yong Shen
---
arch/arm/common/Kconfig |7 +++
arch/arm/common/clkdev.c |3 +
include/linux/clk.h | 18 +++
kernel/clk.c | 116 ++
4 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 0a34c81..c84eb90 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -41,3 +41,10 @@ config SHARP_SCOOP
config COMMON_CLKDEV
bool
select HAVE_CLK
+
+config CLK_DEBUG
+ bool "clock debug information export to user space"
+ depends on USE_COMMON_STRUCT_CLK && PM_DEBUG && DEBUG_FS
+ default n
+ help
+ export clk debug information to user space
diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
index 9e4c4d9..1d08fb3 100644
--- a/arch/arm/common/clkdev.c
+++ b/arch/arm/common/clkdev.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
@@ -104,6 +105,7 @@ EXPORT_SYMBOL(clk_put);
void clkdev_add(struct clk_lookup *cl)
{
+ clk_debug_register(cl->clk);
mutex_lock(&clocks_mutex);
list_add_tail(&cl->node, &clocks);
mutex_unlock(&clocks_mutex);
@@ -114,6 +116,7 @@ void __init clkdev_add_table(struct clk_lookup
*cl, size_t num)
{
mutex_lock(&clocks_mutex);
while (num--) {
+ clk_debug_register(cl->clk);
list_add_tail(&cl->node, &clocks);
cl++;
}
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 56416b7..3d5f9ba 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -18,6 +18,7 @@
struct device;
#ifdef CONFIG_USE_COMMON_STRUCT_CLK
+#define CLK_NAME_LEN 32
/* If we're using the common struct clk, we define the base clk object here */
@@ -48,12 +49,23 @@ struct clk {
const struct clk_ops*ops;
unsigned intenable_count;
struct mutexmutex;
+#ifdef CONFIG_CLK_DEBUG
+ char name[CLK_NAME_LEN];
+ struct dentry *dentry;
+#endif
};
+#ifdef CONFIG_CLK_DEBUG
+#define __INIT_CLK_DEBUG(n) .name = #n,
+#else
+#define __INIT_CLK_DEBUG(n)
+#endif
+
#define INIT_CLK(name, o) {\
.ops= &o, \
.enable_count = 0,\
.mutex = __MUTEX_INITIALIZER(name.mutex), \
+ __INIT_CLK_DEBUG(name) \
}
struct clk_ops {
@@ -245,4 +257,10 @@ struct clk *clk_get_sys(const char *dev_id, const
char *con_id);
int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
struct device *dev);
+#ifdef CONFIG_CLK_DEBUG
+void clk_debug_register(struct clk *clk);
+#else
+static inline void clk_debug_register(struct clk *clk) {}
+#endif
+
#endif
diff --git a/kernel/clk.c b/kernel/clk.c
index 32f25ef..d23633f 100644
--- a/kernel/clk.c
+++ b/kernel/clk.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
int clk_enable(struct clk *clk)
{
@@ -113,3 +115,117 @@ struct clk_ops clk_fixed_ops = {
.get_rate = clk_fixed_get_rate,
};
EXPORT_SYMBOL_GPL(clk_fixed_ops);
+
+#ifdef CONFIG_CLK_DEBUG
+/*
+ * debugfs support to trace clock tree hierarchy and attributes
+ */
+static int clk_debug_rate_get(void *data, u64 *val)
+{
+ struct clk *clk = data;
+
+ *val = (u64)clk_get_rate(clk);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(clk_debug_rate_fops, clk_debug_rate_get, NULL,
+ "%llu\n");
+
+
+static struct dentry *clk_root;
+static int clk_debug_register_one(struct clk *clk)
+{
+ int err;
+ struct dentry *d, *child, *child_tmp;
+ struct clk *pa = clk_get_parent(clk);
+
+ if (pa && !IS_ERR(pa))
+ d = debugfs_create_dir(clk->name, pa->dentry);
+ else {
+ if (!clk_root)
+ clk_root = debugfs_create_dir("clocks", NULL);
+ if (!clk_root)
+ return -ENOMEM;
+ d = debugfs_create_dir(clk->name, clk_root);
+ }
+
+ if (!d)
+ return -ENOMEM;
+
+ clk->dentry = d;
+
+ d = debugfs_create_u32("enable_count", S_IRUGO, clk-
