From: Peter Zijlstra <peterz@infradead.org>
To: Sonny Rao <sonnyrao@us.ibm.com>
Cc: Nishanth Aravamudan <nacc@us.ibm.com>,
miltonm@bga.com, Thomas Gleixner <tglx@linutronix.de>,
Ian Campbell <ian.campbell@citrix.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
linux-kernel@vger.kernel.org, sonnyrao@linux.vnet.ibm.com
Subject: Re: [RESEND PATCH 1/2] IRQ: use cpu_possible_mask rather than online_mask in setup_affinity
Date: Mon, 11 Oct 2010 20:48:25 +0200 [thread overview]
Message-ID: <1286822905.1998.96.camel@laptop> (raw)
In-Reply-To: <20101006210236.GQ13726@us.ibm.com>
On Wed, 2010-10-06 at 16:02 -0500, Sonny Rao wrote:
> > > With user-driven dynamic SMT,
> >
> > What's that?
>
> Well, that is basically a feature where we can use CPU hotplug to
> force a particular mode on an SMT (hardware multithreaded) processor
>
> The point here was really that on such multi-threaded processors -- which are
> becoming more common -- cpu hotplug can potentially be used fairly
> often.
I guess you're talking about the trainwreck called power7? Where you
want to force the thing into SMT1/2 mode instead of letting it degrade
into SMT4 mode?
Why would you want to change that often? Do realize that cpu-hotplug is
a very heavy, very expensive operation, doing it more than a few times
an hour counts as excessive in my book.
For RT I've been thinking of extending cpusets with a feature that
allows you to disable things like SMT and MC on a set, ensuring you get
no pipeline/cache interference.
But this is something you setup once and then run your workload, its not
something you'll change often (in fact, hotplugging cpus will utterly
wreck your RT workload).
Also, I don't see why you would want to have interrupts with affinity to
offline cpus only, that sounds plain wrong, an offline'd cpu is not able
to deal with interrupts.
I wish people would stop abusing hotplug as:
- resource management
- power management
- other crazy ass things
Its not suitable for those..
next prev parent reply other threads:[~2010-10-11 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 21:26 [RESEND PATCH 0/2] Fix IRQ round-robing w/o irqbalance on pseries Nishanth Aravamudan
2010-10-01 21:26 ` [RESEND PATCH 1/2] IRQ: use cpu_possible_mask rather than online_mask in setup_affinity Nishanth Aravamudan
2010-10-02 10:57 ` Thomas Gleixner
2010-10-06 20:55 ` Sonny Rao
2010-10-02 11:01 ` Peter Zijlstra
2010-10-06 21:02 ` Sonny Rao
2010-10-11 18:48 ` Peter Zijlstra [this message]
2010-10-11 19:52 ` Sonny Rao
2010-10-01 21:26 ` [RESEND PATCH 2/2] pseries/xics: use cpu_possible_mask rather than cpu_all_mask Nishanth Aravamudan
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=1286822905.1998.96.camel@laptop \
--to=peterz@infradead.org \
--cc=ian.campbell@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=nacc@us.ibm.com \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=sonnyrao@linux.vnet.ibm.com \
--cc=sonnyrao@us.ibm.com \
--cc=tglx@linutronix.de \
/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