linux-kernel - Re: [patch 00/40] CPU hotplug rework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1301312233480.11905@ionos>
Date:	Thu, 31 Jan 2013 22:48:41 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Arjan van de Veen <arjan@...radead.org>,
	Paul Turner <pjt@...gle.com>,
	Richard Weinberger <rw@...utronix.de>,
	Magnus Damm <magnus.damm@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 00/40] CPU hotplug rework - episode I

On Thu, 31 Jan 2013, Andrew Morton wrote:

> On Thu, 31 Jan 2013 15:44:10 -0000
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > At the end hotplug should run through an array of callbacks on both
> > sides with explicit core synchronization points. The ordering should
> > look like this:
> > 
> > CPUHP_OFFLINE                   // Start state.
> > CPUHP_PREP_<hardware>           // Kick CPU into life / let it die
> > CPUHP_PREP_<datastructures>     // Get datastructures set up / freed.
> > CPUHP_PREP_<threads>            // Create threads for cpu
> > CPUHP_SYNC			// Synchronization point
> > CPUHP_INIT_<hardware>		// Startup/teardown on the CPU (interrupts, timers ...)
> > CPUHP_SCHED_<stuff on CPU>      // Unpark/park per cpu local threads on the CPU.
> > CPUHP_ENABLE_<stuff_on_CPU>	// Enable/disable facilities 
> > CPUHP_SYNC			// Synchronization point
> > CPUHP_SCHED                     // Expose/remove CPU from general scheduler.
> > CPUHP_ONLINE                    // Final state
> 
> What does CPUHP_SYNC do?

This is a future step which makes sure that the cpu which controls the
bringup and the teardown of the hotplugged cpu are synchronizing at
some point. Right now, we have this synchronization burried somewhere
in the architecture code and of course every arch does it different
versus the generic bringup/teardown mechanisms.
 
> Methinks Tejun needed a cc on this lot ;)

Not really. The workqueue hotplug scheme is today one of the sanest in
that area. Earlier versions have been a prime example of hotplug hell!

TJ has converted it via the notifier priorities to a symetric
startup/teardown scheme already. So the conversion is a no brainer and
no real change.

Sure, I should have spent the cycles to add every file owner to the cc
list, but due to brain damage caused by decoding the current hotplug
maze I skipped that painful exercise relying on you to fix it up for
me :)

Thanks,

	tglx



--
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/