[PATCH v2 0/2] cpu: pseries: Offline state framework.
Peter Zijlstra
a.p.zijlstra at chello.nl
Wed Sep 2 15:33:31 EST 2009
On Fri, 2009-08-28 at 15:30 +0530, Gautham R Shenoy wrote:
> Hi,
>
> This is the version 2 of the patch series to provide a cpu-offline framework
> that enables the administrators choose the state the offline CPU must be put
> into when multiple such states are exposed by the underlying architecture.
>
> Version 1 of the Patch can be found here:
> http://lkml.org/lkml/2009/8/6/236
>
> The patch-series exposes the following sysfs tunables to
> allow the system-adminstrator to choose the state of a CPU:
>
> To query the available hotplug states, one needs to read the sysfs tunable:
> /sys/devices/system/cpu/cpu<number>/available_hotplug_states
> To query or set the current state, on needs to read/write the sysfs tunable:
> /sys/devices/system/cpu/cpu<number>/current_states
>
> The patchset ensures that the writes to the "current_state" sysfs file are
> serialized against the writes to the "online" file.
>
> This patchset also contains the offline state driver implemented for
> pSeries. For pSeries, we define three available_hotplug_states. They are:
>
> online: The processor is online.
>
> deallocate: This is the the default behaviour when the cpu is offlined
> even in the absense of this driver. The CPU would call make an
> rtas_stop_self() call and hand over the CPU back to the resource pool,
> thereby effectively deallocating that vCPU from the LPAR.
> NOTE: This would result in a configuration change to the LPAR
> which is visible to the outside world.
>
> deactivate: This cedes the vCPU to the hypervisor which
> in turn can put the vCPU time to the best use.
> NOTE: This option DOES NOT result in a configuration change
> and the vCPU would be still entitled to the LPAR to which it earlier
> belong to.
>
> Awaiting your feedback.
I'm still thinking this is a bad idea.
The OS should only know about online/offline.
Use the hypervisor interface to deal with the cpu once its offline.
That is, I think this interface you propose is a layering violation.
More information about the Linuxppc-dev
mailing list