From: Peter Zijlstra <peterz@infradead.org>
To: Yuyang Du <yuyang.du@intel.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
bsegall@google.com, pjt@google.com, morten.rasmussen@arm.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com
Subject: Re: [PATCH v4 2/5] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group
Date: Mon, 6 Jun 2016 11:54:50 +0200 [thread overview]
Message-ID: <20160606095450.GA30909@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1465172441-27727-3-git-send-email-yuyang.du@intel.com>
On Mon, Jun 06, 2016 at 08:20:38AM +0800, Yuyang Du wrote:
> Vincent reported that the first task to a new task group's cfs_rq will
> be attached in attach_task_cfs_rq() and once more when it is enqueued
> (see https://lkml.org/lkml/2016/5/25/388).
>
> Actually, it is worse. The sched avgs can be sometimes attached twice
> not only when we change task groups but also when we switch to fair class,
> these two scenarios will descripbe in the following respectively.
>
> 1) Switch to fair class:
>
> The sched class change is done like this:
>
> if (queued)
> enqueue_task();
> check_class_changed()
> switched_from()
> switched_to()
>
> If the task is on_rq, it should have already been enqueued, which
> MAY have attached sched avgs to the cfs_rq, if so, we shouldn't attach
> it again in switched_to(), otherwise, we attach it twice.
>
> To address both the on_rq and !on_rq cases, as well as both the task
> was switched from fair and otherwise, the simplest solution is to reset
> the task's last_update_time to 0, when the task is switched from fair.
> Then let task enqueue do the sched avgs attachment only once.
>
> 2) Change between fair task groups:
>
> The task groups are changed like this:
>
> if (queued)
> dequeue_task()
> task_move_group()
> if (queued)
> enqueue_task()
>
> Unlike the switch to fair class case, if the task is on_rq, it will be
> enqueued after we move task groups, so the simplest solution is to reset
> the task's last_update_time when we do task_move_group(), but not to
> attach sched avgs in task_move_group(), and then let enqueue_task() do
> the sched avgs attachment.
So this patch completely removes the detach->attach aging you moved
around in the previous patch -- leading me to wonder what the purpose of
the previous patch was.
Also, this Changelog completely fails to mention this fact, nor does it
explain why this is 'right'.
> +/* Virtually synchronize task with its cfs_rq */
I don't feel this comment actually enlightens the function much.
> @@ -8372,9 +8363,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
> se->depth = se->parent ? se->parent->depth + 1 : 0;
> #endif
>
> - /* Synchronize task with its cfs_rq */
> - attach_entity_load_avg(cfs_rq, se);
> -
> if (!vruntime_normalized(p))
> se->vruntime += cfs_rq->min_vruntime;
> }
You leave attach/detach asymmetric and not a comment in sight explaining
why.
> @@ -8382,16 +8370,18 @@ static void attach_task_cfs_rq(struct task_struct *p)
> static void switched_from_fair(struct rq *rq, struct task_struct *p)
> {
> detach_task_cfs_rq(p);
> + reset_task_last_update_time(p);
> + /*
> + * If we change back to fair class, we will attach the sched
> + * avgs when we are enqueued, which will be done only once. We
> + * won't have the chance to consistently age the avgs before
> + * attaching them, so we have to continue with the last updated
> + * sched avgs when we were detached.
> + */
This comment needs improvement; it confuses.
> @@ -8444,6 +8434,11 @@ static void task_move_group_fair(struct task_struct *p)
> detach_task_cfs_rq(p);
> set_task_rq(p, task_cpu(p));
> attach_task_cfs_rq(p);
> + /*
> + * This assures we will attach the sched avgs when we are enqueued,
"ensures" ? Also, more confusion.
> + * which will be done only once.
> + */
> + reset_task_last_update_time(p);
> }
next prev parent reply other threads:[~2016-06-06 9:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 0:20 [PATCH v4 0/5] sched/fair: Fix attach and detach sched avgs for task group change or sched class change Yuyang Du
2016-06-06 0:20 ` [PATCH v4 1/5] sched/fair: Clean up attach_entity_load_avg() Yuyang Du
2016-06-06 13:30 ` Matt Fleming
2016-06-06 13:40 ` Vincent Guittot
2016-06-06 14:06 ` Matt Fleming
2016-06-06 14:27 ` Peter Zijlstra
2016-06-06 0:20 ` [PATCH v4 2/5] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group Yuyang Du
2016-06-06 9:54 ` Peter Zijlstra [this message]
2016-06-06 19:38 ` Yuyang Du
2016-06-06 12:32 ` Vincent Guittot
2016-06-06 19:05 ` Yuyang Du
2016-06-07 8:09 ` Vincent Guittot
2016-06-07 18:16 ` Yuyang Du
2016-06-06 0:20 ` [PATCH v4 3/5] sched/fair: Skip detach sched avgs for new task when changing task groups Yuyang Du
2016-06-06 9:58 ` Peter Zijlstra
2016-06-06 14:03 ` Matt Fleming
2016-06-06 19:15 ` Yuyang Du
2016-06-06 0:20 ` [PATCH v4 4/5] sched/fair: Move load and util avgs from wake_up_new_task() to sched_fork() Yuyang Du
2016-06-06 0:20 ` [PATCH v4 5/5] sched/fair: Add inline to detach_entity_load_evg() Yuyang Du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160606095450.GA30909@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=pjt@google.com \
--cc=vincent.guittot@linaro.org \
--cc=yuyang.du@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).