LKML Archive on
help / color / mirror / Atom feed
From: Suresh Siddha <>
To: Venkatesh Pallipadi <>
Cc: Peter Zijlstra <>,
	Ingo Molnar <>,
	"" <>,
	Paul Turner <>, Mike Galbraith <>,
	Nick Piggin <>
Subject: Re: [PATCH] sched: Resolve sd_idle and first_idle_cpu Catch-22 - v1
Date: Mon, 07 Feb 2011 11:53:19 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, 2011-02-07 at 10:21 -0800, Venkatesh Pallipadi wrote: 
> On Mon, Feb 7, 2011 at 5:50 AM, Peter Zijlstra <> wrote:
> > Why is SMT treaded differently from say a shared cache? In both cases we
> > want to spread the load as wide as possible to provide as much of the
> > resources to the few runnable tasks.
> >
> IIRC, the reason for the whole sd_idle part was to have less aggressive
> load balance when one SMT sibling is busy and other is idle, in order not
> to take CPU cycles away from the busy sibling.
> Suresh will know the exact reasoning behind this and which CPUs and
> which workload this helped..;a=commit;h=5969fe06

Original code came from Nick in 2005.

        [PATCH] sched: HT optimisation
        If an idle sibling of an HT queue encounters a busy sibling, then make
        higher level load balancing of the non-idle variety.
        Performance of multiprocessor HT systems with low numbers of tasks
        (generally < number of virtual CPUs) can be significantly worse than the
        exact same workloads when running in non-HT mode.  The reason is largely
        due to poor scheduling behaviour.
        This patch improves the situation, making the performance gap far less
        significant on one problematic test case (tbench).

Peter, to answer your question of why SMT is treated different to cores
sharing cache, performance improvements contributed by SMT is far less
compared to the cores and any wrong decisions in SMT load balancing
(especially in the presence of idle cores, packages) has a bigger

I think in the tbench case referred by Nick, idle HT siblings in a busy
package picked the load instead of the idle packages. And thus we
probably had to wait for active load balance to kick in to distribute
the load etc by which the damage would have been. Performance impact of
this condition wouldn't be as severe in the cores sharing last level
cache and other resources.

Also there are lot of changes in this area since 2005. So it would be
nice to revisit the tbench case and see if the logic of propagating busy
sibling status to the higher level load balances is still needed or not.

On the contrary, perhaps there might be some workloads which may benefit
in performance/latency if we completely do away with this less
aggressive SMT load balancing.

Venki, as you are looking into the fixes in this area, can you run your
workloads (aswell as tbench) and compare the logic with your fixes vs
removing this logic ?


  reply	other threads:[~2011-02-07 19:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-04 20:51 [PATCH] sched: Resolve sd_idle and first_idle_cpu Catch-22 Venkatesh Pallipadi
2011-02-04 21:25 ` [PATCH] sched: Resolve sd_idle and first_idle_cpu Catch-22 - v1 Venkatesh Pallipadi
2011-02-07 13:50   ` Peter Zijlstra
2011-02-07 18:21     ` Venkatesh Pallipadi
2011-02-07 19:53       ` Suresh Siddha [this message]
2011-02-08 17:37         ` Venkatesh Pallipadi
2011-02-08 18:13           ` Misc sd_idle related fixes Venkatesh Pallipadi
2011-02-09  9:29             ` Peter Zijlstra
2011-02-10 17:24               ` Venkatesh Pallipadi
2011-02-08 18:13           ` [PATCH 1/3] sched: Resolve sd_idle and first_idle_cpu Catch-22 Venkatesh Pallipadi
2011-02-08 18:13           ` [PATCH 2/3] sched: fix_up broken SMT load balance dilation Venkatesh Pallipadi
2011-02-08 18:13           ` [PATCH 3/3] sched: newidle balance set idle_timestamp only on successful pull Venkatesh Pallipadi
2011-02-09  3:37             ` Mike Galbraith
2011-02-09 15:55         ` [PATCH] sched: Resolve sd_idle and first_idle_cpu Catch-22 - v1 Peter Zijlstra
2011-02-12  1:20           ` Suresh Siddha
2011-02-14 22:38             ` [PATCH] sched: Wholesale removal of sd_idle logic Venkatesh Pallipadi
2011-02-15 17:01               ` Vaidyanathan Srinivasan
2011-02-15 18:26                 ` Venkatesh Pallipadi
2011-02-16  8:53                   ` Vaidyanathan Srinivasan
2011-02-16 11:43               ` Peter Zijlstra
2011-02-16 13:50               ` [tip:sched/core] " tip-bot for Venkatesh Pallipadi
2011-02-15  9:15             ` [PATCH] sched: Resolve sd_idle and first_idle_cpu Catch-22 - v1 Peter Zijlstra
2011-02-15 19:11               ` Suresh Siddha
2011-02-18  1:05             ` Alex,Shi

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).