public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rick Lindsley <ricklind@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH 12/13] schedstats additions for sched-balance-fork
Date: Fri, 25 Feb 2005 22:21:54 +1100	[thread overview]
Message-ID: <421F0A52.5020209@yahoo.com.au> (raw)
In-Reply-To: <200502251107.j1PB7Ptk008435@owlet.beaverton.ibm.com>

Rick Lindsley wrote:
>     There is little help we get from userspace, and i'm not sure we want to
>     add scheduler overhead for this single benchmark - when something like a
>     _tiny_ bit of NUMAlib use within the OpenMP library would probably solve
>     things equally well!
> 
> There's has been a general problem with sched domains and it trying to
> meet two goals: "1) spread things around evenly within a domain and
> balance across domains infrequently", and "2) load up cores before
> loading up siblings, even at the expense of violating 1)".
> 

Yes, you hit the nail on the head. Well, the other (potentially
more problematic) part of the equation is "3) keep me close to
my parent and siblings, because we'll be likely to share memory
and/or communicate".

However: I'm hoping that on unloaded or lightly loaded NUMA
systems, it is usually the right choice to spread tasks across
nodes. Especially on the newer breed of low remote latency, high
bandwidth systems like Opterons and POWER5s.

When load ramps up a bit and we start saturating CPUs, the amount
of balance-on-forking should slow down, so we start to fulfil
requirement 3 for workloads that perhaps resemble more general
purpose server stuff.

That's the plan anyway. We'll see...


  reply	other threads:[~2005-02-25 11:22 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 [this message]
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
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=421F0A52.5020209@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=ricklind@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox