linux-kernel - Re: [RFD PATCH 0/4] cpu: Bulk CPU Hotplug support.

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]

Date:	Sat, 20 Jun 2009 17:35:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	svaidy@...ux.vnet.ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gautham R Shenoy <ego@...ibm.com>,
	linux-kernel@...r.kernel.org, Balbir Singh <balbir@...ibm.com>,
	Rusty Russel <rusty@...tcorp.com.au>,
	Nathan Lynch <ntl@...ox.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Shoahua Li <shaohua.li@...ux.com>
Subject: Re: [RFD PATCH 0/4] cpu: Bulk CPU Hotplug support.


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> On Wed, 2009-06-17 at 17:07 +0200, Ingo Molnar wrote:
> > * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > 
> > > On Wed, Jun 17, 2009 at 09:32:57AM +0200, Peter Zijlstra wrote:
> > > > On Tue, 2009-06-16 at 13:37 +0530, Vaidyanathan Srinivasan wrote:
> > > > > * Andrew Morton <akpm@...ux-foundation.org> [2009-06-15 23:23:18]:
> > > > > 
> > > > > > On Tue, 16 Jun 2009 11:08:39 +0530 Gautham R Shenoy <ego@...ibm.com> wrote:
> > > > > > 
> > > > > > > Currently on a ppc64 box with 16 CPUs, the time taken for
> > > > > > > a individual cpu-hotplug operation is as follows.
> > > > > > > 
> > > > > > >     # time echo 0 > /sys/devices/system/cpu/cpu2/online
> > > > > > >     real    0m0.025s
> > > > > > >     user    0m0.000s
> > > > > > >     sys     0m0.002s
> > > > > > > 
> > > > > > >     # time echo 1 > /sys/devices/system/cpu/cpu2/online
> > > > > > >     real    0m0.021s
> > > > > > >     user    0m0.000s
> > > > > > >     sys     0m0.000s
> > > > > > 
> > > > > > Surprised.  Do people really online and offline CPUs frequently enough
> > > > > > for this to be a problem?
> > > > > 
> > > > > Certainly not for hardware faults or hardware replacement, but
> > > > > cpu-hotplug interface is useful for changing system configuration to
> > > > > meet different objectives like
> > > > > 
> > > > > * Reduce system capacity to reduce average power and reduce heat
> > > > > 
> > > > > * Increasing number of cores and threads in a CPU package is leading
> > > > >   to multiple cpu offline/online operations for any perceivable effect
> > > > > 
> > > > > * Dynamically change CPU configurations in virtualized environments
> > > > 
> > > > I tend to agree with Andrew, if any of those things are done 
> > > > frequent enough that the hotplug performance matter you're doing 
> > > > something mighty odd.
> > > 
> > > Boot speedup?
> > 
> > Also, if it brings more attention (and more stability and more 
> > bugfixes) to CPU hotplug that's only good.
> 
> Sure, but do we need the extra complexity?
> 
> I mean, sure bootup speed might be nice, but any of the scenarios 
> given should simply not require cpu hotplug actions of a frequent 
> enough nature that any performance matters.

Well, the fact that the patches exist show that there's people 
caring about the speedup here. The speedup itself is non-trivial.

If the patches are technically correct, and if any existing 
uncleanlinesses in the affected code are fixed first (please list 
any TODO items in the CPU hotplug code you might know about), then 
there's no reason not to pursue these patches - unless the 
complexity increase is so huge that it makes the patches technically 
wrong.

The diffstat doesnt look _that_ awful IMO - 50 lines of code and i 
suspect the patches come with a promise to properly handle all prior 
and later bugs in this area? :)

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