From: Peter Zijlstra <peterz@infradead.org>
To: byungchul.park@lge.com
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: sync with the prev cfs when changing cgroup within a cpu
Date: Mon, 10 Aug 2015 13:47:06 +0200 [thread overview]
Message-ID: <20150810114706.GA16853@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1439186939-27992-1-git-send-email-byungchul.park@lge.com>
On Mon, Aug 10, 2015 at 03:08:59PM +0900, byungchul.park@lge.com wrote:
> From: Byungchul Park <byungchul.park@lge.com>
>
> current code seems to be wrong with cfs_rq->blocked_load_avg when changing
> a task's cgroup(=cfs_rq) to another. i tested with "echo pid > cgroup" and
> found that cfs_rq->blocked_load_avg became larger and larger whenever i
> changed a cgroup to another again and again.
>
> it is possible to move between groups within a cpu, and each cfs_rq is
> tracking its own blocked load. so we have to sync se's average load with
> both *prev* cfs_rq and next cfs_rq when changing its group.
>
> in addition, "#ifdef CONFIG_SMP" is removed becasuse we need to sync a
> se's load with its cfs_rq even in the case of !SMP. remember it is possible
> to move between groups in *a* cpu.
>
> i also removed some comments mentioning migration_task_rq_fair().
> migration_task_rq_fair() can be called in three cases. and in each case,
> both decay counter and blocked load are already considered. so we
> don't need to consider these in task_move_group_fair() at all.
>
> 1. the wake-up migration case
> enqueue_entity_load_avg() makes se->avg.decay_count zero after applying it.
> and it will be woken up soon so we don't need to add its load to
> cfs_rq->blocked_load_avg.
>
> 2. the fork balancing case
> se->avg.decay_count is initialized in __sched_fork() to zero. and
> wake_up_new_task() calls activate_task() with flag = 0 so that
> enqueue_entity_load_avg() can omit adding its load to
> cfs_rq->blocked_load_avg, and it will be woken up soon.
>
> 3. the rq migration case (not wake up case)
> the target task is already on rq, so we don't need to consider both its
> decay counter and blocked load in this case.
>
> Signed-off-by: Byungchul Park <byungchul.park@lge.com>
What code is this against? Please look at current code and try again.
next prev parent reply other threads:[~2015-08-10 11:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-10 6:08 byungchul.park
2015-08-10 11:47 ` Peter Zijlstra [this message]
2015-08-10 23:47 ` Byungchul Park
2015-08-11 7:59 ` Peter Zijlstra
2015-08-11 0:01 ` Byungchul Park
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=20150810114706.GA16853@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=byungchul.park@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
/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
all inboxes | Powered by JetHome®