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

[Pavel Machek]

On Tue 2009-06-16 14:00:59, Paul E. McKenney wrote:
> On Tue, Jun 16, 2009 at 01:37:15PM +0530, Vaidyanathan Srinivasan wrote:
> > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [2009-06-15 23:23:18]:
> > 
> > > On Tue, 16 Jun 2009 11:08:39 +0530 Gautham R Shenoy <ego@xxxxxxxxxx> 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
> 
> Perhaps also reducing boot-up time?  If I am correctly interpreting the
> above numbers, an eight-CPU system would be consuming 175 milliseconds
> bringing up the seven non-boot CPUs.  Reducing this by 150 milliseconds
> might be of interest to some people.  ;-)

...also it should save 300msec from s2ram cycle. Actually maybe
suspend code should be modified first,  as it can demonstrate the
changes without kernel<-> user interface changing?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/