[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120605220059.GV2388@linux.vnet.ibm.com>
Date: Tue, 5 Jun 2012 15:00:59 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
"Luck, Tony" <tony.luck@...el.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Ingo Molnar <mingo@...e.hu>, H Peter Anvin <hpa@...or.com>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
"Mallick, Asit K" <asit.k.mallick@...el.com>,
Arjan Dan De Ven <arjan@...ux.intel.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, linux-pm <linux-pm@...r.kernel.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Re: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi
On Tue, Jun 05, 2012 at 11:37:21PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-06-05 at 14:29 -0700, Paul E. McKenney wrote:
> > OK, I'll bite... Why not just use CPU hotplug to expel the timers?
>
> Currently? Can you say: 'kstopmachine'?
So if CPU hotplug (or whatever you want to call it) stops using
kstopmachine, you are OK with it?
> But its also a question of interface and naming. Do you want to have to
> iterate all cpus in your isolated set, do you want to bring them down
> far enough to physically unplug. Ideally no to both.
For many use cases, it is indeed not necessary to get to a point where
the CPUs could be physically removed from the system. But CPU-failure
use cases would need the CPU to be fully deactivated. And many of the
hardware guys tell me that the CPU-failure case will be getting more
common, though I sure hope that they are wrong.
> If you don't bring them down far enough to unplug, should you still be
> calling it hotplug?
I am not too worried about what it is called. Though "banish to monastery"
would probably be going too far in the other direction.
> Ideally I think there'd be a file in your cpuset which if opened and
> written to will flush all pending bits (timers, workqueues, the lot) and
> return when this is done (and maybe provide O_ASYNC writes to not wait
> for completion).
The mobile guys probably are not too worried about bulk operations yet
because they don't have that many CPUs, but it might be useful elsewhere.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists