From: Ken Chen <kenchen@google.com>
To: Vladimir Davydov <VDavydov@parallels.com>
Cc: "a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"mingo@elte.hu" <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Subject: [PATCH] sched: fixed erroneous all_pinned logic.
Date: Fri, 8 Apr 2011 11:25:28 -0700 [thread overview]
Message-ID: <BANLkTinWBdURcb2+P5YC99audiVohX4DQA@mail.gmail.com> (raw)
In-Reply-To: <870910A1-62AF-412F-A989-1FA57B715E35@parallels.com>
On Fri, Apr 8, 2011 at 3:57 AM, Vladimir Davydov wrote:
>
> As far as I understand, this patch sets the all_pinned flag if
> and only if we fail to move any tasks during the load balance.
> However, the migration can fail because e.g. all tasks are
> cache hot on their cpus (can_migrate_task() returns 0 in this
> case), and in this case we shouldn't treat all tasks as cpu
> bound, should we?
all_pinned logic is not restricted for tasks that have hard CPU affinity.
In balance_tasks(), e.g. if all tasks have high weight, it would also trip
all_pinned to 1. See ( p->se.load.weight >> 1) > rem_load_move). I don't
see much difference whether a task has high weight, or is cache hot, or
has hard cpu affinity.
The effect of classifying cache_hot as pinned task or not is difficult to
measure, I think. Because that state is more temporal compare to the
other two conditions.
I don't have enough data to indicate which way is better though.
- Ken
next prev parent reply other threads:[~2011-04-08 18:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 0:24 Ken Chen
2011-04-08 10:57 ` Vladimir Davydov
2011-04-08 11:49 ` Peter Zijlstra
2011-04-08 19:20 ` Ken Chen
2011-04-09 11:14 ` Peter Zijlstra
2011-04-11 10:46 ` [tip:sched/urgent] sched: Fix " tip-bot for Ken Chen
2011-04-08 18:25 ` Ken Chen [this message]
2011-04-08 11:39 ` Subject: [PATCH] sched: fixed " Peter Zijlstra
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=BANLkTinWBdURcb2+P5YC99audiVohX4DQA@mail.gmail.com \
--to=kenchen@google.com \
--cc=VDavydov@parallels.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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®