All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	steiner@sgi.com, dvhltc@us.ibm.com, mbligh@mbligh.org
Subject: Re: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)
Date: Fri, 12 Aug 2005 09:49:36 +1000	[thread overview]
Message-ID: <42FBE410.9070809@yahoo.com.au> (raw)
In-Reply-To: <20050811111411.A581@unix-os.sc.intel.com>

Siddha, Suresh B wrote:
> On Thu, Aug 11, 2005 at 01:09:10PM +1000, Nick Piggin wrote:
> 
>>I have a variation on the 2nd part of your patch which I think
>>I would prefer. IMO it kind of generalises the current imbalance
>>calculation to handle this case rather than introducing a new
>>special case.
> 
> 
> There is a difference between our changes. 
> 
> When the system is lightly loaded, my patch minimizes the number of 
> groups picking up that load. This will help in power savings for 
> example in the context of CMP. There are more changes required
> (user or kernel) for complete power savings, but this is a direction 
> towards that.
> 
> How about this patch?

Well, it is a departure from our current idea of balancing.
I would prefer to use my patch initially to fix the _bug_
you found, then we can think about changing policy for
power savings.

Main things I'm worried about:

Idle time regressions that pop up any time we put
restrictions on balancing.

This can tend to unbalance memory controllers (eg. on POWER5,
CMP Opteron) which can be a performance problem on those
systems.

Lastly, complexity in the calculation.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2005-08-11 23:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-02  0:42 [Patch] don't kick ALB in the presence of pinned task Siddha, Suresh B
2005-08-02  6:09 ` Nick Piggin
2005-08-02  9:43   ` Ingo Molnar
2005-08-02 10:06     ` Nick Piggin
2005-08-02 21:12   ` Siddha, Suresh B
2005-08-02  9:27 ` Ingo Molnar
2005-08-09 23:08   ` allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task) Siddha, Suresh B
2005-08-10  0:27     ` Nick Piggin
2005-08-10  2:03       ` Siddha, Suresh B
2005-08-11  3:09         ` Nick Piggin
2005-08-11 18:14           ` Siddha, Suresh B
2005-08-11 23:49             ` Nick Piggin [this message]
2005-08-12  0:39               ` Siddha, Suresh B
2005-08-12  1:24                 ` Nick Piggin
2005-08-12  1:44                   ` Siddha, Suresh B
2005-08-10  7:16     ` Ingo Molnar

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=42FBE410.9070809@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=suresh.b.siddha@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.