lkml.org 
[lkml]   [2010]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CPU Hotplug add/remove optimizations
  On 8/3/2010 1:07 AM, Andi Kleen wrote:
> Rohit Vaswani<rvaswani@codeaurora.org> writes:
>
>> Hi,
>>
>> We are trying to use cpu hotplug to turn off a cpu when it is not in
>> use to improve power management.
> It might not be a big issue on smaller systems, but CPU hotunplug
> involves stop_machine() and that is a very costly thing
> to do as systems become larger.
I think that currently for users, the cpu hotplug add time is what
matters more - so that the user does not experience that latency in the
UI when the core comes up. So I guess we could accept the latency for
CPU hotunplug for the time being because eventually it will save power.
>> I am trying to optimize the cpu
>> hotplug add and cpu hotplug remove timings. Currently cpu hotplug add
>> takes around 250ms and cpu hotplug remove takes 190 ms. For the
>> current purposes we want to assume that we are removing and adding the
>> same core. It seems that since we are actually not replacing the core
>> – there could be a lot of initialization overhead that could be
>> saved and restored instead of calibrating the entire core again.
>> One such thing we have been looking at is that once a core is powered
>> up during cpu hotplug add, it runs the calibrate_delay routine to
>> calculate the value of loops_per_jiffy. In such a case could we bypass
>> the calibrate_delay function and just save and restore the value of
>> loops_per_jiffy?
>> Does this approach seem wrong to anyone?
> It's wrong on a system that supports socket hotplug. The CPU you're
> power up again might not be the same.
Could we have a separate code path for bringing up the same core that we
just hot-unplugged?
One way could be that the user can specify that it is bringing up the
same core and thus the calibrate_delay function could be skipped. If a
new core is being added - the code path would calibrate the core again.
Currently the calibrate_delay function takes up almost the entire 250ms
of cpu hotplug-add time. Thus, if we can get rid of that function call,
when we know that we are bringing up the same core - the cpu hotplug add
could be almost instantaneous.
Is there a better way to accomplish this?
Are there any other issues that I may be missing in order to get this
working?
> In theory you could have some low level interface that distingushes
> these two cases, but right now that's not there.
>
>> Can we safely assume that the core will start at the same clock speed
>> at which the value was stored and then restored?
> That neither.
>
> -Andi
Thanks,
Rohit Vaswani

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-08-06 22:09    [W:0.052 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site