public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Andrew Morton <akpm@osdl.org>,
	kernel@kolivas.org, npiggin@suse.de, mingo@elte.hu,
	rostedt@goodmis.org, linux-kernel@vger.kernel.org,
	torvalds@osdl.org
Subject: Re: [rfc][patch] sched: remove smpnice
Date: Tue, 14 Feb 2006 23:07:45 -0800	[thread overview]
Message-ID: <20060214230745.A1677@unix-os.sc.intel.com> (raw)
In-Reply-To: <43F25C60.4080603@bigpond.net.au>; from pwil3058@bigpond.net.au on Wed, Feb 15, 2006 at 09:40:32AM +1100

On Wed, Feb 15, 2006 at 09:40:32AM +1100, Peter Williams wrote:
> Siddha, Suresh B wrote:
> > On a 4P(8-way with HT), if you run a -20 task(a simple infinite loop)
> > it hops from one processor to another processor... you can observe it
> > using top.
> 
> How do you get top to display which CPU tasks are running on?

In the interactive mode, you can select the "last used cpu" field to display.
or you can use /proc/pid/stat

> > 
> > find_busiest_group() thinks there is an imbalance and ultimately the
> > idle cpu kicks active load balance on busy cpu, resulting in the hopping.
> 
> I'm still having trouble getting my head around this.  A task shouldn't 
> be moved unless there's at least one other task on its current CPU, it 

Because of the highest priority task, weighted load of that cpu
will be > SCHED_LOAD_SCALE. Because of this, an idle cpu in 
find_busiest_group() thinks that there is an imbalance.. This is due to
the code near the comment "however we may be able to increase 
total CPU power used by ...". That piece of code assumes that a unit load
is represented by SCHED_LOAD_SCALE (which is no longer true with smpnice)
and finally results in "pwr_move > pwr_now".. This will make the idle cpu
try to pull that process from busiest cpu and the process will ultimately move
with the help of active load balance...

> > I agree with you.. But lets take a DP system with HT, now if there are
> > only two low priority tasks running, ideally we should be running them
> > on two different packages. With this patch, we may end up running on the
> > same logical processor.. leave alone running on the same package..
> > As these are low priority tasks, it might be ok.. But...
> 
> Yes, this is an issue but it's not restricted to HT systems (except for 

Agreed.

> the same package part).  The latest patch that I've posted addresses 
> (part of) this problem by replacing SCHED_LOAD_SCALE with the average 
> load per runnable task in the code at the end of find_busiest_group() 
> which handles the case where imbalance is small.  This should enable 
> load balancing to occur even if all runnable tasks are low priority.

Yes. We need to fix the code I mentioned above too.... And please make sure
it doesn't break HT optimizations as this piece of code is mainly used
for implementing HT optimizations..

thanks,
suresh

  parent reply	other threads:[~2006-02-15  7:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-07 14:28 [rfc][patch] sched: remove smpnice Nick Piggin
2006-02-07 14:57 ` Con Kolivas
2006-02-07 15:05   ` Nick Piggin
2006-02-07 22:15   ` Andrew Morton
2006-02-07 23:11     ` Con Kolivas
2006-02-07 23:36       ` Andrew Morton
2006-02-08  3:28         ` Nick Piggin
2006-02-08 14:56         ` Ingo Molnar
2006-02-10  7:01         ` Siddha, Suresh B
2006-02-10  7:17           ` Andrew Morton
2006-02-10  7:23             ` Con Kolivas
2006-02-10  9:06             ` Ingo Molnar
2006-02-11  1:27             ` Peter Williams
2006-02-11  2:00               ` Andrew Morton
2006-02-12  1:13                 ` Peter Williams
2006-02-12 23:10                   ` Peter Williams
2006-02-13  1:06                     ` Peter Williams
2006-02-14  0:37                       ` Peter Williams
2006-02-14  8:53                         ` Siddha, Suresh B
2006-02-11  3:36               ` Peter Williams
2006-02-11  4:04               ` Peter Williams
2006-02-14  9:07               ` Siddha, Suresh B
2006-02-14 22:40                 ` Peter Williams
2006-02-14 23:44                   ` Paul Jackson
2006-02-15  0:09                     ` Peter Williams
2006-02-15  1:00                       ` Paul Jackson
2006-02-15  7:07                   ` Siddha, Suresh B [this message]
2006-02-15 22:36                     ` Peter Williams
2006-02-15 23:29                       ` Peter Williams
2006-02-13 14:12           ` Con Kolivas
2006-02-07 23:20     ` Peter Williams
2006-02-07 23:29       ` Con Kolivas
2006-02-07 23:36       ` Martin Bligh

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=20060214230745.A1677@unix-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=pwil3058@bigpond.net.au \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@osdl.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