Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Regards, Amit
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Yes, I will pick them in upstream branch. Juri, after upstream branch updated, would you like to refresh the sched-core branch?
Regards, Amit
Hi Alex, Amit,
On 29/04/15 04:20, Alex Shi wrote:
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Yes, I will pick them in upstream branch. Juri, after upstream branch updated, would you like to refresh the sched-core branch?
I think it would be better if we leave it as is for now and we refresh the thing after EASv4 is out, moving that branch from v3 to v4.
Thanks,
- Juri
Regards, Amit
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Thanks Alex
On 04/29/2015 06:25 PM, Juri Lelli wrote:
Hi Alex, Amit,
On 29/04/15 04:20, Alex Shi wrote:
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Yes, I will pick them in upstream branch. Juri, after upstream branch updated, would you like to refresh the sched-core branch?
I think it would be better if we leave it as is for now and we refresh the thing after EASv4 is out, moving that branch from v3 to v4.
Thanks,
- Juri
Regards, Amit
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
On 29/04/15 12:08, Alex Shi wrote:
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Our current aim is to get it out by May the 8th. But, this might still be subject to changes.
Thanks,
- Juri
Thanks Alex
On 04/29/2015 06:25 PM, Juri Lelli wrote:
Hi Alex, Amit,
On 29/04/15 04:20, Alex Shi wrote:
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Yes, I will pick them in upstream branch. Juri, after upstream branch updated, would you like to refresh the sched-core branch?
I think it would be better if we leave it as is for now and we refresh the thing after EASv4 is out, moving that branch from v3 to v4.
Thanks,
- Juri
Regards, Amit
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
On 04/29/2015 09:44 PM, Juri Lelli wrote:
On 29/04/15 12:08, Alex Shi wrote:
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Our current aim is to get it out by May the 8th. But, this might still be subject to changes.
Hi Juri,
Thanks for info! But seems it's a bit hard for me to catch the code fresh before you do. Will do it by yourself? or need I deliver it before some day?
Hi Alex,
On 30/04/15 02:57, Alex Shi wrote:
On 04/29/2015 09:44 PM, Juri Lelli wrote:
On 29/04/15 12:08, Alex Shi wrote:
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Our current aim is to get it out by May the 8th. But, this might still be subject to changes.
Hi Juri,
Thanks for info! But seems it's a bit hard for me to catch the code fresh before you do.
Do you mean update sched-upstream before I start updating sched-core? The 8th is our current estimate to get EASv4 posted to LKML, sched-core update will start after that.
Will do it by yourself? or need I deliver it before some day?
Well, I guess my work would be easier if sched-upstream is already updated when I'll have to update sched-core :).
Thanks,
- Juri
Thanks Alex
On 04/30/2015 04:28 PM, Juri Lelli wrote:
Hi Alex,
On 30/04/15 02:57, Alex Shi wrote:
On 04/29/2015 09:44 PM, Juri Lelli wrote:
On 29/04/15 12:08, Alex Shi wrote:
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Our current aim is to get it out by May the 8th. But, this might still be subject to changes.
Hi Juri,
Thanks for info! But seems it's a bit hard for me to catch the code fresh before you do.
Do you mean update sched-upstream before I start updating sched-core? The 8th is our current estimate to get EASv4 posted to LKML, sched-core update will start after that.
Well, that give me some breath. :)
Will do it by yourself? or need I deliver it before some day?
Well, I guess my work would be easier if sched-upstream is already updated when I'll have to update sched-core :).
OK. I will update them, guess start from 2 weeks later.
Thanks,
- Juri
EAS work is in my plan from this week. But I am sent to Hisilicon for emmc CQ issue. So this backport have to be delay, unless some one volunteer. Sorry for the resource issue.
Thanks Alex
On 04/30/2015 04:28 PM, Juri Lelli wrote:
Hi Alex,
On 30/04/15 02:57, Alex Shi wrote:
On 04/29/2015 09:44 PM, Juri Lelli wrote:
On 29/04/15 12:08, Alex Shi wrote:
Hi, Juri,
When your easv4 is coming up? Anyway it isn't in hurry before final 4.1 version.
Our current aim is to get it out by May the 8th. But, this might still be subject to changes.
Hi Juri,
Thanks for info! But seems it's a bit hard for me to catch the code fresh before you do.
Do you mean update sched-upstream before I start updating sched-core? The 8th is our current estimate to get EASv4 posted to LKML, sched-core update will start after that.
Will do it by yourself? or need I deliver it before some day?
Well, I guess my work would be easier if sched-upstream is already updated when I'll have to update sched-core :).
Thanks,
- Juri
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
Hi, Amit,
Is this the only serial need to pick up? or still sth I missed?
d4573c3 sched: Improve load balancing in the presence of idle CPUs dfbca41 sched: Optimize freq invariant accounting 1aaf90a sched: Move CFS tasks to CPUs with higher capacity caff37e sched: Add SD_PREFER_SIBLING for SMT level dc7ff76 sched: Remove unused struct sched_group_capacity::capacity_orig ea67821 sched: Replace capacity_factor by usage 8bb5b00 sched: Calculate CPU's usage statistic and put it into struct sg_lb_stats::group_usage ca6d75e sched: Add struct rq::cpu_capacity_orig b5b4860 sched: Make scale_rt invariant with frequency 0c1dc6b sched: Make sched entity usage tracking scale-invariant a8faa8f sched: Remove frequency scaling from cpu_capacity 21f4486 sched: Track group sched_entity usage contributions 36ee28e sched: Add sched_avg::utilization_avg_contrib
It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed.
Regards, Amit
On Thu, Jun 11, 2015 at 6:06 PM, Alex Shi alex.shi@linaro.org wrote:
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
Hi, Amit,
Is this the only serial need to pick up? or still sth I missed?
d4573c3 sched: Improve load balancing in the presence of idle CPUs dfbca41 sched: Optimize freq invariant accounting 1aaf90a sched: Move CFS tasks to CPUs with higher capacity caff37e sched: Add SD_PREFER_SIBLING for SMT level dc7ff76 sched: Remove unused struct sched_group_capacity::capacity_orig ea67821 sched: Replace capacity_factor by usage 8bb5b00 sched: Calculate CPU's usage statistic and put it into struct sg_lb_stats::group_usage ca6d75e sched: Add struct rq::cpu_capacity_orig b5b4860 sched: Make scale_rt invariant with frequency 0c1dc6b sched: Make sched entity usage tracking scale-invariant a8faa8f sched: Remove frequency scaling from cpu_capacity 21f4486 sched: Track group sched_entity usage contributions 36ee28e sched: Add sched_avg::utilization_avg_contrib
Yes, that looks correct.
Looking closely, perhaps we should also backport dfbca41f34. Juri?
On 06/12/2015 01:34 PM, Amit Kucheria wrote:
Yes, that looks correct.
Looking closely, perhaps we should also backport dfbca41f34. Juri?
hi, Amit,
After Larry quit from this project, anyone will take over this job?
Thanks!
On Fri, Jun 12, 2015 at 1:24 PM, Alex Shi alex.shi@linaro.org wrote:
On 06/12/2015 01:34 PM, Amit Kucheria wrote:
Yes, that looks correct.
Looking closely, perhaps we should also backport dfbca41f34. Juri?
hi, Amit,
After Larry quit from this project, anyone will take over this job?
We're looking into it.
Regards, Amit
On 12/06/15 06:34, Amit Kucheria wrote:
On Thu, Jun 11, 2015 at 6:06 PM, Alex Shi alex.shi@linaro.org wrote:
On 04/28/2015 06:21 PM, Amit Kucheria wrote:
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged.
Hi, Amit,
Is this the only serial need to pick up? or still sth I missed?
d4573c3 sched: Improve load balancing in the presence of idle CPUs dfbca41 sched: Optimize freq invariant accounting 1aaf90a sched: Move CFS tasks to CPUs with higher capacity caff37e sched: Add SD_PREFER_SIBLING for SMT level dc7ff76 sched: Remove unused struct sched_group_capacity::capacity_orig ea67821 sched: Replace capacity_factor by usage 8bb5b00 sched: Calculate CPU's usage statistic and put it into struct sg_lb_stats::group_usage ca6d75e sched: Add struct rq::cpu_capacity_orig b5b4860 sched: Make scale_rt invariant with frequency 0c1dc6b sched: Make sched entity usage tracking scale-invariant a8faa8f sched: Remove frequency scaling from cpu_capacity 21f4486 sched: Track group sched_entity usage contributions 36ee28e sched: Add sched_avg::utilization_avg_contrib
Yes, that looks correct.
Looking closely, perhaps we should also backport dfbca41f34. Juri?
Yes, we need that too (dfbca41f3479 "sched: Optimize freq invariant accounting"), but is it not already in Alex's list above?
I would also suggest backporting following commits, that make EAS patches apply more cleanly:
638476007d13 "sched/fair: Fix the dealing with decay_count in __synchronize_entity_decay()" cb0b9f2445cd "sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd" 6c1d9410f007 "sched: Move p->nr_cpus_allowed check to select_task_rq()"
Best,
- Juri
I would also suggest backporting following commits, that make EAS patches apply more cleanly:
Thanks for suggestion, Juri!
638476007d13 "sched/fair: Fix the dealing with decay_count in __synchronize_entity_decay()"
it is included in conflict fix.
cb0b9f2445cd "sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd"
it is removed in later conflict fix.
6c1d9410f007 "sched: Move p->nr_cpus_allowed check to select_task_rq()"
This commit depends on 4 parameters select_task_rq which introduced by sched_numa. That I really don't want to touch. :(
On 12/06/15 10:49, Alex Shi wrote:
I would also suggest backporting following commits, that make EAS patches apply more cleanly:
Thanks for suggestion, Juri!
638476007d13 "sched/fair: Fix the dealing with decay_count in __synchronize_entity_decay()"
it is included in conflict fix.
cb0b9f2445cd "sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd"
it is removed in later conflict fix.
6c1d9410f007 "sched: Move p->nr_cpus_allowed check to select_task_rq()"
This commit depends on 4 parameters select_task_rq which introduced by sched_numa. That I really don't want to touch. :(
Oh, you mean ac66f5477239 "sched/numa: Introduce migrate_swap()". No problem, not picking this should only result in a minor change required for EAS code.
Thanks,
- Juri
-
Alex Shi -
Amit Kucheria -
Juri Lelli