On Wed, Oct 19, 2016 at 04:33:03PM +0100, Dietmar Eggemann wrote: > On 19/10/16 12:25, Vincent Guittot wrote: > > On 19 October 2016 at 11:46, Dietmar Eggemann <dietmar.eggem...@arm.com> > > wrote: > >> On 18/10/16 12:56, Vincent Guittot wrote: > >>> Le Tuesday 18 Oct 2016 à 12:34:12 (+0200), Peter Zijlstra a écrit : > >>>> On Tue, Oct 18, 2016 at 11:45:48AM +0200, Vincent Guittot wrote: > >>>>> On 18 October 2016 at 11:07, Peter Zijlstra <pet...@infradead.org> > >>>>> wrote: > > [...] > > >> But this test only makes sure that we don't see any ghost contribution > >> (from non-existing cpus) any more. > >> > >> We should study the tg->se[i]->avg.load_avg for the hierarchy of tg's > >> (with the highest tg having a task enqueued) a little bit more, with and > >> without your v5 'sched: reflect sched_entity move into task_group's load'. > > > > Can you elaborate ? > > I try :-) > > I thought I will see some different behaviour because of the fact that > the tg se's are initialized differently [1024 versus 0].
This is the exact thing I was also worried about and that's the reason I tried to fix this in a different way. However I didn't find any behaviour difference once any task attached to child cfs_rq which is the point we really care about. I found this bug while making patch at https://lkml.org/lkml/2016/10/18/841 which will fail with wrong task_group load_avg. I tested Vincent's patch and above together, confirmed it's still good. Though I know Ingo already sent out pull request. Anyway. Tested-by: Joonwoo Park <joonw...@codeaurora.org> Thanks, Joonwoo > > But I can't spot any difference. The test case is running a sysbench > thread affine to cpu1 in tg_root/tg_1/tg_11/tg_111 on tip/sched/core on > an ARM64 Juno (6 logical cpus). > The moment the sysbench task is put into tg_111 > tg_111->se[1]->avg.load_avg gets updated to 0 any way because of the > huge time difference between creating this tg and attaching a task to > it. So the tg->se[2]->avg.load_avg signals for tg_111, tg_11 and tg_1 > look exactly the same w/o and w/ your patch. > > But your patch helps in this (very synthetic) test case as well. W/o > your patch I see remaining tg->load_avg for tg_1 and tg_11 after the > test case has finished because the tg's were exclusively used on cpu1. > > # cat /proc/sched_debug > > cfs_rq[1]:/tg_1 > .tg_load_avg_contrib : 0 > .tg_load_avg : 5120 (5 (unused cpus) * 1024 * 1) > cfs_rq[1]:/tg_1/tg_11/tg_111 > .tg_load_avg_contrib : 0 > .tg_load_avg : 0 > cfs_rq[1]:/tg_1/tg_11 > .tg_load_avg_contrib : 0 > .tg_load_avg : 5120 > > With your patch applied all the .tg_load_avg are 0.