Hi Andrey,
This is more of announcement than a PULL request. :)
Most of us are working with interactive governor. But most of us use a different version of it, as it is not yet mainlined and there is no hope of it getting mainlined.
http://lists.linaro.org/pipermail/linaro-kernel/2012-February/001122.html
So, we have decided to keep the latest version within Linaro and make it part of our release, so that everybody works with the same version and use it in ubuntu as well.
I am keeping it in my big LITTLE MP repository in separate branches: - cpufreq-interactive-gov-master-v*: Latest version of governor from google tree - cpufreq-interactive-gov-experimental-v*: Rebased over master with updates from Linaro.
This is a PULL request for master branch:
--------------
The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17:
Linux 3.7-rc7 (2012-11-25 17:59:19 -0800)
are available in the git repository at:
git://git.linaro.org/arm/big.LITTLE/mp.git cpufreq-interactive-gov-master-v1
for you to fetch changes up to 1ad5d36179224fbcdddf8abf3cbfdd183da38b3e:
cpufreq: interactive: kick timer on idle exit past expiry (2012-11-29 00:48:46 +0530)
---------------------------------------------------------------- John Stultz (1): cpufreq-interactive: Compile fixup
Lianwei Wang (1): cpufreq: interactive: use deferrable timer by default
Mike Chan (1): cpufreq: interactive: New 'interactive' governor
Sam Leffler (2): cpufreq: interactive: take idle notifications only when active cpufreq: interactive: keep freezer happy when not current governor
Todd Poynor (24): Move x86_64 idle notifiers to generic ARM: Call idle notifiers ARM: Move leds idle start/stop calls to idle notifiers cpufreq interactive governor: event tracing cpufreq: interactive: apply intermediate load to max speed not current cpufreq: interactive: set at least hispeed when above hispeed load cpufreq: interactive: don't drop speed if recently at higher load cpufreq: interactive: configurable delay before raising above hispeed cpufreq: interactive: adjust code and documentation to match cpufreq: interactive: base hispeed bump on target freq, not actual cpufreq: interactive: Separate speed target revalidate time and initial set time cpufreq: interactive: Boost frequency on touchscreen input cpufreq: interactive: remove unused target_validate_time_in_idle cpufreq: interactive: Add sysfs boost interface for hints from userspace cpufreq: interactive: set floor for boosted speed cpufreq: interactive: add boost pulse interface cpufreq: interactive: restart above_hispeed_delay at each hispeed load cpufreq: interactive: fixup trace of string params cpufreq: interactive: handle speed up and down in the realtime task cpufreq: interactive: remove input_boost handling cpufreq: interactive: always limit initial speed bump to hispeed cpufreq: interactive: run at fraction of hispeed_freq when load is low cpufreq: interactive: pin timers to associated CPU cpufreq: interactive: kick timer on idle exit past expiry
Documentation/cpu-freq/governors.txt | 59 +++ arch/arm/kernel/process.c | 4 +- arch/x86/include/asm/idle.h | 7 - arch/x86/kernel/process.c | 17 +- drivers/cpufreq/Kconfig | 27 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_interactive.c | 754 +++++++++++++++++++++++++++++ drivers/leds/ledtrig-cpu.c | 25 + include/linux/cpu.h | 7 + include/linux/cpufreq.h | 3 + include/trace/events/cpufreq_interactive.h | 106 ++++ kernel/cpu.c | 20 + 12 files changed, 1006 insertions(+), 24 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_interactive.c create mode 100644 include/trace/events/cpufreq_interactive.h
On Thu, 2012-11-29 at 20:45 +0530, Viresh Kumar wrote:
Hi Andrey,
This is more of announcement than a PULL request. :)
Most of us are working with interactive governor. But most of us use a different version of it, as it is not yet mainlined and there is no hope of it getting mainlined.
http://lists.linaro.org/pipermail/linaro-kernel/2012-February/001122.html
So, we have decided to keep the latest version within Linaro and make it part of our release, so that everybody works with the same version and use it in ubuntu as well.
I am keeping it in my big LITTLE MP repository in separate branches:
- cpufreq-interactive-gov-master-v*: Latest version of governor from google tree
- cpufreq-interactive-gov-experimental-v*: Rebased over master with updates from Linaro.
This is a PULL request for master branch:
Linaro's kernel tree already has an interactive governor which is provided by the Android topic branch, so isn't trying to integrate another version going to cause a lot of problems for whoever maintains the two versions and the person having to merge them?
On 29 November 2012 21:43, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Linaro's kernel tree already has an interactive governor which is provided by the Android topic branch, so isn't trying to integrate another version going to cause a lot of problems for whoever maintains the two versions and the person having to merge them?
Hi Tixy,
I believe the version of patches in my tree are going to be almost same to what is present in Android topic branch, and so shouldn't be much issues there.
If the two versions are different, then either i must update it or the other guy. That will guarantee that all are using same and latest version of this governor.
Over that it would be available for ubuntu also.
How do you suggest to solve these issues?
-- viresh
On Fri, 2012-11-30 at 07:47 +0530, Viresh Kumar wrote:
On 29 November 2012 21:43, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Linaro's kernel tree already has an interactive governor which is provided by the Android topic branch, so isn't trying to integrate another version going to cause a lot of problems for whoever maintains the two versions and the person having to merge them?
Hi Tixy,
I believe the version of patches in my tree are going to be almost same to what is present in Android topic branch, and so shouldn't be much issues there.
If the two versions are different, then either i must update it or the other guy.
But if they aren't different why do we need your version? Thing is I not sure who the 'other guy' is who is maintaining the Android topic, it use to always be John Stultz but not sure now.
That will guarantee that all are using same and latest version of this governor.
Is 'the latest version' the one in AOSP?
Over that it would be available for ubuntu also.
But surely it is already available for Ubuntu because the Android topic branch is included in llct. E.g. if you boot a 12.11 Ubuntu image for vexpress and do
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
you will get:
interactive ondemand performance
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic' get together and work it out :-)
Of course, it could be that things go smoothly without any coordination. I just wanted to chime in and make sure that people knew that there could be issues, because these things have a nasty habit of cropping up a few days before a monthly release, when there is little time to fix and test things.
On 30 November 2012 15:22, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Fri, 2012-11-30 at 07:47 +0530, Viresh Kumar wrote: But if they aren't different why do we need your version? Thing is I not sure who the 'other guy' is who is maintaining the Android topic, it use to always be John Stultz but not sure now.
I believe John is maintaining it, as i can guess from git.linaro.org
That will guarantee that all are using same and latest version of this governor.
Is 'the latest version' the one in AOSP?
Yes.
https://android.googlesource.com/kernel/common
Over that it would be available for ubuntu also.
But surely it is already available for Ubuntu because the Android topic branch is included in llct. E.g. if you boot a 12.11 Ubuntu image for vexpress and do
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
you will get:
interactive ondemand performance
Yes. It is. :)
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic' get together and work it out :-)
Of course, it could be that things go smoothly without any coordination. I just wanted to chime in and make sure that people knew that there could be issues, because these things have a nasty habit of cropping up a few days before a monthly release, when there is little time to fix and test things.
@John/Andrey: Current linux-linaro surely doesn't have latest interactive governor in it. How do you guys suggest to get over this issue? I have few ideas: - John pull it from my tree, and i will keep an eye on AOSP - John directly pick patches from AOSP
-- viresh
On 11/30/2012 02:23 PM, Viresh Kumar wrote:
On 30 November 2012 15:22, Jon Medhurst (Tixy) tixy@linaro.org wrote:
But if they aren't different why do we need your version?
To my understanding, having a separate topic for the interactive governor makes sense if some people need this governor, but do not want the rest of android code in their kernel. Viresh, is this the case? This seems to contradict with the initial idea of the single kernel tree (where all the releases should be made from), but may be valuable for the LTs/members and for some development work.
Viresh, I'd like an explicit answer to why do we need a separate topic for the interactive governor (in addition to the android one). We must be sure we would do that extra work for a reason.
On Fri, 2012-11-30 at 07:47 +0530, Viresh Kumar wrote: But if they aren't different why do we need your version? Thing is I not sure who the 'other guy' is who is maintaining the Android topic, it use to always be John Stultz but not sure now.
I believe John is maintaining it, as i can guess from git.linaro.org
John did all the Android topics updates for llct except the last one. Adding Anton (his Android topic has been used for 12.11), and Deepak.
That will guarantee that all are using same and latest version of this governor.
Is 'the latest version' the one in AOSP?
Yes.
So it is from the same source as the android topic for llct. Just the topic by Viresh is a bit more recent, and is a few commits ahead of the android topic currently merged into llct.
Over that it would be available for ubuntu also.
But surely it is already available for Ubuntu because the Android topic branch is included in llct. E.g. if you boot a 12.11 Ubuntu image for vexpress and do
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
you will get:
interactive ondemand performance
Yes. It is. :)
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic'
Deepak, is that ^^^ John, Anton, or someone else? :)
get together and work it out :-)
Of course, it could be that things go smoothly without any coordination.
I don't believe in that :( In a different world - maybe.
I just wanted to chime in and make sure that people knew that there could be issues, because these things have a nasty habit of cropping up a few days before a monthly release, when there is little time to fix and test things.
Viresh,
@John/Andrey: Current linux-linaro surely doesn't have latest interactive governor in it. How do you guys suggest to get over this issue? I have few ideas:
- John pull it from my tree, and i will keep an eye on AOSP
... the problem here is that AOSP is not the interactive governor only. John (or the other "Android topic guy") would have to keep an eye on the rest of AOSP. Keeping two pars of eyes on the same thing requires coordination. Or are you volunteering to take over the android topic? :)
- John directly pick patches from AOSP
... and again, then you and the "Android topic guy" must synchronize somehow. Otherwise we would get into the same situation with two slightly different versions of the interactive governor in the two topics like we have now.
John, Anton,
If one of you will continue to maintain the android topic, for the next cycles could you split a separate interactive governor topic from the android one? Or any other ideas?
Thanks, Andrey
On 30 November 2012 19:00, Andrey Konovalov andrey.konovalov@linaro.org wrote:
On 11/30/2012 02:23 PM, Viresh Kumar wrote:
On 30 November 2012 15:22, Jon Medhurst (Tixy) tixy@linaro.org wrote:
But if they aren't different why do we need your version?
To my understanding, having a separate topic for the interactive governor makes sense if some people need this governor, but do not want the rest of android code in their kernel. Viresh, is this the case? This seems to contradict with the initial idea of the single kernel tree (where all the releases should be made from), but may be valuable for the LTs/members and for some development work.
Viresh, I'd like an explicit answer to why do we need a separate topic for the interactive governor (in addition to the android one). We must be sure we would do that extra work for a reason.
The basic idea was: Everybody from ARM/Linaro/Maybe somebody else, should use the same and the latest version of this governor. And a lot of stuff really depends on it, all power measurements etc..
I have seen people using Tixy's tree (for-example) for their tests and this governor is only present in his android branch. Over that, what if somebody doesn't want to get linux-linaro or android stuff in kernel and yet want to use power with interactive governor.
That's it.
So it is from the same source as the android topic for llct. Just the topic by Viresh is a bit more recent, and is a few commits ahead of the android topic currently merged into llct.
Over that it would be available for ubuntu also.
This governor actually need somewhat better refresh rate. As it affects the way cpus behave in our tests.
I just wanted to chime in and make sure that people knew that there could be issues, because these things have a nasty habit of cropping up a few days before a monthly release, when there is little time to fix and test things.
Viresh,
I accept. Just to mention, i didn't wanted this to get in for this release.
@John/Andrey: Current linux-linaro surely doesn't have latest interactive governor in it. How do you guys suggest to get over this issue? I have few ideas:
- John pull it from my tree, and i will keep an eye on AOSP
... the problem here is that AOSP is not the interactive governor only. John (or the other "Android topic guy") would have to keep an eye on the rest of AOSP. Keeping two pars of eyes on the same thing requires coordination. Or are you volunteering to take over the android topic? :)
No, i am not volunteering for it. But after getting android stuff from AOSP, what's the harm in pulling my branch.
- John directly pick patches from AOSP
... and again, then you and the "Android topic guy" must synchronize somehow.
No. In that case i will not keep this in my tree. But it would be difficult for the android guy to keep an eye on interactive governor updates.
-- viresh
On Fri, Nov 30, 2012 at 05:30:03PM +0400, Andrey Konovalov wrote: [...]
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic'
Deepak, is that ^^^ John, Anton, or someone else? :)
Same question. :)
I can easily pull branch into my Android git tree on infradead.org, but I believe this would be not The Right Thing to do, since it was just a temporary measure.
Thanks, Anton.
On Sat, Dec 1, 2012 at 8:36 AM, Anton Vorontsov anton.vorontsov@linaro.org wrote:
On Fri, Nov 30, 2012 at 05:30:03PM +0400, Andrey Konovalov wrote: [...]
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic'
Deepak, is that ^^^ John, Anton, or someone else? :)
Same question. :)
I can easily pull branch into my Android git tree on infradead.org, but I believe this would be not The Right Thing to do, since it was just a temporary measure.
Thanks, Anton.
Hey guys,
Any conclusion to this discussion? I'd really like the latest version of interactive governor to be carried in all Linaro releases (Android and Ubuntu). The one from the Android tree isn't the latest.
Regards, Amit
On 12/04/2012 02:39 AM, Amit Kucheria wrote:
On Sat, Dec 1, 2012 at 8:36 AM, Anton Vorontsov anton.vorontsov@linaro.org wrote:
On Fri, Nov 30, 2012 at 05:30:03PM +0400, Andrey Konovalov wrote: [...]
How do you suggest to solve these issues?
That you, Andrey and the 'the guy maintaining the Android topic'
Deepak, is that ^^^ John, Anton, or someone else? :)
Same question. :)
I can easily pull branch into my Android git tree on infradead.org, but I believe this would be not The Right Thing to do, since it was just a temporary measure.
Thanks, Anton.
Hey guys,
Any conclusion to this discussion? I'd really like the latest version of interactive governor to be carried in all Linaro releases (Android and Ubuntu). The one from the Android tree isn't the latest.
Sorry, I've been busy with other items and haven't gotten a chance to update the lianro-android tree. I'll spend some time today to try to resolve this.
thanks -john
On 12/04/2012 10:47 AM, John Stultz wrote:
On 12/04/2012 02:39 AM, Amit Kucheria wrote:
Any conclusion to this discussion? I'd really like the latest version of interactive governor to be carried in all Linaro releases (Android and Ubuntu). The one from the Android tree isn't the latest.
Sorry, I've been busy with other items and haven't gotten a chance to update the lianro-android tree. I'll spend some time today to try to resolve this.
Ok, so I've taken the 3.7 rebase tree Anton did while I was on leave and cherry-picked a number of newer changes from the AOSP/android-3.4 branch. This should contain the latest AOSP cpufreq-interactive, ion, and sync drivers.
You can find it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.7-anton-rebase
I've also included fixes from Tushar and Tixy.
Let me know if you notice any other important commits missing from the AOSP tree and I'll try to cherry-pick those in as well.
thanks -john
On 5 December 2012 06:32, John Stultz john.stultz@linaro.org wrote:
Ok, so I've taken the 3.7 rebase tree Anton did while I was on leave and cherry-picked a number of newer changes from the AOSP/android-3.4 branch. This should contain the latest AOSP cpufreq-interactive, ion, and sync drivers.
You can find it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.7-anton-rebase
I've also included fixes from Tushar and Tixy.
Let me know if you notice any other important commits missing from the AOSP tree and I'll try to cherry-pick those in as well.
Hi John,
I haven't checked your repo till now, but the bigger question which this thread had was, how do we ensure that we always have the latest copy of interactive governor in linux-linaro tree?
You would like to pick them yourself from AOSP or us to point to that? Or you can also pull from the branch i created (which only had interactive governor patches)?
-- viresh
On 12/04/2012 08:10 PM, Viresh Kumar wrote:
On 5 December 2012 06:32, John Stultz john.stultz@linaro.org wrote:
Ok, so I've taken the 3.7 rebase tree Anton did while I was on leave and cherry-picked a number of newer changes from the AOSP/android-3.4 branch. This should contain the latest AOSP cpufreq-interactive, ion, and sync drivers.
You can find it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.7-anton-rebase
I've also included fixes from Tushar and Tixy.
Let me know if you notice any other important commits missing from the AOSP tree and I'll try to cherry-pick those in as well.
Hi John,
I haven't checked your repo till now, but the bigger question which this thread had was, how do we ensure that we always have the latest copy of interactive governor in linux-linaro tree? You would like to pick them yourself from AOSP or us to point to that? Or you can also pull from the branch i created (which only had interactive governor patches)?
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
However, if you're maintaining your own tree anyway, why not have Andrey pull your tree in addition to the current linaro-android-3.x-*rebase branch?
Since they are both contain a common subset, the merge will likely be quite easy. That way Andrey's tree will have a better chance of having the latest changes.
Does that seem ok?
One other option, if someone has the cycles and interest, is that I would be fine with handing over the linaro-android tree maintenance responsibilities. If you or anyone else is interested, please send me email and we can work it out.
thanks -john
On 5 December 2012 09:55, John Stultz john.stultz@linaro.org wrote:
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
That might be enough, i suppose.
However, if you're maintaining your own tree anyway, why not have Andrey pull your tree in addition to the current linaro-android-3.x-*rebase branch?
Since they are both contain a common subset, the merge will likely be quite easy. That way Andrey's tree will have a better chance of having the latest changes.
Does that seem ok?
That was the initial idea, but there were concerns from Tixy and Andrey on that. @Andrey: Do you want to comment again?
One other option, if someone has the cycles and interest, is that I would be fine with handing over the linaro-android tree maintenance responsibilities. If you or anyone else is interested, please send me email and we can work it out.
Not me atleast :) I am already maintaining few trees and they are killing my time like anything :) -- viresh
05.12.2012 08:32, Viresh Kumar пишет:
On 5 December 2012 09:55, John Stultz john.stultz@linaro.org wrote:
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
That might be enough, i suppose.
Are you saying that cpufreq-interactive-gov would not be needed in this case? Thus excluding the case when someone wants the interactive governor, but without the rest of the android code. (I thought it was one of the reasons to have a separate cpufreq-interactive-gov topic vs more frequent updates to the existing android topic)
However, if you're maintaining your own tree anyway, why not have Andrey pull your tree in addition to the current linaro-android-3.x-*rebase branch?
Since they are both contain a common subset, the merge will likely be quite easy.
Not quite right. At least the android topic is the rebase, so these topics are quite different from git's perspective. I've tried merging Viresh's topic into llct containing the Anton's version of the android topic. There were 2 conflicting files. One file was 3 commits ahead of the llct, and it would be much more easier to cherry pick those commits into llct than trying to associate the combined diff with the 3 commits. As for the 2nd file, it was just one additional commit in the Viresh's branch, but it wasn't the topmost commit in that branch for some reason. That is such merge needs some manual work, and I don't feel comfortable doing such merges w/o good knowledge of android or the governor at least. Also there may be conflict resolutions or fixes done when creating or updating the android topic, and they can be omitted by occasion when merging cpufreq-interactive-gov-master into llct.
The things would be pretty trivial, if cpufreq-interactive-gov-master were based on the android topic. But cpufreq-interactive-gov-master is intended to be used without the android topic as well, right? This means outside the linux-linaro kernel trees btw.
That way Andrey's tree will have a better chance of having the latest changes.
Does that seem ok?
That was the initial idea, but there were concerns from Tixy and Andrey on that. @Andrey: Do you want to comment again?
imho the conflicts when merging cpufreq-interactive-gov-master into llct require interactive governor tests in the CI loop. Especially if we want cpufreq-interactive-gov-master to be updated frequently.
How difficult would it be to maintain a special version of the cpufreq-interactive-gov topic for llct: cpufreq-interactive-gov-master rebased onto the most recent android topic? E.g. cpufreq-interactive-gov-linux-linaro?
Thanks, Andrey
On 5 December 2012 17:09, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Are you saying that cpufreq-interactive-gov would not be needed in this case? Thus excluding the case when someone wants the interactive governor, but without the rest of the android code. (I thought it was one of the reasons to have a separate cpufreq-interactive-gov topic vs more frequent updates to the existing android topic)
We wanted it for ubuntu and Android. And when we use linux-linaro release, we have android code built into the kernel. So, we don't really need these patches for something else, Unless somebody is using an older version of linux-linaro release, and in that case he must update his stuff manually.
-- viresh
On 5 December 2012 09:55, John Stultz john.stultz@linaro.org wrote:
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
Hi John,
There are few updates of interactive governor available in AOSP 3.4 branch. Can you please include them?
On 12/19/2012 06:05 PM, Viresh Kumar wrote:
On 5 December 2012 09:55, John Stultz john.stultz@linaro.org wrote:
So while I can try to update the linaro-android tree more frequently, maintaining that tree is more of a background task. So when my other commitments consume my attention, sometimes that update frequency is slower. Also, given we're already 3 releases beyond the AOSP tree, keeping the two branches in perfect sync is unlikely to happen (due to the higher chance of collisions). So if folks notice there is some critical functionality that is updated in the AOSP tree, when they let me know, I can be sure to merge it in (like was done with this case - albeit slower then I'd like).
Hi John,
There are few updates of interactive governor available in AOSP 3.4 branch. Can you please include them?
Sure thing, just merged them in and pushed them out. Let me know if you notice anything missing.
thanks! -john
-
Amit Kucheria -
Andrey Konovalov -
Anton Vorontsov -
John Stultz -
Jon Medhurst (Tixy) -
Viresh Kumar