mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®