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>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/13] remove aggressive idle balancing
Date: Mon, 07 Mar 2005 16:34:18 +1100	[thread overview]
Message-ID: <422BE7DA.5040304@yahoo.com.au> (raw)
In-Reply-To: <20050305214336.A9085@unix-os.sc.intel.com>

Siddha, Suresh B wrote:

> 
> By code inspection, I see an issue with this patch
> 	[PATCH 10/13] remove aggressive idle balancing
> 
> Why are we removing cpu_and_siblings_are_idle check from active_load_balance?
> In case of SMT, we  want to give prioritization to an idle package while
> doing active_load_balance(infact, active_load_balance will be kicked
> mainly because there is an idle package) 
> 
> Just the re-addition of cpu_and_siblings_are_idle check to 
> active_load_balance might not be enough. We somehow need to communicate 
> this to move_tasks, otherwise can_migrate_task will fail and we will 
> never be able to do active_load_balance.
> 

Active balancing should only kick in after the prescribed number
of rebalancing failures - can_migrate_task will see this, and
will allow the balancing to take place.

That said, we currently aren't doing _really_ well for SMT on
some workloads, however with this patch we are heading in the
right direction I think.

I have been mainly looking at tuning CMP Opterons recently (they
are closer to a "traditional" SMP+NUMA than SMT, when it comes
to the scheduler's point of view). However, in earlier revisions
of the patch I had been looking at SMT performance and was able
to get it much closer to perfect:

I was working on a 4 socket x440 with HT. The problem area is
usually when the load is lower than the number of logical CPUs.
So on tbench, we do say 450MB/s with 4 or more threads without
HT, and 550MB/s with 8 or more threads with HT, however we only
do 300MB/s with 4 threads.

Those aren't the exact numbers, but that's basically what they
look like. Now I was able to bring the 4 thread + HT case much
closer to the 4 thread - HT numbers, but with earlier patchsets.
When I get a chance I will do more tests on the HT system, but
the x440 is infuriating for fine tuning performance, because it
is a NUMA system, but it doesn't tell the kernel about it, so
it will randomly schedule things on "far away" CPUs, and results
vary.

PS. Another thing I would like to see tested is a 3 level domain
setup (SMT + SMP + NUMA). I don't have access to one though.


  reply	other threads:[~2005-03-07  5:34 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-24  7:14 [PATCH 0/13] Multiprocessor CPU scheduler patches Nick Piggin
2005-02-24  7:16 ` [PATCH 1/13] timestamp fixes Nick Piggin
2005-02-24  7:16   ` [PATCH 2/13] improve pinned task handling Nick Piggin
2005-02-24  7:18     ` [PATCH 3/13] rework schedstats Nick Piggin
2005-02-24  7:19       ` [PATCH 4/13] find_busiest_group fixlets Nick Piggin
2005-02-24  7:20         ` [PATCH 5/13] find_busiest_group cleanup Nick Piggin
2005-02-24  7:21           ` [PATCH 6/13] no aggressive idle balancing Nick Piggin
2005-02-24  7:22             ` [PATCH 7/13] better active balancing heuristic Nick Piggin
2005-02-24  7:24               ` [PATCH 8/13] generalised CPU load averaging Nick Piggin
2005-02-24  7:25                 ` [PATCH 9/13] less affine wakups Nick Piggin
2005-02-24  7:27                   ` [PATCH 10/13] remove aggressive idle balancing Nick Piggin
2005-02-24  7:28                     ` [PATCH 11/13] sched-domains aware balance-on-fork Nick Piggin
2005-02-24  7:28                       ` [PATCH 12/13] schedstats additions for sched-balance-fork Nick Piggin
2005-02-24  7:30                         ` [PATCH 13/13] basic tuning Nick Piggin
2005-02-24  8:46                         ` [PATCH 12/13] schedstats additions for sched-balance-fork Ingo Molnar
2005-02-24 22:13                           ` Nick Piggin
2005-02-25 11:07                           ` Rick Lindsley
2005-02-25 11:21                             ` Nick Piggin
2005-02-24  8:41                     ` [PATCH 10/13] remove aggressive idle balancing Ingo Molnar
2005-02-24 12:13                       ` Nick Piggin
2005-02-24 12:16                         ` Ingo Molnar
2005-03-06  5:43                         ` Siddha, Suresh B
2005-03-07  5:34                           ` Nick Piggin [this message]
2005-03-07  8:04                             ` Siddha, Suresh B
2005-03-07  8:28                               ` Nick Piggin
2005-03-08  7:22                                 ` Siddha, Suresh B
2005-03-08  8:17                                   ` Nick Piggin
2005-03-08 19:36                                     ` Siddha, Suresh B
2005-02-24  8:39               ` [PATCH 7/13] better active balancing heuristic Ingo Molnar
2005-02-24  8:36         ` [PATCH 4/13] find_busiest_group fixlets Ingo Molnar
2005-02-24  8:07       ` [PATCH 3/13] rework schedstats Ingo Molnar
2005-02-25 10:50       ` Rick Lindsley
2005-02-25 11:10         ` Nick Piggin
2005-02-25 11:25           ` DHCP on multi homed host! Ravindra Nadgauda
2005-02-24  8:04     ` [PATCH 2/13] improve pinned task handling Ingo Molnar
2005-02-24  7:46   ` [PATCH 1/13] timestamp fixes Ingo Molnar
2005-02-24  7:56     ` Nick Piggin
2005-02-24  8:34       ` 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=422BE7DA.5040304@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.