Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[stratosk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1397 bytes --]

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.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

On 3 April 2013 12:01, stratosk <stratosk@semaphore.gr> wrote:
> I'm sorry, I don't understand.
> The goal of this patch is not energy saving.

He probably misunderstood it...

> The goal is to detect CPU load as soon as possible to increase frequency.
>
> Could you please clarify this?

But he is looking for some numbers to prove your patch. Some numbers
that shows performance is better with your changes...

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Rafael J. Wysocki]

On Wednesday, April 03, 2013 12:13:56 PM Viresh Kumar wrote:
> On 3 April 2013 12:01, stratosk <stratosk@semaphore.gr> wrote:
> > I'm sorry, I don't understand.
> > The goal of this patch is not energy saving.
> 
> He probably misunderstood it...
> 
> > The goal is to detect CPU load as soon as possible to increase frequency.
> >
> > Could you please clarify this?
> 
> But he is looking for some numbers to prove your patch. Some numbers
> that shows performance is better with your changes...

Yes.  If the goal of the patch is to improve performance, it would be good to
know that it does meet the goal. IOW, *something* is supposed to be better with
the patch and if so, numbers in support of this should be provided.

Thanks,
Rafael


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

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

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

On 04/03/2013 02:14 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 12:13:56 PM Viresh Kumar wrote:
>> On 3 April 2013 12:01, stratosk <stratosk@semaphore.gr> wrote:
>>> I'm sorry, I don't understand.
>>> The goal of this patch is not energy saving.
>>
>> He probably misunderstood it...
>>
>>> The goal is to detect CPU load as soon as possible to increase frequency.
>>>
>>> Could you please clarify this?
>>
>> But he is looking for some numbers to prove your patch. Some numbers
>> that shows performance is better with your changes...
> 
> Yes.  If the goal of the patch is to improve performance, it would be good to
> know that it does meet the goal. IOW, *something* is supposed to be better with
> the patch and if so, numbers in support of this should be provided.
> 
> Thanks,
> Rafael

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. 

Thanks for your time,
Stratos

--------

counter 10,000,000
run	early_demand off	early_demand on		diff
1	20183us			20100us			0.41%
2	20127us			20091us			0.18%
3	20121us			20034us			0.43%
4	20262us			20043us			1.08%
5	20192us			20101us			0.45%

counter 20,000,000
run	early_demand off	early_demand on		diff
1	40037us			39846us			0.47%
2	40051us			39829us			0.55%
3	39996us			39845us			0.38%
4	40104us			39876us			0.57%
5	40090us			39841us			0.62%

counter 30,000,000
run	early_demand off	early_demand on		diff
1	60010us			59834us			0.29%
2	59560us			59854us			-0.491%
3	60006us			59827us			0.29%
4	59998us			59828us			0.28%
5	60012us			59866us			0.24%


[-- Attachment #2: bench.c --]
[-- Type: text/x-csrc, Size: 1943 bytes --]

#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>


struct timeval start, end;
unsigned long long i, cnt;
long utime, seconds, useconds;

void enable_early() {
	system("echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/early_demand");
}

void disable_early() {
        system("echo 0 > /sys/devices/system/cpu/cpufreq/ondemand/early_demand");
}

void calibrate()
{
	sleep(1);

	gettimeofday(&start, NULL);

	for (i = 0; i < 1000000000; i++);

	gettimeofday(&end, NULL);
	seconds = end.tv_sec - start.tv_sec;
	useconds = end.tv_usec - start.tv_usec;
	utime = seconds * 1000000 + useconds;
	
	printf("Calibrating\n");
	printf("Elapsed time: %ld microseconds\n", utime);

	/* find the counter for 10ms */
	cnt = i * 10000 / utime;

	printf("cnt: %ld\n", cnt);
}

long do_bench()
{
	gettimeofday(&start, NULL);

	for (i = 0; i < cnt; i++);

	gettimeofday(&end, NULL);
	seconds = end.tv_sec - start.tv_sec;
	useconds = end.tv_usec - start.tv_usec;
	utime = seconds * 1000000 + useconds;
	
	printf("Elapsed time: %ld microseconds\n", utime);

	return utime;
}

void benchmark()
{
	const int iter = 20;
	long total_off = 0;
	long total_on = 0;
	int diff_perc;
	unsigned int i;

	/* calibrate(); */
	cnt = 10000000;

	disable_early();
	do_bench(); /* do a first benchmark but do not count in total */	
	sleep(5);

	for (i = 0; i < iter; i++) {
		total_off += do_bench();
		
		usleep(500000);
	}
	total_off /= iter;

	printf("early_demand off - average time: %ld microseconds\n", total_off);

	enable_early();
	do_bench(); /* do a first benchmark but do not count in total */
	sleep(5);

	for (i = 0; i < iter; i++) {
                total_on += do_bench();

                usleep(500000);
        }
        total_on /= iter;

	diff_perc = total_off - total_on;

        printf("early_demand on - average time: %ld microseconds\n", total_on);
	printf("diff: %d\n", diff_perc);
}

main ()
{
	printf("Starting benchmark\n");
	benchmark();

}

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

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

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

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

Hi Viresh,

On 04/04/2013 07:54 AM, Viresh Kumar wrote:
> Hi Stratos,
> 
> 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
> 

I run some more tests. I increased the number of iterations to 100 (from 20). 
I also test for counter 1,000,000 (~4200us), 5,000,000 (~10000us), 15,000,000 (~30000us).

This time, I also extracted statistics from cpufreq_stats driver. I think this will be an
indication for power consumption. Below the results and attached the program I used for to
get these numbers.

Thanks for your time,
Stratos

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

counter 1,000,000
average diff: 0.184%

run 0
-----
cpufreq off     on
------- ------- ----
3401000 686     702
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 4957    4940
early_demand off: 4207 us
early_demand on: 4214 us
diff: -0.17%

run 1
-----
cpufreq off     on
------- ------- ----
3401000 513     665
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 5130    4978
early_demand off: 4208 us
early_demand on: 4194 us
diff: 0.33%

run 2
-----
cpufreq off     on
------- ------- ----
3401000 630     487
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 5013    5155
early_demand off: 4210 us
early_demand on: 4200 us
diff: 0.24%

run 3
-----
cpufreq off     on
------- ------- ----
3401000 666     602
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 4976    5040
early_demand off: 4205 us
early_demand on: 4183 us
diff: 0.52%

run 4
-----
cpufreq off     on
------- ------- ----
3401000 527     725
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 5116    4917
early_demand off: 4193 us
early_demand on: 4193 us
diff: 0.00%
-------------------------


counter 5,000,000
average diff: 1.184%

run 0
-----
cpufreq off     on
------- ------- ----
3401000 1994    2294
3400000 0       0
3300000 0       49
3100000 40      0
3000000 11      1
2900000 0       49
2800000 0       1
2600000 0       0
2500000 0       0
2400000 55      0
2200000 0       4
2100000 0       0
2000000 0       0
1900000 46      1
1700000 0       0
1600000 3558    3304
early_demand off: 10423 us
early_demand on: 10441 us
diff: -0.17%

run 1
-----
cpufreq off     on
------- ------- ----
3401000 2112    2174
3400000 0       0
3300000 7       38
3100000 0       0
3000000 49      0
2900000 0       49
2800000 39      0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       1
2000000 0       0
1900000 37      38
1700000 44      11
1600000 3416    3390
early_demand off: 10538 us
early_demand on: 10239 us
diff: 2.83%

run 2
-----
cpufreq off     on
------- ------- ----
3401000 2107    2296
3400000 0       0
3300000 0       0
3100000 0       22
3000000 95      0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 49      11
2200000 0       0
2100000 0       0
2000000 0       49
1900000 11      34
1700000 0       0
1600000 3443    3291
early_demand off: 10434 us
early_demand on: 10439 us
diff: -0.05%

run 3
-----
cpufreq off     on
------- ------- ----
3401000 2106    2308
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       11
2900000 0       0
2800000 0       0
2600000 0       0
2500000 59      0
2400000 13      46
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       4
1700000 0       0
1600000 3527    3333
early_demand off: 10541 us
early_demand on: 10238 us
diff: 2.87%

run 4
-----
cpufreq off     on
------- ------- ----
3401000 1899   2197
3400000 0      0   
3300000 0      0   
3100000 49     99  
3000000 0      0   
2900000 0      0   
2800000 21     0   
2600000 0      0   
2500000 0      0   
2400000 0      0   
2200000 0      0   
2100000 0      0   
2000000 20     0   
1900000 4      11  
1700000 0      14  
1600000 3710   3383
early_demand off: 10432 us
early_demand on: 10339 us
diff: 0.89%
--------------------------


counter 10,000,000
average diff: 0.336%

run 0
-----
cpufreq off     on
------- ------- ----
3401000 2106    2232
3400000 0       0
3300000 0       42
3100000 29      0
3000000 0       0
2900000 0       0
2800000 49      0
2600000 0       0
2500000 0       0
2400000 11      49
2200000 0       0
2100000 0       0
2000000 52      0
1900000 47      0
1700000 0       0
1600000 3507    3478
early_demand off: 20169 us
early_demand on: 20036 us
diff: 0.66%

run 1
-----
cpufreq off     on
------- ------- ----
3401000 2210    2146
3400000 0       0
3300000 44      0
3100000 49      10
3000000 0       0
2900000 3       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       3
1700000 0       0
1600000 3496    3643
early_demand off: 20142 us
early_demand on: 20137 us
diff: 0.03%

run 2
-----
cpufreq off     on
------- ------- ----
3401000 2133    2135
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       35
2600000 0       0
2500000 21      0
2400000 53      39
2200000 0       0
2100000 0       0
2000000 49      0
1900000 38      49
1700000 0       48
1600000 3506    3495
early_demand off: 20037 us
early_demand on: 19934 us
diff: 0.51%

run 3
-----
cpufreq off     on
------- ------- ----
3401000 2166    2125
3400000 0       0
3300000 0       0
3100000 0       5
3000000 11      0
2900000 43      0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       55
2200000 28      0
2100000 8       54
2000000 0       0
1900000 0       34
1700000 11      0
1600000 3535    3525
early_demand off: 20038 us
early_demand on: 19940 us
diff: 0.49%

run 4
-----
cpufreq off     on
------- ------- ----
3401000 2122    2125
3400000 0       0
3300000 25      0
3100000 0       5
3000000 29      0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       55
2200000 0       0
2100000 0       54
2000000 0       0
1900000 0       34
1700000 0       0
1600000 3626    3525
early_demand off: 20037 us
early_demand on: 20039 us
diff: -0.01%
--------------------------


counter 15,000,000
average diff: 0.21%


run 0
-----
cpufreq off     on
------- ------- ----
3401000 2226    2262
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 22      0
2200000 0       0
2100000 0       49
2000000 38      0
1900000 60      0
1700000 0       0
1600000 3555    3592
early_demand off: 29940 us
early_demand on: 30038 us
diff: -0.33%

run 1
-----
cpufreq off     on
------- ------- ----
3401000 2466    2582
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       38
2400000 37      0
2200000 0       11
2100000 0       0
2000000 0       11
1900000 0       0
1700000 0       0
1600000 3400    3260
early_demand off: 30033 us
early_demand on: 29934 us
diff: 0.33%

run 2
-----
cpufreq off     on
------- ------- ----
3401000 2545    2195
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 24      4
2200000 0       4
2100000 34      0
2000000 6       0
1900000 0       0
1700000 0       0
1600000 3294    3700
early_demand off: 30131 us
early_demand on: 30028 us
diff: 0.34%

run 3
-----
cpufreq off     on
------- ------- ----
3401000 2327    2362
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 2       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 11      0
2000000 0       1
1900000 0       0
1700000 4       39
1600000 3558    3500
early_demand off: 29938 us
early_demand on: 29930 us
diff: 0.03%

run 4
-----
cpufreq off     on
------- ------- ----
3401000 2303    2246
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       11
2500000 9       0
2400000 56      0
2200000 0       0
2100000 11      0
2000000 0       0
1900000 0       49
1700000 0       0
1600000 3525    3596
early_demand off: 30137 us
early_demand on: 29931 us
diff: 0.68%
--------------------------


counter 20,000,000
average diff: 0.038%

run 0
-----
cpufreq off     on
------- ------- ----
3401000 2498    2483
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 1       0
1900000 0       19
1700000 0       33
1600000 3504    3468
early_demand off: 39917 us
early_demand on: 39925 us
diff: -0.02%

run 1
-----
cpufreq off     on
------- ------- ----
3401000 2338   2405 
3400000 0      0 
3300000 0      0 
3100000 0      0 
3000000 0      0 
2900000 0      0 
2800000 0      0 
2600000 0      0 
2500000 0      0 
2400000 0      0 
2200000 0      0 
2100000 0      0 
2000000 0      0 
1900000 75     9 
1700000 0      0 
1600000 3593   3589 
early_demand off: 40130 us
early_demand on: 39927 us
diff: 0.51%

run 2
-----
cpufreq off     on
------- ------- ----
3401000 2344    2342
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 17      49
2000000 0       0
1900000 32      0
1700000 0       0
1600000 3610    3612
early_demand off: 39930 us
early_demand on: 39930 us
diff: 0.00%

run 3
-----
cpufreq off     on
------- ------- ----
3401000 2631    2490
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       37
1700000 0       12
1600000 3373    3465
early_demand off: 39937 us
early_demand on: 39938 us
diff: 0.00%

run 4
-----
cpufreq off     on
------- ------- ----
3401000 2298    2451
3400000 0       0
3300000 0       0
3100000 0       0
3000000 0       0
2900000 0       0
2800000 0       0
2600000 0       0
2500000 0       0
2400000 0       0
2200000 0       0
2100000 0       0
2000000 0       0
1900000 0       0
1700000 0       0
1600000 3708    3553
early_demand off: 40126 us
early_demand on: 39937 us
diff: 0.47%


[-- Attachment #2: bench.c --]
[-- Type: text/x-csrc, Size: 2471 bytes --]

#define _GNU_SOURCE
#include <pthread.h>
#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>
#include <sched.h>

struct timeval start, end;
unsigned long long i, cnt;
long utime, seconds, useconds;

void enable_early() {
	system("echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/early_demand");
        system("rmmod cpufreq_stats");
        system("modprobe cpufreq_stats");
}

void disable_early() {
        system("echo 0 > /sys/devices/system/cpu/cpufreq/ondemand/early_demand");
	system("rmmod cpufreq_stats");
	system("modprobe cpufreq_stats");
}

void calibrate()
{
	sleep(1);

	gettimeofday(&start, NULL);

	for (i = 0; i < 1000000000; i++);

	gettimeofday(&end, NULL);
	seconds = end.tv_sec - start.tv_sec;
	useconds = end.tv_usec - start.tv_usec;
	utime = seconds * 1000000 + useconds;
	
	printf("Calibrating\n");
	printf("Elapsed time: %ld microseconds\n", utime);

	/* find the counter for 10ms */
	cnt = i * 10000 / utime;

	printf("cnt: %ld\n", cnt);
}

long do_bench()
{
	gettimeofday(&start, NULL);

	for (i = 0; i < cnt; i++);

	gettimeofday(&end, NULL);
	seconds = end.tv_sec - start.tv_sec;
	useconds = end.tv_usec - start.tv_usec;
	utime = seconds * 1000000 + useconds;
	
	printf("Elapsed time: %ld microseconds\n", utime);

	return utime;
}

void benchmark()
{
	const int iter = 100;
	long total_off = 0;
	long total_on = 0;
	double diff_perc;
	unsigned int i;

	/* calibrate(); */
	cnt = 1000000;

	disable_early();
	sleep(1);
	do_bench(); /* do a first benchmark but do not count in total */	
	sleep(5);

	for (i = 0; i < iter; i++) {
		total_off += do_bench();
		
		usleep(500000);
	}
	total_off /= iter;

	system("cat /sys/devices/system/cpu/cpu2/cpufreq/stats/time_in_state");

	enable_early();
	sleep(1);
	do_bench(); /* do a first benchmark but do not count in total */
	sleep(5);

	for (i = 0; i < iter; i++) {
                total_on += do_bench();

                usleep(500000);
        }
        total_on /= iter;

	system("cat /sys/devices/system/cpu/cpu2/cpufreq/stats/time_in_state");
	diff_perc = (total_off - total_on) * 100;
	diff_perc /= total_off;

	printf("early_demand off: %ld us\n", total_off);
        printf("early_demand on: %ld us\n", total_on);
	printf("diff: %f\n", diff_perc);
}

main ()
{
	int i;

	cpu_set_t  mask;
	CPU_ZERO(&mask);
	CPU_SET(2, &mask);
	sched_setaffinity(0, sizeof(mask), &mask);

	printf("Starting benchmark\n");
	
	for (i = 0; i < 5; i++) {
		printf("run %i\n", i);
		benchmark();
	}
}

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
> Hi Viresh,
>
> On 04/04/2013 07:54 AM, Viresh Kumar wrote:
>> Hi Stratos,
>>
>> 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
>>
>
> I run some more tests. I increased the number of iterations to 100 (from 20).
> I also test for counter 1,000,000 (~4200us), 5,000,000 (~10000us), 15,000,000 (~30000us).
>
> This time, I also extracted statistics from cpufreq_stats driver. I think this will be an
> indication for power consumption. Below the results and attached the program I used for to
> get these numbers.

Any comments would be appreciated.

Thanks,
Stratos

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

On 9 April 2013 22:26, Stratos Karafotis <stratosk@semaphore.gr> wrote:
> On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
>>
>> Hi Viresh,
>>
>> On 04/04/2013 07:54 AM, Viresh Kumar wrote:
>>>
>>> Hi Stratos,
>>>
>>> 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
>>>
>>
>> I run some more tests. I increased the number of iterations to 100 (from
>> 20).
>> I also test for counter 1,000,000 (~4200us), 5,000,000 (~10000us),
>> 15,000,000 (~30000us).
>>
>> This time, I also extracted statistics from cpufreq_stats driver. I think
>> this will be an
>> indication for power consumption. Below the results and attached the
>> program I used for to
>> get these numbers.
>
>
> Any comments would be appreciated.

Sorry, i forgot about this mail earlier..

Your performance numbers look improved but i am still not sure about
power consumption. But as this is not going to be the default settings, i
think we can take this patch.

@Rafael:?

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

On 04/10/2013 06:22 AM, Viresh Kumar wrote:
> On 9 April 2013 22:26, Stratos Karafotis <stratosk@semaphore.gr> wrote:
>> On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
>>>
>>> Hi Viresh,
>>>
>>> On 04/04/2013 07:54 AM, Viresh Kumar wrote:
>>>>
>>>> Hi Stratos,
>>>>
>>>> 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
>>>>
>>>
>>> I run some more tests. I increased the number of iterations to 100 (from
>>> 20).
>>> I also test for counter 1,000,000 (~4200us), 5,000,000 (~10000us),
>>> 15,000,000 (~30000us).
>>>
>>> This time, I also extracted statistics from cpufreq_stats driver. I think
>>> this will be an
>>> indication for power consumption. Below the results and attached the
>>> program I used for to
>>> get these numbers.
>>
>>
>> Any comments would be appreciated.
>
> Sorry, i forgot about this mail earlier..
>
> Your performance numbers look improved but i am still not sure about
> power consumption. But as this is not going to be the default settings, i
> think we can take this patch.
>
> @Rafael:?
>

Hi Rafael,

I'm sorry for bothering you again for this patch.
Are these number adequate? Should I provide more benchmark results?

Thanks for your time.

Stratos

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

On 04/09/2013 07:56 PM, Stratos Karafotis wrote:
> On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
>> Hi Viresh,
>>
>> On 04/04/2013 07:54 AM, Viresh Kumar wrote:
>>> Hi Stratos,
>>>
>>> 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
>>>
>>
>> I run some more tests. I increased the number of iterations to 100
>> (from 20).
>> I also test for counter 1,000,000 (~4200us), 5,000,000 (~10000us),
>> 15,000,000 (~30000us).
>>
>> This time, I also extracted statistics from cpufreq_stats driver. I
>> think this will be an
>> indication for power consumption. Below the results and attached the
>> program I used for to
>> get these numbers.
>
> Any comments would be appreciated.
>
> Thanks,
> Stratos
>
>

Ping.

Thanks,
Stratos

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[stratosk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1173 bytes --]

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.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

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.

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[stratosk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2000 bytes --]

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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Rafael J. Wysocki]

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.

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

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? 


Thanks,
Stratos

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Rafael J. Wysocki]

On Saturday, March 30, 2013 12:27:34 AM Stratos Karafotis wrote:
> On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> > On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:
> >
> >> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> > 
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > 
> 
> Hi Rafael,
> 
> In case you are interested in this patch I rebased it to the latest linux-pm/bleeding-edge.
> 
> Thanks,
> Stratos
> 
> ------------------------------------------
> 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) and we increase frequency immediately.
> 
> New tuners are introduced:
> - early_demand: to enable this functionality (disabled by default).
> - grad_up_threshold: over this gradient of load we will increase
> frequency immediately.

Do you have any numbers indicating that this actually makes things better?

Rafael


> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> ---
>  drivers/cpufreq/cpufreq_governor.c |  1 +
>  drivers/cpufreq/cpufreq_governor.h |  3 ++
>  drivers/cpufreq/cpufreq_ondemand.c | 59 +++++++++++++++++++++++++++++++++++++-
>  3 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 41e5e56..1d9abc4 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -328,6 +328,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  		} 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);
>  		}
>  
> diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
> index 1f7de13..c33b37a 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -95,6 +95,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 {
> @@ -113,6 +114,8 @@ struct od_dbs_tuners {
>  	unsigned int adj_up_threshold;
>  	unsigned int powersave_bias;
>  	unsigned int io_is_busy;
> +	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 29ed48a..6cd59a7 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -31,6 +31,7 @@
>  #define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
>  #define DEF_FREQUENCY_UP_THRESHOLD		(80)
>  #define DEF_SAMPLING_DOWN_FACTOR		(1)
> +#define DEF_GRAD_UP_THRESHOLD			(50)
>  #define MAX_SAMPLING_DOWN_FACTOR		(100000)
>  #define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
>  #define MICRO_FREQUENCY_UP_THRESHOLD		(95)
> @@ -168,11 +169,26 @@ static void od_check_cpu(int cpu, unsigned int load_freq)
>  	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
>  	struct dbs_data *dbs_data = policy->governor_data;
>  	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	int boost_freq = 0;
>  
>  	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) and
> +	 * we increase the frequency immediately
> +	 */
> +	if (od_tuners->early_demand) {
> +		if (load_freq > dbs_info->prev_load_freq &&
> +		   (load_freq - dbs_info->prev_load_freq >
> +		    od_tuners->grad_up_threshold * policy->cur))
> +			boost_freq = 1;
> +
> +		dbs_info->prev_load_freq = load_freq;
> +	}
> +
>  	/* Check for frequency increase */
> -	if (load_freq > od_tuners->up_threshold * policy->cur) {
> +	if (boost_freq || load_freq > od_tuners->up_threshold * policy->cur) {
>  		/* If switching to max speed, apply sampling_down_factor */
>  		if (policy->cur < policy->max)
>  			dbs_info->rate_mult =
> @@ -454,12 +470,47 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *policy,
>  	return count;
>  }
>  
> +static ssize_t store_grad_up_threshold(struct cpufreq_policy *policy,
> +		const char *buf, size_t count)
> +{
> +	struct dbs_data *dbs_data = policy->governor_data;
> +	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	unsigned int input;
> +	int ret;
> +	ret = sscanf(buf, "%u", &input);
> +
> +	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
> +			input < MIN_FREQUENCY_UP_THRESHOLD) {
> +		return -EINVAL;
> +	}
> +
> +	od_tuners->grad_up_threshold = input;
> +	return count;
> +}
> +
> +static ssize_t store_early_demand(struct cpufreq_policy *policy,
> +		const char *buf, size_t count)
> +{
> +	struct dbs_data *dbs_data = policy->governor_data;
> +	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	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, ignore_nice);
>  show_one(od, powersave_bias, powersave_bias);
> +show_one(od, grad_up_threshold, grad_up_threshold);
> +show_one(od, early_demand, early_demand);
>  declare_show_sampling_rate_min();
>  
>  cpufreq_freq_attr_rw(sampling_rate);
> @@ -468,6 +519,8 @@ cpufreq_freq_attr_rw(up_threshold);
>  cpufreq_freq_attr_rw(sampling_down_factor);
>  cpufreq_freq_attr_rw(ignore_nice);
>  cpufreq_freq_attr_rw(powersave_bias);
> +cpufreq_freq_attr_rw(grad_up_threshold);
> +cpufreq_freq_attr_rw(early_demand);
>  cpufreq_freq_attr_ro(sampling_rate_min);
>  
>  static struct attribute *dbs_attributes[] = {
> @@ -478,6 +531,8 @@ static struct attribute *dbs_attributes[] = {
>  	&ignore_nice.attr,
>  	&powersave_bias.attr,
>  	&io_is_busy.attr,
> +	&grad_up_threshold.attr,
> +	&early_demand.attr,
>  	NULL
>  };
>  
> @@ -525,9 +580,11 @@ static int od_init(struct dbs_data *dbs_data)
>  	}
>  
>  	tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
> +	tuners->grad_up_threshold = DEF_GRAD_UP_THRESHOLD;
>  	tuners->ignore_nice = 0;
>  	tuners->powersave_bias = 0;
>  	tuners->io_is_busy = should_io_be_busy();
> +	tuners->early_demand = 0;
>  
>  	dbs_data->tuners = tuners;
>  	mutex_init(&dbs_data->mutex);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Rafael J. Wysocki]

On Saturday, March 30, 2013 12:27:34 AM Stratos Karafotis wrote:
> On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> > On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:
> >
> >> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> > 
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > 
> 
> Hi Rafael,
> 
> In case you are interested in this patch I rebased it to the latest linux-pm/bleeding-edge.

Thanks!

I have a backlog of cpufreq patches to sort out, so it may take some time till
I get to this one.

Thanks,
Rafael


> ------------------------------------------
> 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) and we increase frequency immediately.
> 
> New tuners are introduced:
> - early_demand: to enable this functionality (disabled by default).
> - grad_up_threshold: over this gradient of load we will increase
> frequency immediately.
> 
> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> ---
>  drivers/cpufreq/cpufreq_governor.c |  1 +
>  drivers/cpufreq/cpufreq_governor.h |  3 ++
>  drivers/cpufreq/cpufreq_ondemand.c | 59 +++++++++++++++++++++++++++++++++++++-
>  3 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 41e5e56..1d9abc4 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -328,6 +328,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  		} 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);
>  		}
>  
> diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
> index 1f7de13..c33b37a 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -95,6 +95,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 {
> @@ -113,6 +114,8 @@ struct od_dbs_tuners {
>  	unsigned int adj_up_threshold;
>  	unsigned int powersave_bias;
>  	unsigned int io_is_busy;
> +	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 29ed48a..6cd59a7 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -31,6 +31,7 @@
>  #define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
>  #define DEF_FREQUENCY_UP_THRESHOLD		(80)
>  #define DEF_SAMPLING_DOWN_FACTOR		(1)
> +#define DEF_GRAD_UP_THRESHOLD			(50)
>  #define MAX_SAMPLING_DOWN_FACTOR		(100000)
>  #define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
>  #define MICRO_FREQUENCY_UP_THRESHOLD		(95)
> @@ -168,11 +169,26 @@ static void od_check_cpu(int cpu, unsigned int load_freq)
>  	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
>  	struct dbs_data *dbs_data = policy->governor_data;
>  	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	int boost_freq = 0;
>  
>  	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) and
> +	 * we increase the frequency immediately
> +	 */
> +	if (od_tuners->early_demand) {
> +		if (load_freq > dbs_info->prev_load_freq &&
> +		   (load_freq - dbs_info->prev_load_freq >
> +		    od_tuners->grad_up_threshold * policy->cur))
> +			boost_freq = 1;
> +
> +		dbs_info->prev_load_freq = load_freq;
> +	}
> +
>  	/* Check for frequency increase */
> -	if (load_freq > od_tuners->up_threshold * policy->cur) {
> +	if (boost_freq || load_freq > od_tuners->up_threshold * policy->cur) {
>  		/* If switching to max speed, apply sampling_down_factor */
>  		if (policy->cur < policy->max)
>  			dbs_info->rate_mult =
> @@ -454,12 +470,47 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *policy,
>  	return count;
>  }
>  
> +static ssize_t store_grad_up_threshold(struct cpufreq_policy *policy,
> +		const char *buf, size_t count)
> +{
> +	struct dbs_data *dbs_data = policy->governor_data;
> +	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	unsigned int input;
> +	int ret;
> +	ret = sscanf(buf, "%u", &input);
> +
> +	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
> +			input < MIN_FREQUENCY_UP_THRESHOLD) {
> +		return -EINVAL;
> +	}
> +
> +	od_tuners->grad_up_threshold = input;
> +	return count;
> +}
> +
> +static ssize_t store_early_demand(struct cpufreq_policy *policy,
> +		const char *buf, size_t count)
> +{
> +	struct dbs_data *dbs_data = policy->governor_data;
> +	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> +	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, ignore_nice);
>  show_one(od, powersave_bias, powersave_bias);
> +show_one(od, grad_up_threshold, grad_up_threshold);
> +show_one(od, early_demand, early_demand);
>  declare_show_sampling_rate_min();
>  
>  cpufreq_freq_attr_rw(sampling_rate);
> @@ -468,6 +519,8 @@ cpufreq_freq_attr_rw(up_threshold);
>  cpufreq_freq_attr_rw(sampling_down_factor);
>  cpufreq_freq_attr_rw(ignore_nice);
>  cpufreq_freq_attr_rw(powersave_bias);
> +cpufreq_freq_attr_rw(grad_up_threshold);
> +cpufreq_freq_attr_rw(early_demand);
>  cpufreq_freq_attr_ro(sampling_rate_min);
>  
>  static struct attribute *dbs_attributes[] = {
> @@ -478,6 +531,8 @@ static struct attribute *dbs_attributes[] = {
>  	&ignore_nice.attr,
>  	&powersave_bias.attr,
>  	&io_is_busy.attr,
> +	&grad_up_threshold.attr,
> +	&early_demand.attr,
>  	NULL
>  };
>  
> @@ -525,9 +580,11 @@ static int od_init(struct dbs_data *dbs_data)
>  	}
>  
>  	tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
> +	tuners->grad_up_threshold = DEF_GRAD_UP_THRESHOLD;
>  	tuners->ignore_nice = 0;
>  	tuners->powersave_bias = 0;
>  	tuners->io_is_busy = should_io_be_busy();
> +	tuners->early_demand = 0;
>  
>  	dbs_data->tuners = tuners;
>  	mutex_init(&dbs_data->mutex);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:
>
>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 

Hi Rafael,

In case you are interested in this patch I rebased it to the latest linux-pm/bleeding-edge.

Thanks,
Stratos

------------------------------------------
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) and we increase frequency immediately.

New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this gradient of load we will increase
frequency immediately.

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

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 41e5e56..1d9abc4 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -328,6 +328,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 		} 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);
 		}
 
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 1f7de13..c33b37a 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -95,6 +95,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 {
@@ -113,6 +114,8 @@ struct od_dbs_tuners {
 	unsigned int adj_up_threshold;
 	unsigned int powersave_bias;
 	unsigned int io_is_busy;
+	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 29ed48a..6cd59a7 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -31,6 +31,7 @@
 #define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
 #define DEF_FREQUENCY_UP_THRESHOLD		(80)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
+#define DEF_GRAD_UP_THRESHOLD			(50)
 #define MAX_SAMPLING_DOWN_FACTOR		(100000)
 #define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
 #define MICRO_FREQUENCY_UP_THRESHOLD		(95)
@@ -168,11 +169,26 @@ static void od_check_cpu(int cpu, unsigned int load_freq)
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
 	struct dbs_data *dbs_data = policy->governor_data;
 	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	int boost_freq = 0;
 
 	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) and
+	 * we increase the frequency immediately
+	 */
+	if (od_tuners->early_demand) {
+		if (load_freq > dbs_info->prev_load_freq &&
+		   (load_freq - dbs_info->prev_load_freq >
+		    od_tuners->grad_up_threshold * policy->cur))
+			boost_freq = 1;
+
+		dbs_info->prev_load_freq = load_freq;
+	}
+
 	/* Check for frequency increase */
-	if (load_freq > od_tuners->up_threshold * policy->cur) {
+	if (boost_freq || load_freq > od_tuners->up_threshold * policy->cur) {
 		/* If switching to max speed, apply sampling_down_factor */
 		if (policy->cur < policy->max)
 			dbs_info->rate_mult =
@@ -454,12 +470,47 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *policy,
 	return count;
 }
 
+static ssize_t store_grad_up_threshold(struct cpufreq_policy *policy,
+		const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = policy->governor_data;
+	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+
+	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
+			input < MIN_FREQUENCY_UP_THRESHOLD) {
+		return -EINVAL;
+	}
+
+	od_tuners->grad_up_threshold = input;
+	return count;
+}
+
+static ssize_t store_early_demand(struct cpufreq_policy *policy,
+		const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = policy->governor_data;
+	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	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, ignore_nice);
 show_one(od, powersave_bias, powersave_bias);
+show_one(od, grad_up_threshold, grad_up_threshold);
+show_one(od, early_demand, early_demand);
 declare_show_sampling_rate_min();
 
 cpufreq_freq_attr_rw(sampling_rate);
@@ -468,6 +519,8 @@ cpufreq_freq_attr_rw(up_threshold);
 cpufreq_freq_attr_rw(sampling_down_factor);
 cpufreq_freq_attr_rw(ignore_nice);
 cpufreq_freq_attr_rw(powersave_bias);
+cpufreq_freq_attr_rw(grad_up_threshold);
+cpufreq_freq_attr_rw(early_demand);
 cpufreq_freq_attr_ro(sampling_rate_min);
 
 static struct attribute *dbs_attributes[] = {
@@ -478,6 +531,8 @@ static struct attribute *dbs_attributes[] = {
 	&ignore_nice.attr,
 	&powersave_bias.attr,
 	&io_is_busy.attr,
+	&grad_up_threshold.attr,
+	&early_demand.attr,
 	NULL
 };
 
@@ -525,9 +580,11 @@ static int od_init(struct dbs_data *dbs_data)
 	}
 
 	tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
+	tuners->grad_up_threshold = DEF_GRAD_UP_THRESHOLD;
 	tuners->ignore_nice = 0;
 	tuners->powersave_bias = 0;
 	tuners->io_is_busy = should_io_be_busy();
+	tuners->early_demand = 0;
 
 	dbs_data->tuners = tuners;
 	mutex_init(&dbs_data->mutex);
-- 
1.8.1.4

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Rafael J. Wysocki]

On Friday, February 22, 2013 11:27:09 AM Viresh Kumar wrote:
> On Fri, Feb 22, 2013 at 7:26 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:
> 
> >> 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) and we increase frequency immediately.
> >>
> >> New tuners are introduced:
> >> - early_demand: to enable this functionality (disabled by default).
> >> - grad_up_threshold: over this gradient of load we will increase
> >> frequency immediately.
> >>
> >> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> Rafael,
> 
> I applied it here with my Ack over my patches, for getting a run by
> "kbuild test robot".
> 
> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-for-3.10

Thanks, but I'm still not entirely sure about the have_multiple_policies stuff
(yes, I saw your arguments) and the v3.10 merge window is still two months
away.  IOW, please slow down a bit.

Thanks,
Rafael


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

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

On Fri, Feb 22, 2013 at 7:26 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:

>> 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) and we increase frequency immediately.
>>
>> New tuners are introduced:
>> - early_demand: to enable this functionality (disabled by default).
>> - grad_up_threshold: over this gradient of load we will increase
>> frequency immediately.
>>
>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Rafael,

I applied it here with my Ack over my patches, for getting a run by
"kbuild test robot".

http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-for-3.10

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Viresh Kumar]

On 21 February 2013 23:09, Stratos Karafotis <stratosk@semaphore.gr> wrote:
> Thanks again. Following V3 with your suggestion.
>
> Regards,
> Stratos
>
> -----------------------8<--------------------------------------------
> 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) and we increase frequency immediately.
>
> New tuners are introduced:
> - early_demand: to enable this functionality (disabled by default).
> - grad_up_threshold: over this gradient of load we will increase
> frequency immediately.
>
> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

[Stratos Karafotis]

Hi,

On 02/21/2013 05:33 PM, Viresh Kumar wrote:
> Hi Again,
> 
> int boost_freq = 0;
> 
>         if (od_tuners->early_demand) {
>                 if (load_freq > dbs_info->prev_load_freq && (load_freq
> - dbs_info->prev_load_freq >
>                     od_tuners->grad_up_threshold * policy->cur)) {
>                     boost_freq = 1;
>                 }
> 
>                 dbs_info->prev_load_freq = load_freq;
>         }
> 
>          /* Check for frequency increase */
>          if (boost_freq || (load_freq > od_tuners->up_threshold * policy->cur)) {
>                   increase-freq;
> 
> 
> This would get rid of duplicate calls to increase_freq() and also
> avoid changing its
> prototype.
> 

Thanks again. Following V3 with your suggestion.

Regards,
Stratos

-----------------------8<--------------------------------------------
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) and we increase frequency immediately.

New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this gradient of load we will increase
frequency immediately.

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

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 7722505..e737aa9 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -322,6 +322,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 		} 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);
 		}
 
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 6301790..3a703b9 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -96,6 +96,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 {
@@ -114,6 +115,8 @@ struct od_dbs_tuners {
 	unsigned int adj_up_threshold;
 	unsigned int powersave_bias;
 	unsigned int io_is_busy;
+	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 c5fd794..fa4b21e 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -31,6 +31,7 @@
 #define DEF_FREQUENCY_DOWN_DIFFERENTIAL		(10)
 #define DEF_FREQUENCY_UP_THRESHOLD		(80)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
+#define DEF_GRAD_UP_THRESHOLD			(50)
 #define MAX_SAMPLING_DOWN_FACTOR		(100000)
 #define MICRO_FREQUENCY_DOWN_DIFFERENTIAL	(3)
 #define MICRO_FREQUENCY_UP_THRESHOLD		(95)
@@ -168,11 +169,26 @@ static void od_check_cpu(int cpu, unsigned int load_freq)
 	struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
 	struct dbs_data *dbs_data = policy->governor_data;
 	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	int boost_freq = 0;
 
 	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) and
+	 * we increase the frequency immediately
+	 */
+	if (od_tuners->early_demand) {
+		if (load_freq > dbs_info->prev_load_freq &&
+		   (load_freq - dbs_info->prev_load_freq >
+		    od_tuners->grad_up_threshold * policy->cur))
+			boost_freq = 1;
+
+		dbs_info->prev_load_freq = load_freq;
+	}
+
 	/* Check for frequency increase */
-	if (load_freq > od_tuners->up_threshold * policy->cur) {
+	if (boost_freq || (load_freq > od_tuners->up_threshold * policy->cur)) {
 		/* If switching to max speed, apply sampling_down_factor */
 		if (policy->cur < policy->max)
 			dbs_info->rate_mult =
@@ -445,12 +461,47 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *policy,
 	return count;
 }
 
+static ssize_t store_grad_up_threshold(struct cpufreq_policy *policy,
+		const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = policy->governor_data;
+	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	unsigned int input;
+	int ret;
+	ret = sscanf(buf, "%u", &input);
+
+	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
+			input < MIN_FREQUENCY_UP_THRESHOLD) {
+		return -EINVAL;
+	}
+
+	od_tuners->grad_up_threshold = input;
+	return count;
+}
+
+static ssize_t store_early_demand(struct cpufreq_policy *policy,
+		const char *buf, size_t count)
+{
+	struct dbs_data *dbs_data = policy->governor_data;
+	struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+	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, ignore_nice);
 show_one(od, powersave_bias, powersave_bias);
+show_one(od, grad_up_threshold, grad_up_threshold);
+show_one(od, early_demand, early_demand);
 declare_show_sampling_rate_min();
 
 cpufreq_freq_attr_rw(sampling_rate);
@@ -459,6 +510,8 @@ cpufreq_freq_attr_rw(up_threshold);
 cpufreq_freq_attr_rw(sampling_down_factor);
 cpufreq_freq_attr_rw(ignore_nice);
 cpufreq_freq_attr_rw(powersave_bias);
+cpufreq_freq_attr_rw(grad_up_threshold);
+cpufreq_freq_attr_rw(early_demand);
 cpufreq_freq_attr_ro(sampling_rate_min);
 
 static struct attribute *dbs_attributes[] = {
@@ -469,6 +522,8 @@ static struct attribute *dbs_attributes[] = {
 	&ignore_nice.attr,
 	&powersave_bias.attr,
 	&io_is_busy.attr,
+	&grad_up_threshold.attr,
+	&early_demand.attr,
 	NULL
 };
 
@@ -516,9 +571,11 @@ static int od_init(struct dbs_data *dbs_data)
 	}
 
 	tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
+	tuners->grad_up_threshold = DEF_GRAD_UP_THRESHOLD;
 	tuners->ignore_nice = 0;
 	tuners->powersave_bias = 0;
 	tuners->io_is_busy = should_io_be_busy();
+	tuners->early_demand = 0;
 
 	dbs_data->tuners = tuners;
 	mutex_init(&dbs_data->mutex);
-- 
1.8.1.2