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" <[email protected]> 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?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On 3 April 2013 12:01, stratosk <[email protected]> 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...
On Wednesday, April 03, 2013 12:13:56 PM Viresh Kumar wrote:
> On 3 April 2013 12:01, stratosk <[email protected]> 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.
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 <[email protected]> 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%
Hi Stratos,
On 4 April 2013 05:00, Stratos Karafotis <[email protected]> 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
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%
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
On 9 April 2013 22:26, Stratos Karafotis <[email protected]> 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:?
On 04/10/2013 06:22 AM, Viresh Kumar wrote:
> On 9 April 2013 22:26, Stratos Karafotis <[email protected]> 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
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