All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Gautham R Shenoy <ego@in.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
Date: Tue, 20 Apr 2010 06:45:45 +1000	[thread overview]
Message-ID: <715.1271709945@neuling.org> (raw)
In-Reply-To: <1271688543.1488.253.camel@laptop>

In message <1271688543.1488.253.camel@laptop> you wrote:
> On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote:
> > > Are there any numbers available on how much they gain? It might be worth
> > > to stick in real numbers instead of this alleged 15%.
> > 
> > I get some gain numbers but obviously the workloads makes a huge
> > difference.  From a scheduler perspective, I assume an
> > average/representative gain is best rather than an optimistic or
> > pessimistic one?
> 
> Yeah, average would be best.

Ok.

> > We'll have different gains for SMT2 and SMT4, so we could change the
> > gain dynamically based on which SMT mode we are in.  Does that seem like
> > something we should add as an arch hook?  
> 
> That's the sort of thing you can use arch_scale_smt_power() for. But be
> weary to not fall into the same trap I did with x86, where I confused
> actual gain with capacity (When idle the actual gain is 0, but the
> capacity is not).

Oops, yes of course :-)

<from before>
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..

Let me know if/when you come up this solution or if I can help.  

Mikey

WARNING: multiple messages have this Message-ID (diff)
From: Michael Neuling <mikey@neuling.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Gautham R Shenoy <ego@in.ibm.com>
Subject: Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
Date: Tue, 20 Apr 2010 06:45:45 +1000	[thread overview]
Message-ID: <715.1271709945@neuling.org> (raw)
In-Reply-To: <1271688543.1488.253.camel@laptop>

In message <1271688543.1488.253.camel@laptop> you wrote:
> On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote:
> > > Are there any numbers available on how much they gain? It might be worth
> > > to stick in real numbers instead of this alleged 15%.
> > 
> > I get some gain numbers but obviously the workloads makes a huge
> > difference.  From a scheduler perspective, I assume an
> > average/representative gain is best rather than an optimistic or
> > pessimistic one?
> 
> Yeah, average would be best.

Ok.

> > We'll have different gains for SMT2 and SMT4, so we could change the
> > gain dynamically based on which SMT mode we are in.  Does that seem like
> > something we should add as an arch hook?  
> 
> That's the sort of thing you can use arch_scale_smt_power() for. But be
> weary to not fall into the same trap I did with x86, where I confused
> actual gain with capacity (When idle the actual gain is 0, but the
> capacity is not).

Oops, yes of course :-)

<from before>
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..

Let me know if/when you come up this solution or if I can help.  

Mikey

  reply	other threads:[~2010-04-19 20:45 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-09  6:21 [PATCH 0/5] sched: asymmetrical packing for POWER7 SMT4 Michael Neuling
2010-04-09  6:21 ` Michael Neuling
2010-04-09  6:21 ` [PATCH 1/5] sched: fix capacity calculations for SMT4 Michael Neuling
2010-04-09  6:21   ` Michael Neuling
2010-04-13 12:29   ` Peter Zijlstra
2010-04-13 12:29     ` Peter Zijlstra
2010-04-14  4:28     ` Michael Neuling
2010-04-14  4:28       ` Michael Neuling
2010-04-16 13:58       ` Peter Zijlstra
2010-04-16 13:58         ` Peter Zijlstra
2010-04-18 21:34         ` Michael Neuling
2010-04-18 21:34           ` Michael Neuling
2010-04-19 14:49           ` Peter Zijlstra
2010-04-19 14:49             ` Peter Zijlstra
2010-04-19 20:45             ` Michael Neuling [this message]
2010-04-19 20:45               ` Michael Neuling
2010-04-29  6:55         ` Michael Neuling
2010-04-29  6:55           ` Michael Neuling
2010-05-31  8:33         ` Peter Zijlstra
2010-05-31  8:33           ` Peter Zijlstra
2010-06-01 22:52           ` Vaidyanathan Srinivasan
2010-06-01 22:52             ` Vaidyanathan Srinivasan
2010-06-03  8:56             ` Peter Zijlstra
2010-06-03  8:56               ` Peter Zijlstra
2010-06-07 15:06           ` Srivatsa Vaddagiri
2010-06-07 15:06             ` Srivatsa Vaddagiri
2010-04-09  6:21 ` [PATCH 3/5] powerpc: enabled asymmetric SMT scheduling on POWER7 Michael Neuling
2010-04-09  6:21   ` Michael Neuling
2010-04-09  6:48   ` Michael Neuling
2010-04-09  6:48     ` Michael Neuling
2010-04-09  6:21 ` [PATCH 4/5] sched: Mark the balance type for use in need_active_balance() Michael Neuling
2010-04-09  6:21   ` Michael Neuling
2010-04-13 12:29   ` Peter Zijlstra
2010-04-13 12:29     ` Peter Zijlstra
2010-04-15  4:15     ` Michael Neuling
2010-04-15  4:15       ` Michael Neuling
2010-04-09  6:21 ` [PATCH 2/5] sched: add asymmetric packing option for sibling domain Michael Neuling
2010-04-09  6:21   ` Michael Neuling
2010-04-13 12:29   ` Peter Zijlstra
2010-04-13 12:29     ` Peter Zijlstra
2010-04-14  6:09     ` Michael Neuling
2010-04-14  6:09       ` Michael Neuling
2010-04-09  6:21 ` [PATCH 5/5] sched: make fix_small_imbalance work with asymmetric packing Michael Neuling
2010-04-09  6:21   ` Michael Neuling
2010-04-13 12:29   ` Peter Zijlstra
2010-04-13 12:29     ` Peter Zijlstra
2010-04-14  1:31     ` Suresh Siddha
2010-04-14  1:31       ` Suresh Siddha
2010-04-15  5:06       ` Michael Neuling
2010-04-15  5:06         ` Michael Neuling

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=715.1271709945@neuling.org \
    --to=mikey@neuling.org \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --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.