On 08/05/2020 19:02, Tao Zhou wrote:
> On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
>> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
>>>
>>> Hi Phil,
>>>
>>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
>>>> sched/fair: Fix enqueue_task_fair warning some more
[...]
>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>>> index 02f323b85b6d..c6d57c334d51 100644
>>>> --- a/kernel/sched/fair.c
>>>> +++ b/kernel/sched/fair.c
>>>> @@ -5479,6 +5479,13 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>>>> /* end evaluation on encountering a throttled cfs_rq */
>>>> if (cfs_rq_throttled(cfs_rq))
>>>> goto enqueue_throttle;
>>>> +
>>>> + /*
>>>> + * One parent has been throttled and cfs_rq removed from the
>>>> + * list. Add it back to not break the leaf list.
>>>> + */
>>>> + if (throttled_hierarchy(cfs_rq))
>>>> + list_add_leaf_cfs_rq(cfs_rq);
>>>> }
>>>
>>> I was confused by why the throttled cfs rq can be on list.
>>> It is possible when enqueue a task and thanks to the 'threads'.
>>> But I think the above comment does not truely put the right
>>> intention, right ?
>>> If throttled parent is onlist, the child cfs_rq is ignored
>>> to be added to the leaf cfs_rq list me think.
>>>
>>> unthrottle_cfs_rq() follows the same logic if i am not wrong.
>>> Is it necessary to add the above to it ?
>>
>> When a cfs_rq is throttled, its sched group is dequeued and all child
>> cfs_rq are removed from leaf_cfs_rq list. But the sched group of the
>> child cfs_rq stay enqueued in the throttled cfs_rq so child sched
>> group->on_rq might be still set.
>
> If there is a throttle of throttle, and unthrottle the child throttled
> cfs_rq(ugly):
> ...
> |
> cfs_rq throttled (parent A)
> |
> |
> cfs_rq in hierarchy (B)
> |
> |
> cfs_rq throttled (C)
> |
> ...
>
> Then unthrottle the child throttled cfs_rq C, now the A is on the
> leaf_cfs_rq list. sched_group entity of C is enqueued to B, and
> sched_group entity of B is on_rq and is ignored by enqueue but in
> the throttled hierarchy and not add to leaf_cfs_rq list.
> The above may be absolutely wrong that I miss something.
>
> Another thing :
> In enqueue_task_fair():
>
> for_each_sched_entity(se) {
> cfs_rq = cfs_rq_of(se);
>
> if (list_add_leaf_cfs_rq(cfs_rq))
> break;
> }
>
> In unthrottle_cfs_rq():
>
> for_each_sched_entity(se) {
> cfs_rq = cfs_rq_of(se);
>
> list_add_leaf_cfs_rq(cfs_rq);
> }
>
> The difference between them is that if condition, add if
> condition to unthrottle_cfs_rq() may be an optimization and
> keep the same.
>
I'm not 100% sure if this is exactly what Tao pointed out here but I
also had difficulties understanding understanding how this patch works:
p.se
|
__________________|
|
V
cfs_c -> tg_c -> se_c (se->on_rq = 1)
|
__________________|
|
v
cfs_b -> tg_b -> se_b
|
__________________|
|
V
cfs_a -> tg_a -> se_a
|
__________________|
|
V
cfs_r -> tg_r
|
V
rq
(1) The incomplete update happens with cfs_c at the end of
enqueue_entity() in the first loop because of 'if ( .... ||
cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
(2) se_c breaks out of the first loop (se_c->on_rq = 1)
(3) With the patch cfs_b is added back to the list.
But only because cfs_a->on_list=1.
But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
throttle_cfs_rq()->walk_tg_tree_from(..., tg_throttle_down, ...) should
include cfs_a when calling list_del_leaf_cfs_rq().
IMHO, throttle_cfs_rq() calls tg_throttle_down() for the throttled
cfs_rq too.
Another thing: Why don't we use throttled_hierarchy(cfs_rq) instead of
cfs_bandwidth_used() in enqueue_entity() as well?
On Mon, 11 May 2020 at 10:40, Dietmar Eggemann <[email protected]> wrote:
>
> On 08/05/2020 19:02, Tao Zhou wrote:
> > On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
> >> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
> >>>
> >>> Hi Phil,
> >>>
> >>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
> >>>> sched/fair: Fix enqueue_task_fair warning some more
>
> [...]
>
> >>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >>>> index 02f323b85b6d..c6d57c334d51 100644
> >>>> --- a/kernel/sched/fair.c
> >>>> +++ b/kernel/sched/fair.c
> >>>> @@ -5479,6 +5479,13 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> >>>> /* end evaluation on encountering a throttled cfs_rq */
> >>>> if (cfs_rq_throttled(cfs_rq))
> >>>> goto enqueue_throttle;
> >>>> +
> >>>> + /*
> >>>> + * One parent has been throttled and cfs_rq removed from the
> >>>> + * list. Add it back to not break the leaf list.
> >>>> + */
> >>>> + if (throttled_hierarchy(cfs_rq))
> >>>> + list_add_leaf_cfs_rq(cfs_rq);
> >>>> }
> >>>
> >>> I was confused by why the throttled cfs rq can be on list.
> >>> It is possible when enqueue a task and thanks to the 'threads'.
> >>> But I think the above comment does not truely put the right
> >>> intention, right ?
> >>> If throttled parent is onlist, the child cfs_rq is ignored
> >>> to be added to the leaf cfs_rq list me think.
> >>>
> >>> unthrottle_cfs_rq() follows the same logic if i am not wrong.
> >>> Is it necessary to add the above to it ?
> >>
> >> When a cfs_rq is throttled, its sched group is dequeued and all child
> >> cfs_rq are removed from leaf_cfs_rq list. But the sched group of the
> >> child cfs_rq stay enqueued in the throttled cfs_rq so child sched
> >> group->on_rq might be still set.
> >
> > If there is a throttle of throttle, and unthrottle the child throttled
> > cfs_rq(ugly):
> > ...
> > |
> > cfs_rq throttled (parent A)
> > |
> > |
> > cfs_rq in hierarchy (B)
> > |
> > |
> > cfs_rq throttled (C)
> > |
> > ...
> >
> > Then unthrottle the child throttled cfs_rq C, now the A is on the
> > leaf_cfs_rq list. sched_group entity of C is enqueued to B, and
> > sched_group entity of B is on_rq and is ignored by enqueue but in
> > the throttled hierarchy and not add to leaf_cfs_rq list.
> > The above may be absolutely wrong that I miss something.
> >
> > Another thing :
> > In enqueue_task_fair():
> >
> > for_each_sched_entity(se) {
> > cfs_rq = cfs_rq_of(se);
> >
> > if (list_add_leaf_cfs_rq(cfs_rq))
> > break;
> > }
> >
> > In unthrottle_cfs_rq():
> >
> > for_each_sched_entity(se) {
> > cfs_rq = cfs_rq_of(se);
> >
> > list_add_leaf_cfs_rq(cfs_rq);
> > }
> >
> > The difference between them is that if condition, add if
> > condition to unthrottle_cfs_rq() may be an optimization and
> > keep the same.
> >
>
> I'm not 100% sure if this is exactly what Tao pointed out here but I
> also had difficulties understanding understanding how this patch works:
>
> p.se
> |
> __________________|
> |
> V
> cfs_c -> tg_c -> se_c (se->on_rq = 1)
> |
> __________________|
> |
> v
> cfs_b -> tg_b -> se_b
> |
> __________________|
> |
> V
> cfs_a -> tg_a -> se_a
> |
> __________________|
> |
> V
> cfs_r -> tg_r
> |
> V
> rq
>
In your example, which cfs_ rq has been throttled ? cfs_a ?
> (1) The incomplete update happens with cfs_c at the end of
> enqueue_entity() in the first loop because of 'if ( .... ||
> cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
so cfs_c is added with the 1st loop
>
> (2) se_c breaks out of the first loop (se_c->on_rq = 1)
>
> (3) With the patch cfs_b is added back to the list.
> But only because cfs_a->on_list=1.
hmm I don't understand the link between cfs_b been added and cfs_a->on_list=1
cfs_b is added with 2nd loop because its throttle_count > 0 due to
cfs_a been throttled (purpose of this patch)
>
> But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
So 2nd loop breaks because cfs_a is throttled
The 3rd loop will add cfs_a
> throttle_cfs_rq()->walk_tg_tree_from(..., tg_throttle_down, ...) should
> include cfs_a when calling list_del_leaf_cfs_rq().
>
> IMHO, throttle_cfs_rq() calls tg_throttle_down() for the throttled
> cfs_rq too.
>
>
> Another thing: Why don't we use throttled_hierarchy(cfs_rq) instead of
> cfs_bandwidth_used() in enqueue_entity() as well?
Mainly to be conservative because as this patch demonstrates, there
are a lot of possible use cases and combinations and I can't ensure
that it is always safe to use the throttled_hierarchy.
On 11/05/2020 11:36, Vincent Guittot wrote:
> On Mon, 11 May 2020 at 10:40, Dietmar Eggemann <[email protected]> wrote:
>>
>> On 08/05/2020 19:02, Tao Zhou wrote:
>>> On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
>>>> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
>>>>>
>>>>> Hi Phil,
>>>>>
>>>>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
>>>>>> sched/fair: Fix enqueue_task_fair warning some more
[...]
>> I'm not 100% sure if this is exactly what Tao pointed out here but I
>> also had difficulties understanding understanding how this patch works:
>>
>> p.se
>> |
>> __________________|
>> |
>> V
>> cfs_c -> tg_c -> se_c (se->on_rq = 1)
>> |
>> __________________|
>> |
>> v
>> cfs_b -> tg_b -> se_b
>> |
>> __________________|
>> |
>> V
>> cfs_a -> tg_a -> se_a
>> |
>> __________________|
>> |
>> V
>> cfs_r -> tg_r
>> |
>> V
>> rq
>>
>
> In your example, which cfs_ rq has been throttled ? cfs_a ?
Yes, cfs_a. 0xffffa085e48ce000 in Phil's trace.
>
>> (1) The incomplete update happens with cfs_c at the end of
>> enqueue_entity() in the first loop because of 'if ( .... ||
>> cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
>
> so cfs_c is added with the 1st loop
Yes.
>> (2) se_c breaks out of the first loop (se_c->on_rq = 1)
>>
>> (3) With the patch cfs_b is added back to the list.
>> But only because cfs_a->on_list=1.
>
> hmm I don't understand the link between cfs_b been added and cfs_a->on_list=1
cfs_b, 0xffffa085e48ce000 is the one which is now added in the 2. loop.
Isn't the link between cfs_b and cfs_a the first if condition in
list_add_leaf_cfs_rq():
if (cfs_rq->tg->parent &&
cfs_rq->tg->parent->cfs_rq[cpu]->on_list)
to 'connect the branch' or not (default, returning false case)?
> cfs_b is added with 2nd loop because its throttle_count > 0 due to
> cfs_a been throttled (purpose of this patch)
>
>>
>> But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
>
> So 2nd loop breaks because cfs_a is throttled
Yes.
> The 3rd loop will add cfs_a
Yes, but in the example, cfs_a->on_list=1, so we bail out of
list_add_leaf_cfs_rq() early.
I don't grasp how can cfs_a->on_list=1, when cfs_a is throttled and
cfs_b, cfs_c are in a throttled hierarchy?
>> throttle_cfs_rq()->walk_tg_tree_from(..., tg_throttle_down, ...) should
>> include cfs_a when calling list_del_leaf_cfs_rq().
>>
>> IMHO, throttle_cfs_rq() calls tg_throttle_down() for the throttled
>> cfs_rq too.
>>
>>
>> Another thing: Why don't we use throttled_hierarchy(cfs_rq) instead of
>> cfs_bandwidth_used() in enqueue_entity() as well?
>
> Mainly to be conservative because as this patch demonstrates, there
> are a lot of possible use cases and combinations and I can't ensure
> that it is always safe to use the throttled_hierarchy.
Maybe this deserves a comment then.
On Mon, 11 May 2020 at 12:39, Dietmar Eggemann <[email protected]> wrote:
>
> On 11/05/2020 11:36, Vincent Guittot wrote:
> > On Mon, 11 May 2020 at 10:40, Dietmar Eggemann <[email protected]> wrote:
> >>
> >> On 08/05/2020 19:02, Tao Zhou wrote:
> >>> On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
> >>>> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
> >>>>>
> >>>>> Hi Phil,
> >>>>>
> >>>>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
> >>>>>> sched/fair: Fix enqueue_task_fair warning some more
>
> [...]
>
> >> I'm not 100% sure if this is exactly what Tao pointed out here but I
> >> also had difficulties understanding understanding how this patch works:
> >>
> >> p.se
> >> |
> >> __________________|
> >> |
> >> V
> >> cfs_c -> tg_c -> se_c (se->on_rq = 1)
> >> |
> >> __________________|
> >> |
> >> v
> >> cfs_b -> tg_b -> se_b
> >> |
> >> __________________|
> >> |
> >> V
> >> cfs_a -> tg_a -> se_a
> >> |
> >> __________________|
> >> |
> >> V
> >> cfs_r -> tg_r
> >> |
> >> V
> >> rq
> >>
> >
> > In your example, which cfs_ rq has been throttled ? cfs_a ?
>
> Yes, cfs_a. 0xffffa085e48ce000 in Phil's trace.
>
> >
> >> (1) The incomplete update happens with cfs_c at the end of
> >> enqueue_entity() in the first loop because of 'if ( .... ||
> >> cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
> >
> > so cfs_c is added with the 1st loop
>
> Yes.
>
> >> (2) se_c breaks out of the first loop (se_c->on_rq = 1)
> >>
> >> (3) With the patch cfs_b is added back to the list.
> >> But only because cfs_a->on_list=1.
> >
> > hmm I don't understand the link between cfs_b been added and cfs_a->on_list=1
>
> cfs_b, 0xffffa085e48ce000 is the one which is now added in the 2. loop.
>
> Isn't the link between cfs_b and cfs_a the first if condition in
on_list is only there to say if the cfs_rq is already in the list but
there is not dependency with the child
> list_add_leaf_cfs_rq():
>
> if (cfs_rq->tg->parent &&
> cfs_rq->tg->parent->cfs_rq[cpu]->on_list)
>
> to 'connect the branch' or not (default, returning false case)?
>
In your example above if the parent is already on the list then we
know where to insert the child.
> > cfs_b is added with 2nd loop because its throttle_count > 0 due to
> > cfs_a been throttled (purpose of this patch)
> >
> >>
> >> But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
> >
> > So 2nd loop breaks because cfs_a is throttled
>
> Yes.
>
> > The 3rd loop will add cfs_a
>
> Yes, but in the example, cfs_a->on_list=1, so we bail out of
> list_add_leaf_cfs_rq() early.
Because the cfs_rq is on the list already so we don't have to add it
>
> I don't grasp how can cfs_a->on_list=1, when cfs_a is throttled and
> cfs_b, cfs_c are in a throttled hierarchy?
>
> >> throttle_cfs_rq()->walk_tg_tree_from(..., tg_throttle_down, ...) should
> >> include cfs_a when calling list_del_leaf_cfs_rq().
> >>
> >> IMHO, throttle_cfs_rq() calls tg_throttle_down() for the throttled
> >> cfs_rq too.
> >>
> >>
> >> Another thing: Why don't we use throttled_hierarchy(cfs_rq) instead of
> >> cfs_bandwidth_used() in enqueue_entity() as well?
> >
> > Mainly to be conservative because as this patch demonstrates, there
> > are a lot of possible use cases and combinations and I can't ensure
> > that it is always safe to use the throttled_hierarchy.
>
> Maybe this deserves a comment then.
On 11/05/2020 14:12, Vincent Guittot wrote:
> On Mon, 11 May 2020 at 12:39, Dietmar Eggemann <[email protected]> wrote:
>>
>> On 11/05/2020 11:36, Vincent Guittot wrote:
>>> On Mon, 11 May 2020 at 10:40, Dietmar Eggemann <[email protected]> wrote:
>>>>
>>>> On 08/05/2020 19:02, Tao Zhou wrote:
>>>>> On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
>>>>>> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
>>>>>>>
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
>>>>>>>> sched/fair: Fix enqueue_task_fair warning some more
>>
>> [...]
>>
>>>> I'm not 100% sure if this is exactly what Tao pointed out here but I
>>>> also had difficulties understanding understanding how this patch works:
>>>>
>>>> p.se
>>>> |
>>>> __________________|
>>>> |
>>>> V
>>>> cfs_c -> tg_c -> se_c (se->on_rq = 1)
>>>> |
>>>> __________________|
>>>> |
>>>> v
>>>> cfs_b -> tg_b -> se_b
>>>> |
>>>> __________________|
>>>> |
>>>> V
>>>> cfs_a -> tg_a -> se_a
>>>> |
>>>> __________________|
>>>> |
>>>> V
>>>> cfs_r -> tg_r
>>>> |
>>>> V
>>>> rq
>>>>
>>>
>>> In your example, which cfs_ rq has been throttled ? cfs_a ?
>>
>> Yes, cfs_a. 0xffffa085e48ce000 in Phil's trace.
>>
>>>
>>>> (1) The incomplete update happens with cfs_c at the end of
>>>> enqueue_entity() in the first loop because of 'if ( .... ||
>>>> cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
>>>
>>> so cfs_c is added with the 1st loop
>>
>> Yes.
>>
>>>> (2) se_c breaks out of the first loop (se_c->on_rq = 1)
>>>>
>>>> (3) With the patch cfs_b is added back to the list.
>>>> But only because cfs_a->on_list=1.
>>>
>>> hmm I don't understand the link between cfs_b been added and cfs_a->on_list=1
>>
>> cfs_b, 0xffffa085e48ce000 is the one which is now added in the 2. loop.
>>
>> Isn't the link between cfs_b and cfs_a the first if condition in
>
> on_list is only there to say if the cfs_rq is already in the list but
> there is not dependency with the child
Yes, I agree. But coming back to what the patch does in the example:
W/ the patch, list_add_leaf_cfs_rq() is now called for cfs_b and since
cfs_b->tg->parent->cfs_a and cfs_a->on_list=1 the 'branch is now
connected' which means 'rq->tmp_alone_branch = &rq->leaf_cfs_rq_list'.
I.e. assert_list_leaf_cfs_rq() at the end of enqueue_task_fair() is not
barfing anymore.
W/o the patch, list_add_leaf_cfs_rq() called w/ cfs_c left the 'branch
open', it's not called on cfs_b and since cfs_a->on_list=1, the 3rd
for_each_sched_entity() in enqueue_task_fair() doesn't 'connect the
branch' so the assert fires.
What I don't immediately see is how can cfs_a be throttled (which causes
cfs_b -> cfs_c being a throttled hierarchy) and be on the list
(cfs_a->on_list=1) at the same time.
So the only thing how this could happen is when there was a task enqueue
in a parallel cfs_b' (another child of cfs_a) sub hierarchy just before
the example.
>> list_add_leaf_cfs_rq():
>>
>> if (cfs_rq->tg->parent &&
>> cfs_rq->tg->parent->cfs_rq[cpu]->on_list)
>>
>> to 'connect the branch' or not (default, returning false case)?
>>
>
> In your example above if the parent is already on the list then we
> know where to insert the child.
True, we go the 2nd if() condition in list_add_leaf_cfs_rq().
>>> cfs_b is added with 2nd loop because its throttle_count > 0 due to
>>> cfs_a been throttled (purpose of this patch)
>>>
>>>>
>>>> But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
>>>
>>> So 2nd loop breaks because cfs_a is throttled
>>
>> Yes.
>>
>>> The 3rd loop will add cfs_a
>>
>> Yes, but in the example, cfs_a->on_list=1, so we bail out of
>> list_add_leaf_cfs_rq() early.
>
> Because the cfs_rq is on the list already so we don't have to add it
Yes.
[...]
On Mon, 11 May 2020 at 19:02, Dietmar Eggemann <[email protected]> wrote:
>
> On 11/05/2020 14:12, Vincent Guittot wrote:
> > On Mon, 11 May 2020 at 12:39, Dietmar Eggemann <[email protected]> wrote:
> >>
> >> On 11/05/2020 11:36, Vincent Guittot wrote:
> >>> On Mon, 11 May 2020 at 10:40, Dietmar Eggemann <[email protected]> wrote:
> >>>>
> >>>> On 08/05/2020 19:02, Tao Zhou wrote:
> >>>>> On Fri, May 08, 2020 at 05:27:44PM +0200, Vincent Guittot wrote:
> >>>>>> On Fri, 8 May 2020 at 17:12, Tao Zhou <[email protected]> wrote:
> >>>>>>>
> >>>>>>> Hi Phil,
> >>>>>>>
> >>>>>>> On Thu, May 07, 2020 at 04:36:12PM -0400, Phil Auld wrote:
> >>>>>>>> sched/fair: Fix enqueue_task_fair warning some more
> >>
> >> [...]
> >>
> >>>> I'm not 100% sure if this is exactly what Tao pointed out here but I
> >>>> also had difficulties understanding understanding how this patch works:
> >>>>
> >>>> p.se
> >>>> |
> >>>> __________________|
> >>>> |
> >>>> V
> >>>> cfs_c -> tg_c -> se_c (se->on_rq = 1)
> >>>> |
> >>>> __________________|
> >>>> |
> >>>> v
> >>>> cfs_b -> tg_b -> se_b
> >>>> |
> >>>> __________________|
> >>>> |
> >>>> V
> >>>> cfs_a -> tg_a -> se_a
> >>>> |
> >>>> __________________|
> >>>> |
> >>>> V
> >>>> cfs_r -> tg_r
> >>>> |
> >>>> V
> >>>> rq
> >>>>
> >>>
> >>> In your example, which cfs_ rq has been throttled ? cfs_a ?
> >>
> >> Yes, cfs_a. 0xffffa085e48ce000 in Phil's trace.
> >>
> >>>
> >>>> (1) The incomplete update happens with cfs_c at the end of
> >>>> enqueue_entity() in the first loop because of 'if ( .... ||
> >>>> cfs_bandwidth_used())' (cfs_b->on_list=0 since cfs_a is throttled)
> >>>
> >>> so cfs_c is added with the 1st loop
> >>
> >> Yes.
> >>
> >>>> (2) se_c breaks out of the first loop (se_c->on_rq = 1)
> >>>>
> >>>> (3) With the patch cfs_b is added back to the list.
> >>>> But only because cfs_a->on_list=1.
> >>>
> >>> hmm I don't understand the link between cfs_b been added and cfs_a->on_list=1
> >>
> >> cfs_b, 0xffffa085e48ce000 is the one which is now added in the 2. loop.
> >>
> >> Isn't the link between cfs_b and cfs_a the first if condition in
> >
> > on_list is only there to say if the cfs_rq is already in the list but
> > there is not dependency with the child
>
> Yes, I agree. But coming back to what the patch does in the example:
>
> W/ the patch, list_add_leaf_cfs_rq() is now called for cfs_b and since
> cfs_b->tg->parent->cfs_a and cfs_a->on_list=1 the 'branch is now
> connected' which means 'rq->tmp_alone_branch = &rq->leaf_cfs_rq_list'.
>
> I.e. assert_list_leaf_cfs_rq() at the end of enqueue_task_fair() is not
> barfing anymore.
>
> W/o the patch, list_add_leaf_cfs_rq() called w/ cfs_c left the 'branch
> open', it's not called on cfs_b and since cfs_a->on_list=1, the 3rd
> for_each_sched_entity() in enqueue_task_fair() doesn't 'connect the
> branch' so the assert fires.
>
> What I don't immediately see is how can cfs_a be throttled (which causes
> cfs_b -> cfs_c being a throttled hierarchy) and be on the list
> (cfs_a->on_list=1) at the same time.
>
> So the only thing how this could happen is when there was a task enqueue
> in a parallel cfs_b' (another child of cfs_a) sub hierarchy just before
> the example.
Yes. A task has been enqueued on another child (cfs_b') and cfs_a has
been be added back to ensure that cfs are correctly ordered
>
> >> list_add_leaf_cfs_rq():
> >>
> >> if (cfs_rq->tg->parent &&
> >> cfs_rq->tg->parent->cfs_rq[cpu]->on_list)
> >>
> >> to 'connect the branch' or not (default, returning false case)?
> >>
> >
> > In your example above if the parent is already on the list then we
> > know where to insert the child.
>
> True, we go the 2nd if() condition in list_add_leaf_cfs_rq().
>
> >>> cfs_b is added with 2nd loop because its throttle_count > 0 due to
> >>> cfs_a been throttled (purpose of this patch)
> >>>
> >>>>
> >>>> But since cfs_a is throttled it should be cfs_a->on_list=0 as well.
> >>>
> >>> So 2nd loop breaks because cfs_a is throttled
> >>
> >> Yes.
> >>
> >>> The 3rd loop will add cfs_a
> >>
> >> Yes, but in the example, cfs_a->on_list=1, so we bail out of
> >> list_add_leaf_cfs_rq() early.
> >
> > Because the cfs_rq is on the list already so we don't have to add it
>
> Yes.
>
> [...]