From: "Gregory Haskins" <ghaskins@novell.com>
To: "Paul Jackson" <pj@sgi.com>
Cc: <a.p.zijlstra@chello.nl>, <mingo@elte.hu>, <arjan@infradead.org>,
<tglx@linutronix.de>, <dhaval@linux.vnet.ibm.com>,
<vatsa@linux.vnet.ibm.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/2] reworking load_balance_monitor
Date: Thu, 14 Feb 2008 12:16:21 -0700 [thread overview]
Message-ID: <47B44D35.BA47.005A.0@novell.com> (raw)
In-Reply-To: <20080214121544.941d91f1.pj@sgi.com>
>>> On Thu, Feb 14, 2008 at 1:15 PM, in message
<20080214121544.941d91f1.pj@sgi.com>, Paul Jackson <pj@sgi.com> wrote:
> Peter wrote of:
>> the lack of rd->load_balance.
>
> Could you explain to me a bit what that means?
>
> Does this mean that the existing code would, by default (default being
> a single sched domain, covering the entire system's CPUs) load balance
> across the entire system, but with your rework, not so load balance
> there? That seems unlikely.
>
> In any event, from my rather cpuset-centric perspective, there are only
> two common cases to consider.
>
> 1. In the default case, build_sched_domains() gets called once,
> at init, with a cpu_map of all non-isolated CPUs, and we should
> forever after load balance across all those non-isolated CPUs.
>
> 2. In some carefully managed systems using the per-cpuset
> 'sched_load_balance' flags, we tear down that first default
> sched domain, by calling detach_destroy_domains() on it, and we
> then setup some number of sched_domains (typically in the range
> of two to ten, though I suppose we should design to scale to
> hundreds of sched domains, on systems with thousands of CPUs)
> by additional calls to build_sched_domains(), such that their
> CPUs don't overlap (pairwise disjoint) and such that the union
> of all their CPUs may, or may not, include all non-isolated CPUs
> (some CPUs might be left 'out in the cold', intentionally, as
> essentially additional isolated CPUs.) We would then expect load
> balancing within each of these pair-wise disjoint sched domains,
> but not between one of them and another.
Hi Paul,
I think it will still work as you describe. We create a new root-domain object for each pair-wise disjoint sched-domain. In your case (1) above, we would only have one instance of a root-domain which contains (of course) a single instance of the rd->load_balance object. This would, in fact operate like the global variable that Peter is suggesting it replace (IIUC). However, for case (2), we would instantiate a root-domain object per pairwise-disjoint sched-domain, and therefore each one would have its own instance of rd->load_balance.
HTH
-Greg
next prev parent reply other threads:[~2008-02-14 19:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 15:57 [RFC][PATCH 0/2] reworking load_balance_monitor Peter Zijlstra
2008-02-14 15:57 ` [RFC][PATCH 1/2] sched: fair-group: rework load_balance_monitor Peter Zijlstra
2008-02-14 15:57 ` [RFC][PATCH 2/2] sched: fair-group: per root-domain load balancing Peter Zijlstra
2008-02-15 16:46 ` Gregory Haskins
2008-02-15 19:46 ` Peter Zijlstra
2008-02-19 12:42 ` Gregory Haskins
2008-02-14 16:09 ` [RFC][PATCH 0/2] reworking load_balance_monitor Gregory Haskins
2008-02-14 18:15 ` Paul Jackson
2008-02-14 19:16 ` Gregory Haskins [this message]
2008-02-18 8:24 ` Dhaval Giani
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=47B44D35.BA47.005A.0@novell.com \
--to=ghaskins@novell.com \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=tglx@linutronix.de \
--cc=vatsa@linux.vnet.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 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.