linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency
@ 2013-04-03  6:31 stratosk
  2013-04-03  6:43 ` Viresh Kumar
  0 siblings, 1 reply; 22+ messages in thread
From: stratosk @ 2013-04-03  6:31 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Viresh Kumar, cpufreq, linux-pm, linux-kernel

I'm sorry, I don't understand.
The goal of this patch is not energy saving.
The goal is to detect CPU load as soon as possible to increase frequency.

Could you please clarify this?

Thanks,
Stratos

"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

>On Tuesday, April 02, 2013 06:49:14 PM Stratos Karafotis wrote:
>> On 04/02/2013 04:50 PM, Rafael J. Wysocki wrote:
>> > Do you have any numbers indicating that this actually makes things better?
>> > 
>> > Rafael
>> 
>> No, I don't.
>> The expected behaviour after this patch is to "force" max frequency few sampling periods earlier.
>> The idea was to increase system responsiveness especially on 'small' embedded systems (phones for example).
>> 
>> Actually, I thought to provide some numbers but I had no idea how to measure this.
>> 
>> Would it be enough to provide the number of times that the CPU increases frequency 
>> because of early_demand versus the total number of increments?
>
>I think it would be better to check if your approach leads to a better behavior
>as far as energy savings are concerned.  If it actually is worse, then I don't
>see a reason to apply it.
>
>Thanks,
>Rafael
>
>
>-- 
>I speak only for myself.
>Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency
@ 2013-04-04  7:21 stratosk
  0 siblings, 0 replies; 22+ messages in thread
From: stratosk @ 2013-04-04  7:21 UTC (permalink / raw)
  To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, linux-pm, linux-kernel

I agree that we will have false alarms but this will not be a total waste of power since the load will be more than 50 (the default grad_up_threshold value).

So, I don't think there will be *significant* increase in power. Though, I don't know a way to prove this with numbers.

Thanks,
Stratos

Viresh Kumar <viresh.kumar@linaro.org> wrote:

>On 4 April 2013 12:17, stratosk <stratosk@semaphore.gr> wrote:
>> Why do you suspect significant increased power? With ondemand  the CPU will go down to lowest freq as soon as the load will decreased. And the measurement shows that the CPU load will decrease faster (because of faster calculation).
>
>I suspect it because we are increasing freq based on the assumption:
>"If increase in load from last calculation is more then threshold, then
>we must use high freq"..
>
>So, this rise can be false alarm multiple times and we might not see
>a load increase after moving to high freq and so we are running at
>high/max freq without any need of it. And so more power.

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency
@ 2013-04-04  6:47 stratosk
  2013-04-04  6:51 ` Viresh Kumar
  0 siblings, 1 reply; 22+ messages in thread
From: stratosk @ 2013-04-04  6:47 UTC (permalink / raw)
  To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, linux-pm, linux-kernel

Hi Viresh,

I never use performance governor, but I want improved performance with ondemand.

Why do you suspect significant increased power? With ondemand  the CPU will go down to lowest freq as soon as the load will decreased. And the measurement shows that the CPU load will decrease faster (because of faster calculation).

I build and distribute a 3.0.y kernel for a smart phone arm cortex A8. There are about 10000 installations with early_demand included. Nobody noticed increased power.

Though, I'm not able to provide numbers in the form of power.

Thanks,
Stratos

Viresh Kumar <viresh.kumar@linaro.org> wrote:

>Hi Stratos,
>
>On 4 April 2013 05:00, Stratos Karafotis <stratosk@semaphore.gr> wrote:
>> I tried to do some measurements simulating a CPU load with a loop that simply counts
>> an integer. The first test simulates a CPU load that lasts 2 x sampling_rate = ~ 20000us.
>> The second ~40000us and the third ~60000us.
>> There are 5 runs in each test. In each run the benchmark program counts 20 times with
>> early_demand off and 20 times with early_demand on and takes the average times.
>>
>> I run the benchmark program on 3.9-rc5 + early_demand patch. My CPU is the i7-3770 @ 3.40 GHz
>>
>> Please find below the results, and the benchmark code attached.
>> Please note, that the idea of this patch is to push the CPU to max frequency few sampling
>> periods (1 in most cases) earlier for a more responsive system.
>
>Yes, your results show some improvements. BUT if performance is the only thing
>we were looking for, then we will never use ondemand governor but performance
>governor.
>
>I suspect this little increase in performance must have increased power numbers
>too (significantly). So, if you can get numbers in the form of power/performance
>with and without your patch, it will be great.
>
>--
>viresh

^ permalink raw reply	[flat|nested] 22+ messages in thread
* [PATCH linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency
@ 2013-02-20 20:50 Stratos Karafotis
  2013-02-21  4:59 ` Viresh Kumar
  0 siblings, 1 reply; 22+ messages in thread
From: Stratos Karafotis @ 2013-02-20 20:50 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: cpufreq, linux-pm, linux-kernel

Instead of checking only the absolute value of CPU load_freq to increase
frequency, we detect forthcoming CPU load rise and increase frequency
earlier.

Every sampling rate, we calculate the gradient of load_freq.
If it is too steep we assume that the load most probably will
go over up_threshold in next iteration(s). We reduce up_threshold
by early_differential to achieve frequency increase in the current
iteration.

A new tuner early_demand is introduced to enable this functionality
(disabled by default). Also we use new tuners to control early demand:

	- early_differential: controls the final up_threshold
	- grad_up_threshold: over this gradient of load we will decrease
		up_threshold by early_differential.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
---
 drivers/cpufreq/cpufreq_governor.c |  1 +
 drivers/cpufreq/cpufreq_governor.h |  4 ++++
 drivers/cpufreq/cpufreq_ondemand.c | 41 +++++++++++++++++++++++++++++++++++++-
 3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 5a76086..348cb80 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -276,6 +276,7 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
 		} else {
 			od_dbs_info->rate_mult = 1;
 			od_dbs_info->sample_type = OD_NORMAL_SAMPLE;
+			od_dbs_info->prev_load_freq = 0;
 			od_ops->powersave_bias_init_cpu(cpu);
 
 			if (!policy->governor->initialized)
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index d2ac911..d1425a7 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -94,6 +94,7 @@ struct od_cpu_dbs_info_s {
 	unsigned int freq_hi_jiffies;
 	unsigned int rate_mult;
 	unsigned int sample_type:1;
+	unsigned int prev_load_freq;
 };
 
 struct cs_cpu_dbs_info_s {
@@ -112,6 +113,9 @@ struct od_dbs_tuners {
 	unsigned int adj_up_threshold;
 	unsigned int powersave_bias;
 	unsigned int io_is_busy;
+	unsigned int early_differential;
+	unsigned int grad_up_threshold;
+	unsigned int early_demand;
 };
 
 struct cs_dbs_tuners {
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index f3eb26c..458806f 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -30,6 +30,8 @@
 #define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
 #define DEF_FREQUENCY_UP_THRESHOLD		(80)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
+#define DEF_GRAD_UP_THESHOLD			(50)
+#define DEF_EARLY_DIFFERENTIAL			(45)
 #define MAX_SAMPLING_DOWN_FACTOR		(100000)
 #define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
 #define MICRO_FREQUENCY_UP_THRESHOLD		(95)
@@ -49,8 +51,11 @@ static struct od_dbs_tuners od_tuners = {
 	.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
 	.adj_up_threshold = DEF_FREQUENCY_UP_THRESHOLD -
 			    DEF_FREQUENCY_DOWN_DIFFERENTIAL,
+	.early_differential = DEF_EARLY_DIFFERENTIAL,
+	.grad_up_threshold = DEF_GRAD_UP_THESHOLD,
 	.ignore_nice = 0,
 	.powersave_bias = 0,
+	.early_demand = 0,
 };
 
 static void ondemand_powersave_bias_init_cpu(int cpu)
@@ -170,11 +175,29 @@ static void od_check_cpu(int cpu, unsigned int load_freq)
 {
 	struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+	unsigned int up_threshold = od_tuners.up_threshold;
+	unsigned int grad;
 
 	dbs_info->freq_lo = 0;
 
+	/*
+	 * Calculate the gradient of load_freq. If it is too steep we assume
+	 * that the load will go over up_threshold in next iteration(s). We
+	 * reduce up_threshold by early_differential to achieve frequency
+	 * increase earlier
+	 */
+	if (od_tuners.early_demand) {
+		if (load_freq > dbs_info->prev_load_freq) {
+			grad = load_freq - dbs_info->prev_load_freq;
+
+			if (grad > od_tuners.grad_up_threshold * policy->cur)
+				up_threshold -= od_tuners.early_differential;
+		}
+		dbs_info->prev_load_freq = load_freq;
+	}
+
 	/* Check for frequency increase */
-	if (load_freq > od_tuners.up_threshold * policy->cur) {
+	if (load_freq > up_threshold * policy->cur) {
 		/* If switching to max speed, apply sampling_down_factor */
 		if (policy->cur < policy->max)
 			dbs_info->rate_mult =
@@ -438,12 +461,26 @@ static ssize_t store_powersave_bias(struct kobject *a, struct attribute *b,
 	return count;
 }
 
+static ssize_t store_early_demand(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;
+	od_tuners.early_demand = !!input;
+	return count;
+}
+
 show_one(od, sampling_rate, sampling_rate);
 show_one(od, io_is_busy, io_is_busy);
 show_one(od, up_threshold, up_threshold);
 show_one(od, sampling_down_factor, sampling_down_factor);
 show_one(od, ignore_nice_load, ignore_nice);
 show_one(od, powersave_bias, powersave_bias);
+show_one(od, early_demand, early_demand);
 
 define_one_global_rw(sampling_rate);
 define_one_global_rw(io_is_busy);
@@ -452,6 +489,7 @@ define_one_global_rw(sampling_down_factor);
 define_one_global_rw(ignore_nice_load);
 define_one_global_rw(powersave_bias);
 define_one_global_ro(sampling_rate_min);
+define_one_global_rw(early_demand);
 
 static struct attribute *dbs_attributes[] = {
 	&sampling_rate_min.attr,
@@ -461,6 +499,7 @@ static struct attribute *dbs_attributes[] = {
 	&ignore_nice_load.attr,
 	&powersave_bias.attr,
 	&io_is_busy.attr,
+	&early_demand.attr,
 	NULL
 };
 
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-04-26 14:41 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-03  6:31 [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency stratosk
2013-04-03  6:43 ` Viresh Kumar
2013-04-03 11:14   ` Rafael J. Wysocki
2013-04-03 23:30     ` Stratos Karafotis
2013-04-04  4:54       ` Viresh Kumar
2013-04-05 19:50         ` Stratos Karafotis
2013-04-09 16:56           ` Stratos Karafotis
2013-04-10  3:22             ` Viresh Kumar
2013-04-16 18:34               ` Stratos Karafotis
2013-04-26 14:41             ` Stratos Karafotis
  -- strict thread matches above, loose matches on Subject: below --
2013-04-04  7:21 stratosk
2013-04-04  6:47 stratosk
2013-04-04  6:51 ` Viresh Kumar
2013-02-20 20:50 [PATCH " Stratos Karafotis
2013-02-21  4:59 ` Viresh Kumar
2013-02-21 11:31   ` [PATCH v2 " Stratos Karafotis
2013-02-21 15:33     ` Viresh Kumar
2013-02-21 17:39       ` [PATCH v3 " Stratos Karafotis
2013-02-22  1:56         ` Viresh Kumar
2013-02-22  5:57           ` Viresh Kumar
2013-02-22 12:47             ` Rafael J. Wysocki
2013-03-29 22:27           ` Stratos Karafotis
2013-03-29 22:38             ` Rafael J. Wysocki
2013-04-02 13:50             ` Rafael J. Wysocki
2013-04-02 15:49               ` Stratos Karafotis
2013-04-02 22:55                 ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).