Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1453016 > unrolled thread

Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks Wanpeng Li <kernellwp@gmail.com> - 2016-08-01 09:40 +0200
    Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-08-01 11:40 +0200
      Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks Wanpeng Li <kernellwp@gmail.com> - 2016-08-01 12:30 +0200
        Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-08-01 14:00 +0200

#1453016 — Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

2016-06-17 20:01 GMT+08:00 Peter Zijlstra <peterz@infradead.org>:
> Vincent and Yuyang found another few scenarios in which entity
> tracking goes wobbly.
>
> The scenarios are basically due to the fact that new tasks are not
> immediately attached and thereby differ from the normal situation -- a
> task is always attached to a cfs_rq load average (such that it
> includes its blocked contribution) and are explicitly
> detached/attached on migration to another cfs_rq.
>
> Scenario 1: switch to fair class
>
>   p->sched_class = fair_class;
>   if (queued)
>     enqueue_task(p);
>       ...
>         enqueue_entity()
>           enqueue_entity_load_avg()
>             migrated = !sa->last_update_time (true)
>             if (migrated)
>               attach_entity_load_avg()
>   check_class_changed()
>     switched_from() (!fair)
>     switched_to()   (fair)
>       switched_to_fair()
>         attach_entity_load_avg()
>
> If @p is a new task that hasn't been fair before, it will have
> !last_update_time and, per the above, end up in
> attach_entity_load_avg() _twice_.
>
> Scenario 2: change between cgroups
>
>   sched_move_group(p)
>     if (queued)
>       dequeue_task()
>     task_move_group_fair()
>       detach_task_cfs_rq()
>         detach_entity_load_avg()
>       set_task_rq()
>       attach_task_cfs_rq()
>         attach_entity_load_avg()
>     if (queued)
>       enqueue_task();
>         ...
>           enqueue_entity()
>             enqueue_entity_load_avg()
>               migrated = !sa->last_update_time (true)
>               if (migrated)
>                 attach_entity_load_avg()
>
> Similar as with scenario 1, if @p is a new task, it will have
> !load_update_time and we'll end up in attach_entity_load_avg()
> _twice_.
>
> Furthermore, notice how we do a detach_entity_load_avg() on something
> that wasn't attached to begin with.
>
> As stated above; the problem is that the new task isn't yet attached
> to the load tracking and thereby violates the invariant assumption.
>
> This patch remedies this by ensuring a new task is indeed properly
> attached to the load tracking on creation, through
> post_init_entity_util_avg().
>
> Of course, this isn't entirely as straight forward as one might think,
> since the task is hashed before we call wake_up_new_task() and thus

What's the meaning of "the task is hashed before we call wake_up_new_task()"?

Regards,
Wanpeng Li

[toc] | [next] | [standalone]

#1453068

On Mon, 2016-08-01 at 15:30 +0800, Wanpeng Li wrote:

> What's the meaning of "the task is hashed before we call
> wake_up_new_task()"?

See fork.c::copy_process()

        /*
         * Make it visible to the rest of the system, but dont wake it up yet.
         * Need tasklist lock for parent etc handling!
         */
        write_lock_irq(&tasklist_lock);
        ....

[toc] | [prev] | [next] | [standalone]

#1453118

2016-08-01 17:31 GMT+08:00 Mike Galbraith <umgwanakikbuti@gmail.com>:
> On Mon, 2016-08-01 at 15:30 +0800, Wanpeng Li wrote:
>
>> What's the meaning of "the task is hashed before we call
>> wake_up_new_task()"?
>
> See fork.c::copy_process()
>
>         /*
>          * Make it visible to the rest of the system, but dont wake it up yet.
>          * Need tasklist lock for parent etc handling!
>          */
>         write_lock_irq(&tasklist_lock);
>         ....

Thanks Mike, so here "is hashed" means that add to list instead of real hashing.

Regards,
Wanpeng Li

[toc] | [prev] | [next] | [standalone]

#1453159

On Mon, 2016-08-01 at 17:56 +0800, Wanpeng Li wrote:
> 2016-08-01 17:31 GMT+08:00 Mike Galbraith <umgwanakikbuti@gmail.com>:
> > On Mon, 2016-08-01 at 15:30 +0800, Wanpeng Li wrote:
> > 
> > > What's the meaning of "the task is hashed before we call
> > > wake_up_new_task()"?
> > 
> > See fork.c::copy_process()
> > 
> >         /*
> >          * Make it visible to the rest of the system, but dont wake
> > it up yet.
> >          * Need tasklist lock for parent etc handling!
> >          */
> >         write_lock_irq(&tasklist_lock);
> >         ....
> 
> Thanks Mike, so here "is hashed" means that add to list instead of 
> real hashing.

Yeah.

	-Mike

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web