From: Nick Piggin <nickpiggin@yahoo.com.au>
To: hawkes@SGI.com
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>,
Jack Steiner <steiner@SGI.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] load_balance: "busiest CPU" -> "busier CPUs"
Date: Wed, 15 Feb 2006 17:33:14 +1100 [thread overview]
Message-ID: <43F2CB2A.7000909@yahoo.com.au> (raw)
In-Reply-To: <20060207012729.8707.66350.sendpatchset@tomahawk.engr.sgi.com>
hawkes@SGI.com wrote:
> Second try, incorporating Suresh Siddha's suggestion to avoid adding
> a field to the runqueue struct.
>
Sorry for not getting back to you earlier.
Looks like it should work, although bviously exclusive cpusets are
still the preferred way to do exclusive partitioning. Not sure what
the others think about adding complexity and overhead for a
relatively uncommon case, I'm not a huge fan.
I have a suggestion for an improvement - cycle through all CPUs
in the busiest group before moving on to find_busiest_group again?
Do you really need the schedstat field? You'll have to bump the
schedstat version.
The idea I had when thinking about how to handle this, is to have
something like your `consider_cpus` field in the sched domain
itself (which can help you not do too much work at one time, but
will have other complexities like when to reset the mask).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-02-15 7:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-07 1:27 [PATCH] load_balance: "busiest CPU" -> "busier CPUs" hawkes
2006-02-15 6:33 ` Nick Piggin [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-04 0:38 hawkes
2006-02-04 2:36 ` Siddha, Suresh B
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=43F2CB2A.7000909@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=hawkes@SGI.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=steiner@SGI.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox