Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1499805
| From | Dietmar Eggemann <dietmar.eggemann@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 5/7 v4] sched: propagate asynchrous detach |
| Date | 2016-10-12 18:30 +0200 |
| Message-ID | <sruzL-6Ti-5@gated-at.bofh.it> (permalink) |
| References | <slDcJ-3Ml-7@gated-at.bofh.it> <slDcK-3Ml-23@gated-at.bofh.it> <srtkm-688-7@gated-at.bofh.it> <srtX3-6nc-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 12/10/16 16:45, Vincent Guittot wrote: > On 12 October 2016 at 17:03, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: >> On 26/09/16 13:19, Vincent Guittot wrote: [...] >>> @@ -6607,6 +6609,10 @@ static void update_blocked_averages(int cpu) >>> >>> if (update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq, true)) >>> update_tg_load_avg(cfs_rq, 0); >>> + >>> + /* Propagate pending load changes to the parent */ >>> + if (cfs_rq->tg->se[cpu]) >>> + update_load_avg(cfs_rq->tg->se[cpu], 0); >> >> In my test (1 task (run/period: 8ms/16ms) in tg_root->tg_x->tg_y->*tg_z* >> and oscillating between cpu1 and cpu2) the cfs_rq related signals are >> nicely going down to 0 after the task has left the cpu but it doesn't >> seem to be the case for the corresponding se (cfs_rq->tg->se[cpu])? > > strange because such use case is part of the functional tests that I > run and it was working fine according to last test that I did > >> >> It should actually work correctly because of the >> update_tg_cfs_util/load() calls in update_load_avg(cfs_rq->tg->se[cpu], >> 0)->propagate_entity_load_avg() > > Furthermore, the update of the parent cfs_rq tg_x->cfs_rq[cpu] uses > the delta between previous and new value for the child tg_y->se[cpu]. > So it means that if tg_x->cfs_rq[cpu]->avg.load_avg goes down to 0, > tg_y->se[cpu]->avg.load_avg has at least changed and most probably > goes down to 0 too Makes sense. > > Can't it be a misplaced trace point ? Yes, you're right, it was a missing tracepoint. I only had se and cfs_rq pelt tracepoints in __update_load_avg() and attach/detach_entity_load_avg(). I've added them as well to propagate_entity_load_avg() after the update_tg_cfs_load() call and now it makes sense. Thanks! [...]
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 5/7 v4] sched: propagate asynchrous detach Vincent Guittot <vincent.guittot@linaro.org> - 2016-09-26 14:30 +0200
Re: [PATCH 5/7 v4] sched: propagate asynchrous detach Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-10-12 17:10 +0200
Re: [PATCH 5/7 v4] sched: propagate asynchrous detach Vincent Guittot <vincent.guittot@linaro.org> - 2016-10-12 17:50 +0200
Re: [PATCH 5/7 v4] sched: propagate asynchrous detach Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-10-12 18:30 +0200
csiph-web