From: Yuyang Du <yuyang.du@intel.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Rabin Vincent <rabin.vincent@axis.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paul Turner <pjt@google.com>, Ben Segall <bsegall@google.com>
Subject: Re: [PATCH?] Livelock in pick_next_task_fair() / idle_balance()
Date: Fri, 3 Jul 2015 03:37:02 +0800 [thread overview]
Message-ID: <20150702193702.GD5197@intel.com> (raw)
In-Reply-To: <20150702114032.GA7598@e105550-lin.cambridge.arm.com>
Hi Morten,
On Thu, Jul 02, 2015 at 12:40:32PM +0100, Morten Rasmussen wrote:
> detach_tasks() will attempts to pull 62 based on tasks task_h_load() but
> the task_h_load() sum is only 5 + 10 + 0 and hence detach_tasks() will
> empty the src_rq.
>
> IOW, since task groups include blocked load in the load_avg_contrib (see
> __update_group_entity_contrib() and __update_cfs_rq_tg_load_contrib()) the
> imbalance includes blocked load and hence env->imbalance >=
> sum(task_h_load(p)) for all tasks p on the rq. Which leads to
> detach_tasks() emptying the rq completely in the reported scenario where
> blocked load > runnable load.
Whenever I want to know the load avg concerning task group, I need to
walk through the complete codes again, I prefer not to do it this time.
But it should not be that simply to say "the 118 comes from the blocked load".
Anyway, with blocked load, yes, we definitely can't move (or even find) some
ammount of the imbalance if we only look at the tasks on the queue. But this
may or may not be a problem.
Firstly, the question comes to whether we want blocked load anywhere.
This is just about a "now vs. average" question.
Secondly, if we stick to average, we just need to treat the blocked load
consistently, not that group SE has it, but task SE does not, or somewhere
has it, others not.
Thanks,
Yuyang
> Whether emptying the src_rq is the right thing to do depends on on your
> point of view. Does balanced load (runnable+blocked) take priority over
> keeping cpus busy or not? For idle_balance() it seems intuitively
> correct to not empty the rq and hence you could consider env->imbalance
> to be too big.
>
> I think we will see more of this kind of problems if we include
> weighted_cpuload() as well. Parts of the imbalance calculation code is
> quite old and could use some attention first.
>
> A short term fix could be what Yuyang propose, stop pulling tasks when
> there is only one left in detach_tasks(). It won't affect active load
> balance where we may want to migrate the last task as it active load
> balance doesn't use detach_tasks().
>
> Morten
next prev parent reply other threads:[~2015-07-03 3:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 14:30 [PATCH?] Livelock in pick_next_task_fair() / idle_balance() Rabin Vincent
2015-07-01 5:36 ` Mike Galbraith
2015-07-01 14:55 ` Rabin Vincent
2015-07-01 15:47 ` Mike Galbraith
2015-07-01 20:44 ` Peter Zijlstra
2015-07-01 23:25 ` Yuyang Du
2015-07-02 8:05 ` Mike Galbraith
2015-07-02 1:05 ` Yuyang Du
2015-07-02 10:25 ` Mike Galbraith
2015-07-02 11:40 ` Morten Rasmussen
2015-07-02 19:37 ` Yuyang Du [this message]
2015-07-03 9:34 ` Morten Rasmussen
2015-07-03 16:38 ` Peter Zijlstra
2015-07-05 22:31 ` Yuyang Du
2015-07-09 14:32 ` Morten Rasmussen
2015-07-09 23:24 ` Yuyang Du
2015-07-05 20:12 ` Yuyang Du
2015-07-06 17:36 ` Dietmar Eggemann
2015-07-07 11:17 ` Rabin Vincent
2015-07-13 17:43 ` Dietmar Eggemann
2015-07-09 13:53 ` Morten Rasmussen
2015-07-09 22:34 ` Yuyang Du
2015-07-02 10:53 ` Peter Zijlstra
2015-07-02 11:44 ` Morten Rasmussen
2015-07-02 18:42 ` Yuyang Du
2015-07-03 4:42 ` Mike Galbraith
2015-07-03 16:39 ` Peter Zijlstra
2015-07-05 22:11 ` Yuyang Du
2015-07-09 6:15 ` Stefan Ekenberg
2015-07-26 18:57 ` Yuyang Du
2015-08-03 17:05 ` [tip:sched/core] sched/fair: Avoid pulling all tasks in idle balancing tip-bot for 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=20150702193702.GD5197@intel.com \
--to=yuyang.du@intel.com \
--cc=bsegall@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rabin.vincent@axis.com \
--cc=umgwanakikbuti@gmail.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