Hello everybody,
There have been few discussion on how big LITTLE MP tree should be managed as it is getting PULL requests from a wide range of patches working towards making our system more power efficient.
The following scheme is finalized and is detailed here:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
Purpose of this tree is to keep all ongoing efforts, which affect power management on big LITTLE systems, together at a single place. All of these must be targeted to get included in Mainline by their original authors.
There are two categories of branches/patches that are kept here. One that are guaranteed to work on current big LITTLE system (Tested on ARM Vexpress TC2) and others which are experimental. Branches can be moved from experimental to master, once we are convinced they don't break any existing stuff in master branch.
So, following is the category of Merge branches we have:
big-LITTLE-MP-master-v*: Guaranteed to work on current big LITTLE system, ARM Vexpress TC2. This will be pulled in linux-linaro-tracking git tree. big-LITTLE-MP-experimental-v*: Experimental topic branches
For now I have created to merge branches: - big-LITTLE-MP-master-v12: git merge arm-multi_pmu_v2 hw-bkp-v7.1-debug-v1 per-task-load-average-v3-merged task-placement-v2 task-migration-sysfs-tuning misc-patches config-fragments - big-LITTLE-MP-exp-v12: git merge intel-powerclamp-driver-v1 per-entity-load-tracking-with-core-sched-v1 sched-pack-small-tasks-v1 sched-timer-wq-migration-v2-resend
- power-aware-scheduling-v1: This is another branch which is present in this tree, which can be used. It was rebased on tip/master and hence isn't merged.
PULL request to Andrey would be sent only for the Master branch. I would be releasing Experimental branch too every time with Master branch though.
Please share your comments?
-- viresh
On Wed, Nov 14, 2012 at 06:33:29AM +0000, Viresh Kumar wrote:
Hello everybody,
Hi Viresh,
There have been few discussion on how big LITTLE MP tree should be managed as it is getting PULL requests from a wide range of patches working towards making our system more power efficient.
The following scheme is finalized and is detailed here:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
Purpose of this tree is to keep all ongoing efforts, which affect power management on big LITTLE systems, together at a single place. All of these must be targeted to get included in Mainline by their original authors.
There are two categories of branches/patches that are kept here. One that are guaranteed to work on current big LITTLE system (Tested on ARM Vexpress TC2)
How is that guarantee created? Do you have a set of tests that you are going to run before declaring it working? Interested to have a bit more detail here.
and others which are experimental. Branches can be moved from experimental to master, once we are convinced they don't break any existing stuff in master branch.
So, following is the category of Merge branches we have:
big-LITTLE-MP-master-v*: Guaranteed to work on current big LITTLE system, ARM Vexpress TC2. This will be pulled in linux-linaro-tracking git tree. big-LITTLE-MP-experimental-v*: Experimental topic branches
For now I have created to merge branches:
- big-LITTLE-MP-master-v12: git merge arm-multi_pmu_v2 hw-bkp-v7.1-debug-v1 per-task-load-average-v3-merged task-placement-v2
task-migration-sysfs-tuning misc-patches config-fragments
- big-LITTLE-MP-exp-v12: git merge intel-powerclamp-driver-v1 per-entity-load-tracking-with-core-sched-v1 sched-pack-small-tasks-v1 sched-timer-wq-migration-v2-resend
Not exactly clear what is the transition process from experimental to master.
And another question: is there going to be an implicit order in pulling patches in your master branch? (i.e. you pull first the old patches that are known to work because they were previously in -master- before pulling patches from -experimental- ? )
Regards, Liviu
- power-aware-scheduling-v1: This is another branch which is present
in this tree, which can be used. It was rebased on tip/master and hence isn't merged.
PULL request to Andrey would be sent only for the Master branch. I would be releasing Experimental branch too every time with Master branch though.
Please share your comments?
-- viresh
On 14 November 2012 15:23, Liviu Dudau Liviu.Dudau@arm.com wrote:
On Wed, Nov 14, 2012 at 06:33:29AM +0000, Viresh Kumar wrote: Hi Viresh,
Hi Liviu,
There are two categories of branches/patches that are kept here. One that are guaranteed to work on current big LITTLE system (Tested on ARM Vexpress TC2)
How is that guarantee created? Do you have a set of tests that you are going to run before declaring it working? Interested to have a bit more detail here.
It was a Weakly ordered statement :)
Actually, the most important patchset present in this tree for now is "task placement" from Morten. Which enabled big LITTLE behavior. We can add any patch to master which doesn't break this branch.
Earlier i got Vincent's and Preeti's patches, which broke this and so we have to come with this solution.
Yes, i do test these branches with MP Demo i created some time back. Also, we are planning to do some sysbench/cyclic tests on both merge branches.
For now I have created to merge branches:
- big-LITTLE-MP-master-v12: git merge arm-multi_pmu_v2 hw-bkp-v7.1-debug-v1 per-task-load-average-v3-merged task-placement-v2
task-migration-sysfs-tuning misc-patches config-fragments
- big-LITTLE-MP-exp-v12: git merge intel-powerclamp-driver-v1 per-entity-load-tracking-with-core-sched-v1 sched-pack-small-tasks-v1 sched-timer-wq-migration-v2-resend
Not exactly clear what is the transition process from experimental to master.
Whatever doesn't break HMP patches can go into master directly. The purpose here is, that partners should be able to test HMP stuff on their boards with Linaro kernel.
And another question: is there going to be an implicit order in pulling patches in your master branch? (i.e. you pull first the old patches that are known to work because they were previously in -master- before pulling patches from -experimental- ? )
Not sure if i got your question well. Whatever lands into master has very less chance to get out to exp. I normally create an octopus merge in my merge branches, so there is no specific order i follow during these merges.
Sorry if i haven't answered it well :(
-- viresh
On Wed, Nov 14, 2012 at 10:06:49AM +0000, Viresh Kumar wrote:
On 14 November 2012 15:23, Liviu Dudau Liviu.Dudau@arm.com wrote:
On Wed, Nov 14, 2012 at 06:33:29AM +0000, Viresh Kumar wrote: Hi Viresh,
Hi Liviu,
There are two categories of branches/patches that are kept here. One that are guaranteed to work on current big LITTLE system (Tested on ARM Vexpress TC2)
How is that guarantee created? Do you have a set of tests that you are going to run before declaring it working? Interested to have a bit more detail here.
It was a Weakly ordered statement :)
Actually, the most important patchset present in this tree for now is "task placement" from Morten. Which enabled big LITTLE behavior. We can add any patch to master which doesn't break this branch.
Earlier i got Vincent's and Preeti's patches, which broke this and so we have to come with this solution.
Yes, i do test these branches with MP Demo i created some time back. Also, we are planning to do some sysbench/cyclic tests on both merge branches.
Good, cheers!
For now I have created to merge branches:
- big-LITTLE-MP-master-v12: git merge arm-multi_pmu_v2 hw-bkp-v7.1-debug-v1 per-task-load-average-v3-merged task-placement-v2
task-migration-sysfs-tuning misc-patches config-fragments
- big-LITTLE-MP-exp-v12: git merge intel-powerclamp-driver-v1 per-entity-load-tracking-with-core-sched-v1 sched-pack-small-tasks-v1 sched-timer-wq-migration-v2-resend
Not exactly clear what is the transition process from experimental to master.
Whatever doesn't break HMP patches can go into master directly. The purpose here is, that partners should be able to test HMP stuff on their boards with Linaro kernel.
So the expectations is that partners (ARM included) take the patches from experimental and test them with master. Is the onus on the creator of the patch to do the testing?
And another question: is there going to be an implicit order in pulling patches in your master branch? (i.e. you pull first the old patches that are known to work because they were previously in -master- before pulling patches from -experimental- ? )
Not sure if i got your question well. Whatever lands into master has very less chance to get out to exp. I normally create an octopus merge in my merge branches, so there is no specific order i follow during these merges.
Question was: when you do the octopus merge, do you place the list of topic branches in a specific order or you randomly (or alphabetically) sort the list. Interested from a "tracking your git tree" point of view.
Regards, Liviu
Sorry if i haven't answered it well :(
-- viresh
On 14 November 2012 15:55, Liviu Dudau Liviu.Dudau@arm.com wrote:
On Wed, Nov 14, 2012 at 10:06:49AM +0000, Viresh Kumar wrote:
Whatever doesn't break HMP patches can go into master directly. The purpose here is, that partners should be able to test HMP stuff on their boards with Linaro kernel.
So the expectations is that partners (ARM included) take the patches from experimental and test them with master. Is the onus on the creator of the patch to do the testing?
Not always. Sometimes we just pick patches from Mainline, that are developed by guys not working on ARM platforms. So, either i have to test them or somebody else.
But people who are working in Linaro or ARM, they can atleast test their patches against master.
so there is no specific order i follow during these merges.
Question was: when you do the octopus merge, do you place the list of topic branches in a specific order or you randomly (or alphabetically) sort the list. Interested from a "tracking your git tree" point of view.
Ahh.. Above reply from me is for this question only. :) I don't follow any particular order unless there is some dependency between branches.
-- viresh
-
Liviu Dudau -
Viresh Kumar