cpufreq: ondemand: Change the calculation of target frequency

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 10 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

Quoted 7 lines

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

I read this as "the workload takes longer to complete" which means higher power consumption and longer execution times which means less time spent in idle. And I don't think we want that.

Yes, no?

Thanks.

When you are doing a locally-originated truly CPU-bound task, "race to idle" does make some sense. But I can think of a couple of caveats.

1) If you care about power consumption, you want to avoid super-power-hungry turbo states, as you get less done per watt-hour than in some of the middle states.

2) CPU usage that is related to I/O (network, disk, video) doesn't necessarily let you go to idle sooner if at all. In this case if you want to minimize power consumption you may want to use middle states a lot. But if you care more about responsiveness or latency than power consumption, you might want to go to a high state anyway; that is why we have tunables -- so we can configure based on the actual priorities for the machine.

The correct "fix" for this whole deal is coupling cpufreq with the scheduler, as it has been said so many times before. You need "something" which can tell you whether raising the freq. is worth it or not (i.e. the process is waiting on IO or is executing instructions).

Please do not top-post.

Quoted 7 lines · David C Niemi

When you are doing a locally-originated truly CPU-bound task, "race to idle" does make some sense. But I can think of a couple of caveats.

1) If you care about power consumption, you want to avoid super-power-hungry turbo states, as you get less done per watt-hour than in some of the middle states.

Quoted 7 lines

2) CPU usage that is related to I/O (network, disk, video) doesn't necessarily let you go to idle sooner if at all. In this case if you want to minimize power consumption you may want to use middle states a lot. But if you care more about responsiveness or latency than power consumption, you might want to go to a high state anyway; that is why we have tunables -- so we can configure based on the actual priorities for the machine.

No, users don't always know about tunables - this should Just Work(tm).

The correct "fix" for this whole deal is coupling cpufreq with the scheduler, as it has been said so many times before. You need "something" which can tell you whether raising the freq. is worth it or not (i.e. the process is waiting on IO or is executing instructions).

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 10 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

Quoted 7 lines

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

I read this as "the workload takes longer to complete" which means higher power consumption and longer execution times which means less time spent in idle. And I don't think we want that.

Yes, no?

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.
Now, ondemand does not increase freq. CPU runs in lowest freq till the load is greater than up_threshold.

Quoted 21 lines

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 17 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Quoted 11 lines · Stratos Karafotis

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 7 lines

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 6 lines

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.

Hold on, you say above "easily saturate minimum frequency and lead the CPU to max". I read this as we jump straight to max P-state where we even boost.

"CPU to max" finishes the work faster than middle frequencies, if you're CPU-bound.

his patch will give significant improvement both power & performance wise.

Quoted 1 line · Viresh Kumar

his patch will give significant improvement both power & performance wise.

Yes, and I'd like to see the paperwork on that. Numbers, and on a couple of platforms/vendors if possible, please.

Thanks.

Quoted 2 lines

I will try to provide the requested info (although, I'm not sure how to measure total energy :) )

tools/power/x86/turbostat looks like a good tool. It can show, a.o., power consumption in Watts on modern Intels and other interesting stuff.

HTH.

Apologies for top-posting. I was able to send email only from my phone.

Thanks for you hint about turbostat.

As you most probably understood, I'm individual amateur kernel developer. I could provide some numbers from x86 architecture as Rafael suggested. But unfortunately, I don't have access to more sources/infrastructure. So, I will not be able to provide numbers from different platform(s).

I've already provided some benchmarks from x86 (3.10-rc3) and also tested the patch in 3.4.47 kernel (ARM, Nexus 4 phone, ~1000 installations) and in 3.0.80 kernel (ARM, Samsung Galaxy S phone, ~1500 installations).

Kindly let me know if "couple of platforms/vendors" is a show stopper for this patch series. If yes, please ignore this patch and accept my apologies for wasting your time. I am just trying to contribute on this project (I believe there is space here for amateur developers).

Quoted 13 lines · Stratos Karafotis

Apologies for top-posting. I was able to send email only from my phone.

Thanks for you hint about turbostat.

As you most probably understood, I'm individual amateur kernel developer. I could provide some numbers from x86 architecture as Rafael suggested. But unfortunately, I don't have access to more sources/infrastructure. So, I will not be able to provide numbers from different platform(s).

I've already provided some benchmarks from x86 (3.10-rc3) and also tested the patch in 3.4.47 kernel (ARM, Nexus 4 phone, ~1000 installations) and in 3.0.80 kernel (ARM, Samsung Galaxy S phone, ~1500 installations).

Quoted 4 lines

Kindly let me know if "couple of platforms/vendors" is a show stopper for this patch series. If yes, please ignore this patch and accept my apologies for wasting your time. I am just trying to contribute on this project (I believe there is space here for amateur developers).

I'm in no way discouraging you in contributing to the kernel - on the
opposite: you should continue doing that.

I'm just trying to make sure that a change like that doesn't hurt existing systems, thus the request to test on a couple of platforms. If you don't have other platforms, that's fine, we'll find them somewhere. :-)

I'm hoping you can understand my aspect too, though - how would you feel if a patch shows improvement on my box but slows down yours - you won't be very happy with it, right? That's why we generally want to test such power/performance tweaks on a wider range of machines.

But you said you have a i7-3770 CPU on which, I think, turbostat should be able to show you how the power consumption looks like.

And if so, you could measure that consumption once with, and once without your patch. This will give us initial numbers, at least.

How does that sound?

Quoted 19 lines · Stratos Karafotis

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 30 lines

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.
Now, ondemand does not increase freq. CPU runs in lowest freq till the load is greater than up_threshold.

Quoted 21 lines

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 17 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Can you also use powertop to measure the percentage of time spent in idle states for the same workload with and without your patchset? Also, it would be good to measure the total energy consumption somehow ...

Thanks,
Rafael

Quoted 51 lines · Rafael J. Wysocki

Quoted 19 lines · Stratos Karafotis

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 30 lines

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.
Now, ondemand does not increase freq. CPU runs in lowest freq till the load is greater than up_threshold.

Quoted 21 lines

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 17 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Quoted 6 lines

Can you also use powertop to measure the percentage of time spent in idle states for the same workload with and without your patchset? Also, it would be good to measure the total energy consumption somehow ...

Thanks,
Rafael

Hi Rafael,

I repeated the tests extracting also powertop results. Measurement steps with and without this patch:
1) Reboot system
2) Running twice Phoronix benchmark of Linux Kernel Compilation 3.1 test without taking measurement
3) Wait few minutes
4) Run Phoronix and powertop for 100secs and take measurement.

I will try to repeat the test and take measurements with turbostat as Borislav suggested.

------------------------------------------------------------------
Test WITHOUT this patch:

Phoronix Test Suite v4.6.0

    Installed: pts/build-linux-kernel-1.3.0

System Information

Hardware:
Processor: Intel Core i7-3770 @ 3.40GHz (8 Cores), Motherboard: ASUS CM6870, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 2 x 4096 MB DDR3-1600MHz HY64C1C1624ZY, Disk: 1000GB Seagate ST1000DM003-9YN1, Graphics: NVIDIA GeForce GT 640 3072MB, Audio: Realtek ALC892, Monitor: S23B350, Network: Realtek RTL8111/8168 + Ralink RT3090 Wireless 802.11n 1T/1R

Software:
OS: Fedora 18, Kernel: 3.10.0-rc3v+ (x86_64), Desktop: KDE 4.10.3, Display Server: X Server 1.13.3, Display Driver: nouveau 1.0.7, File-System: ext4, Screen Resolution: 1920x1080

Would you like to save these test results (Y/n): n

Timed Linux Kernel Compilation 3.1:

    pts/build-linux-kernel-1.3.0
    Test 1 of 1
    Estimated Trial Run Count:    3
    Estimated Time To Completion: 2 Minutes
        Running Pre-Test Script @ 21:41:19
        Started Run 1 @ 21:41:30
        Running Interim Test Script @ 21:41:44
        Started Run 2 @ 21:41:47
        Running Interim Test Script @ 21:42:02
        Started Run 3 @ 21:42:05
        Running Interim Test Script @ 21:42:15  [Std. Dev: 19.28%]
        Started Run 4 @ 21:42:19
        Running Interim Test Script @ 21:42:29  [Std. Dev: 18.72%]
        Started Run 5 @ 21:42:32
        Running Interim Test Script @ 21:42:42  [Std. Dev: 17.84%]
        Started Run 6 @ 21:42:46  [Std. Dev: 16.91%]
        Running Post-Test Script @ 21:42:55

    Test Results:
        11.073544979095
        14.059958934784
        9.6814110279083
        9.6158590316772
        9.5762379169464
        9.5944919586182

    Average: 10.60 Seconds

Powertop results:
http://www.semaphore.gr/results/powertop_without.html

---------------------------------------------------------------------
Test WITH this patch:

Phoronix Test Suite v4.6.0

    Installed: pts/build-linux-kernel-1.3.0

System Information

Hardware:
Processor: Intel Core i7-3770 @ 3.40GHz (8 Cores), Motherboard: ASUS CM6870, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 2 x 4096 MB DDR3-1600MHz HY64C1C1624ZY, Disk: 1000GB Seagate ST1000DM003-9YN1, Graphics: NVIDIA GeForce GT 640 3072MB, Audio: Realtek ALC892, Monitor: S23B350, Network: Realtek RTL8111/8168 + Ralink RT3090 Wireless 802.11n 1T/1R

Software:
OS: Fedora 18, Kernel: 3.10.0-rc3+ (x86_64), Desktop: KDE 4.10.3, Display Server: X Server 1.13.3, Display Driver: nouveau 1.0.7, File-System: ext4, Screen Resolution: 1920x1080

Would you like to save these test results (Y/n): n

Timed Linux Kernel Compilation 3.1:

    pts/build-linux-kernel-1.3.0
    Test 1 of 1
    Estimated Trial Run Count:    3
    Estimated Time To Completion: 2 Minutes
        Running Pre-Test Script @ 21:28:05
        Started Run 1 @ 21:28:17
        Running Interim Test Script @ 21:28:30
        Started Run 2 @ 21:28:34
        Running Interim Test Script @ 21:28:44
        Started Run 3 @ 21:28:47
        Running Interim Test Script @ 21:28:58  [Std. Dev: 4.81%]
        Started Run 4 @ 21:29:02
        Running Interim Test Script @ 21:29:12  [Std. Dev: 6.05%]
        Started Run 5 @ 21:29:15
        Running Interim Test Script @ 21:29:25  [Std. Dev: 6.13%]
        Started Run 6 @ 21:29:28  [Std. Dev: 6.02%]
        Running Post-Test Script @ 21:29:38

    Test Results:
        10.442322015762
        10.038927078247
        11.044027090073
        9.5781810283661
        9.5812470912933
        9.5545389652252

    Average: 10.04 Seconds

Powertop results:
http://www.semaphore.gr/results/powertop_with.html
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 61 lines · Stratos Karafotis

Quoted 51 lines · Rafael J. Wysocki

Quoted 19 lines · Stratos Karafotis

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 30 lines

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.
Now, ondemand does not increase freq. CPU runs in lowest freq till the load is greater than up_threshold.

Quoted 21 lines

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 17 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Quoted 6 lines

Can you also use powertop to measure the percentage of time spent in idle states for the same workload with and without your patchset? Also, it would be good to measure the total energy consumption somehow ...

Thanks,
Rafael

Hi Rafael,

Quoted 7 lines

I repeated the tests extracting also powertop results. Measurement steps with and without this patch:
1) Reboot system
2) Running twice Phoronix benchmark of Linux Kernel Compilation 3.1 test without taking measurement
3) Wait few minutes
4) Run Phoronix and powertop for 100secs and take measurement.

Well, while this is not conclusive, it definitely looks very promising. :-)

We're seeing measurable performance improvement with the patchset applied *and* more time spent in idle states both at the same time. I'd be very surprised if the energy consumption measuremets did not confirm that the patchset allowed us to reduce it.

If my computations are correct (somebody please check), the cores spent about 20% more time in idle on the average with the patchset applied and in addition to that the cc6 residency was greater by about 2% on the average with respect to the kernel without the patchset.

We need to verify if there are gains (or at least no regressions) with other workloads, but since this *also* reduces code complexity quite a bit, I'm seriously considering taking it.

Quoted 2 lines

I will try to repeat the test and take measurements with turbostat as Borislav suggested.

Please do!

Thanks,
Rafael

Quoted 86 lines · Rafael J. Wysocki

Quoted 61 lines · Stratos Karafotis

Quoted 51 lines · Rafael J. Wysocki

Quoted 19 lines · Stratos Karafotis

Hi Borislav,

Quoted 8 lines · Borislav Petkov

Quoted 6 lines · Stratos Karafotis

Ondemand calculates load in terms of frequency and increases it only if the load_freq is greater than up_threshold multiplied by current or average frequency. This seems to produce oscillations of frequency between min and max because, for example, a relatively small load can easily saturate minimum frequency and lead the CPU to max. Then, the CPU will decrease back to min due to a small load_freq.

Quoted 4 lines

Right, and I think this is how we want it, no?

The thing is, the faster you finish your work, the faster you can become idle and save power.

This is exactly the goal of this patch. To use more efficiently middle frequencies to finish faster the work.

Quoted 30 lines

Quoted 3 lines

If you switch frequencies in a staircase-like manner, you're going to take longer to finish, in certain cases, and burn more power while doing so.

This is not true with this patch. It switches to middle frequencies when the load < up_threshold.
Now, ondemand does not increase freq. CPU runs in lowest freq till the load is greater than up_threshold.

Quoted 21 lines

Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you can finish sooner.

Quoted 17 lines

This patch changes the calculation method of load and target frequency considering 2 points:
- Load computation should be independent from current or average measured frequency. For example an absolute load 80% at 100MHz is not necessarily equivalent to 8% at 1000MHz in the next sampling interval.
- Target frequency should be increased to any value of frequency table proportional to absolute load, instead to only the max. Thus:

Target frequency = C * load

where C = policy->cpuinfo.max_freq / 100

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait. Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an increase ~1.5% in performance. cpufreq_stats (time_in_state) shows that middle frequencies are used more, with this patch. Highest and lowest frequencies were used less by ~9%

Quoted 6 lines

Can you also use powertop to measure the percentage of time spent in idle states for the same workload with and without your patchset? Also, it would be good to measure the total energy consumption somehow ...

Thanks,
Rafael

Hi Rafael,

Quoted 7 lines

I repeated the tests extracting also powertop results. Measurement steps with and without this patch:
1) Reboot system
2) Running twice Phoronix benchmark of Linux Kernel Compilation 3.1 test without taking measurement
3) Wait few minutes
4) Run Phoronix and powertop for 100secs and take measurement.

Well, while this is not conclusive, it definitely looks very promising. :-)

We're seeing measurable performance improvement with the patchset applied *and* more time spent in idle states both at the same time. I'd be very surprised if the energy consumption measuremets did not confirm that the patchset allowed us to reduce it.

If my computations are correct (somebody please check), the cores spent about 20% more time in idle on the average with the patchset applied and in addition to that the cc6 residency was greater by about 2% on the average with respect to the kernel without the patchset.

We need to verify if there are gains (or at least no regressions) with other workloads, but since this *also* reduces code complexity quite a bit, I'm seriously considering taking it.

Quoted 8 lines

Quoted 2 lines

I will try to repeat the test and take measurements with turbostat as Borislav suggested.

Please do!

Thanks,
Rafael

Hi,

I repeated the tests extracting results from turbostat. Measurement steps with and without this patch:
1) Reboot system
2) Running twice Phoronix benchmark of Linux Kernel Compilation 3.1 test without taking measurement
3) Wait few minutes
4) Run Phoronix and turbostat (-i 100) and take measurement