Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra a.p.zijls...@chello.nl [2009-09-25 16:48:40]: On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. That's not how our hypervisor works. Then fix it? If you ask through the management interface, to remove a CPU from a partition, the HV will communicate with a daemon inside the partition that will then unplug the CPU via the right call. I don't really understand your objections to be honest. And I fail to see why it would be a layering violation to have the ability for the OS to indicate in what state it wishes to relinguish a CPU to the hypervisor, which more or less defines what is the expected latency for getting it back later on. OK, so the main objection is the abuse of CPU hotplug as resource management feature. CPU hotplug is terribly invasive and expensive to the kernel, doing hotplug on a minute basis is just plain crazy. If you want a CPU in a keep it near and don't hand it back to the HV state, why not use cpusets to isolate it and simply not run tasks on it? cpusets don't use stopmachine and are much nicer to the rest of the kernel over-all. Hi Peter, This interface is not expected to be used every minute or so to impact the operation of the rest of the system. Cpuhotplug is currently used as a resource management feature in virtualised system using dlpar operations. I do understand that cpu hotplug is invasive at run time and that amount of complexity is required to carefully isolate the cpu from any involvement in the running kernel. Building another interface to isolate the cpus to the same extent as cpu hotplug does today would be redundant and is going to be equally invasive. Alternatives like cpuset for isolation migrates only tasks. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Benjamin Herrenschmidt b...@kernel.crashing.org [2009-09-26 07:12:48]: On Fri, 2009-09-25 at 16:48 +0200, Peter Zijlstra wrote: On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. That's not how our hypervisor works. Then fix it? Are you serious ? :-) CPU hotplug is terribly invasive and expensive to the kernel, doing hotplug on a minute basis is just plain crazy. If you want a CPU in a keep it near and don't hand it back to the HV state, why not use cpusets to isolate it and simply not run tasks on it? cpusets don't use stopmachine and are much nicer to the rest of the kernel over-all. Gautham, what is the different in term of power saving between having it idle for long periods of time (which could do H_CEDE and with NO_HZ, probably wouln't need to wake up that often) and having it unplugged in a H_CEDE loop ? Hi Ben, A cede latency specifier value indicating latency expectation of the guest OS can be established in the VPA to inform the hypervisor during the H_CEDE call. Currently, we do call H_CEDE during NO_HZ for efficient idle. However, higher cede latency values may not be suitable for idle CPUs in the kernel and instead more energy savings may result from exploiting this feature through CPU hotplug interface. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue 2009-09-15 14:11:41, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. Agreed. Proposed interface is ugly. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. That's not how our hypervisor works. Then fix it? If you ask through the management interface, to remove a CPU from a partition, the HV will communicate with a daemon inside the partition that will then unplug the CPU via the right call. I don't really understand your objections to be honest. And I fail to see why it would be a layering violation to have the ability for the OS to indicate in what state it wishes to relinguish a CPU to the hypervisor, which more or less defines what is the expected latency for getting it back later on. OK, so the main objection is the abuse of CPU hotplug as resource management feature. CPU hotplug is terribly invasive and expensive to the kernel, doing hotplug on a minute basis is just plain crazy. If you want a CPU in a keep it near and don't hand it back to the HV state, why not use cpusets to isolate it and simply not run tasks on it? cpusets don't use stopmachine and are much nicer to the rest of the kernel over-all. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Fri, 2009-09-25 at 16:48 +0200, Peter Zijlstra wrote: On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. That's not how our hypervisor works. Then fix it? Are you serious ? :-) CPU hotplug is terribly invasive and expensive to the kernel, doing hotplug on a minute basis is just plain crazy. If you want a CPU in a keep it near and don't hand it back to the HV state, why not use cpusets to isolate it and simply not run tasks on it? cpusets don't use stopmachine and are much nicer to the rest of the kernel over-all. Gautham, what is the different in term of power saving between having it idle for long periods of time (which could do H_CEDE and with NO_HZ, probably wouln't need to wake up that often) and having it unplugged in a H_CEDE loop ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. That's not how our hypervisor works. If you ask through the management interface, to remove a CPU from a partition, the HV will communicate with a daemon inside the partition that will then unplug the CPU via the right call. I don't really understand your objections to be honest. And I fail to see why it would be a layering violation to have the ability for the OS to indicate in what state it wishes to relinguish a CPU to the hypervisor, which more or less defines what is the expected latency for getting it back later on. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: You aren't, I did :) No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus inactive. It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. Well, I did bring the latency into the picture. To some extent it -is- a latency issue. Though we aren't talking milliseconds here... if the CPU's been reallocated to another partition we are talking seconds or minutes or more until we can get it back :-) In any case, this sounds to me like a perfectly valid feature to have, which s390 already does via arch specific hooks, so I fail to see why it wouldn't be legitimate to have a common attribute for it. I don't buy into the layering violation. It's too often a straw man and an excuse for a lack of a proper reason. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, Sep 15, 2009 at 08:28:34PM +0530, Balbir Singh wrote: * Peter Zijlstra a.p.zijls...@chello.nl [2009-09-15 14:11:41]: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. From a design standpoint where we stand today is 1. A cede indicates that the CPU is no longer needed and can be reassigned (remember we do dedicated CPU partitions in power) 2. What this patch is trying to do is to say We don't need the CPU, but please don't reassign, put it to sleep FWIW, this sounds exactly like the same we have already on s390. But back then I didn't consider adding a common code infrastructure would make sense :) Besides the online attribute we have an additional configure attribute to which can only be written if the cpu is offline. Writing a 0 to it would mean that you currently won't need the cpu anymore and the hypervisor is free to reassign the cpu to a different LPAR. Writing a 1 to it means you want to use it. If there are enough resources you will get it. If not.. bad luck. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined inactive: This cedes the vCPU to the hypervisor with a cede latency Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. The problem is that all hypervisor managers cannot figure out what sort of latency guest OS can tolerate under the situation. They wouldn't know from what context guest OS has ceded the vcpu. It has to have some sort of hint, which is what the guest OS provides. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 20:58 +0530, Dipankar Sarma wrote: On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined inactive: This cedes the vCPU to the hypervisor with a cede latency Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. The problem is that all hypervisor managers cannot figure out what sort of latency guest OS can tolerate under the situation. They wouldn't know from what context guest OS has ceded the vcpu. It has to have some sort of hint, which is what the guest OS provides. I'm missing something here, hot-unplug is a slow path and should not ever be latency critical..? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, Sep 16, 2009 at 05:32:51PM +0200, Peter Zijlstra wrote: On Wed, 2009-09-16 at 20:58 +0530, Dipankar Sarma wrote: On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined inactive: This cedes the vCPU to the hypervisor with a cede latency Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. The problem is that all hypervisor managers cannot figure out what sort of latency guest OS can tolerate under the situation. They wouldn't know from what context guest OS has ceded the vcpu. It has to have some sort of hint, which is what the guest OS provides. I'm missing something here, hot-unplug is a slow path and should not ever be latency critical..? You aren't, I did :) No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus inactive. It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus inactive. It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. I'm still not getting it.. Suppose we have some guest, it booted with 4 cpus. We then offline 2 of them. Apparently this LPAR binds guest cpus to physical cpus? So we use a hypervisor interface to reclaim these 2 offlined cpus and re-assign them to some other guest. So far so good, right? Now if you were to try and online the cpus in the guest, it'd fail because the cpus aren't backed anymore, and the hot-plug simply times-out and fails. And we're still good, right? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra a.p.zijls...@chello.nl [2009-09-16 18:35:16]: On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus inactive. It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. I'm still not getting it.. Suppose we have some guest, it booted with 4 cpus. We then offline 2 of them. Apparently this LPAR binds guest cpus to physical cpus? So we use a hypervisor interface to reclaim these 2 offlined cpus and re-assign them to some other guest. So far so good, right? Now if you were to try and online the cpus in the guest, it'd fail because the cpus aren't backed anymore, and the hot-plug simply times-out and fails. And we're still good, right? The requirement differ here. If we had offlined 2 vCPUs for the purpose of system reconfiguration, the expected behavior with offline interface will work right. However the proposed cede interface is needed when we want them to temporarily go away but still come back when we do an online. We want the online to always succeed since the backing physical resources are not relinquished. The proposed interface facilitates offline without relinquishing the physical resources assigned to LPARs. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 22:33 +0530, Vaidyanathan Srinivasan wrote: * Peter Zijlstra a.p.zijls...@chello.nl [2009-09-16 18:35:16]: On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus inactive. It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. I'm still not getting it.. Suppose we have some guest, it booted with 4 cpus. We then offline 2 of them. Apparently this LPAR binds guest cpus to physical cpus? So we use a hypervisor interface to reclaim these 2 offlined cpus and re-assign them to some other guest. So far so good, right? Now if you were to try and online the cpus in the guest, it'd fail because the cpus aren't backed anymore, and the hot-plug simply times-out and fails. And we're still good, right? The requirement differ here. If we had offlined 2 vCPUs for the purpose of system reconfiguration, the expected behavior with offline interface will work right. However the proposed cede interface is needed when we want them to temporarily go away but still come back when we do an online. We want the online to always succeed since the backing physical resources are not relinquished. The proposed interface facilitates offline without relinquishing the physical resources assigned to LPARs. Then make that the platform default and leave the lpar management to whatever pokes at the lpar? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, Sep 16, 2009 at 07:22:35PM +0200, Peter Zijlstra wrote: On Wed, 2009-09-16 at 22:33 +0530, Vaidyanathan Srinivasan wrote: * Peter Zijlstra a.p.zijls...@chello.nl [2009-09-16 18:35:16]: Now if you were to try and online the cpus in the guest, it'd fail because the cpus aren't backed anymore, and the hot-plug simply times-out and fails. And we're still good, right? The requirement differ here. If we had offlined 2 vCPUs for the purpose of system reconfiguration, the expected behavior with offline interface will work right. However the proposed cede interface is needed when we want them to temporarily go away but still come back when we do an online. We want the online to always succeed since the backing physical resources are not relinquished. The proposed interface facilitates offline without relinquishing the physical resources assigned to LPARs. Then make that the platform default and leave the lpar management to whatever pokes at the lpar? That could have worked - however lpar management already uses the same sysfs interface to poke. The current semantics make the lpar vcpu deconfig state the platform default assuming that it will be used for lpar management. The only clean way to do this without breaking lpar management stuff is to add another state - inactive and retain backward compatibility. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/3] cpu: pseries: Cpu offline states framework
Hi, RFC not for inclusion This is the version 3 of the patch series to provide a cpu-offline framework that enables the administrators choose the state of a CPU when it is offlined, when multiple such states are exposed by the underlying architecture. Changes from Version 2:(can be found here: http://lkml.org/lkml/2009/8/28/102) - Addressed Andrew Morton's review comments regarding names of global variables, handling of error conditions and documentation of the interfaces. - Implemented a patch to provide helper functions to set the cede latency specifier value in the VPA indicating latency expectation of the guest OS when the vcpu is ceded from a subsequent H_CEDE hypercall. Hypervisor may use this for better energy savings. - Renamed of the cpu-hotplug states. deallocate is renamed as offline and deactivate is renamed as inactive. 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/cpunumber/available_hotplug_states To query or set the current state, on needs to read/write the sysfs tunable: /sys/devices/system/cpu/cpunumber/current_hotplug_state The patchset ensures that the writes to the current_hotplug_state sysfs file are serialized against the writes to the online file. This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. --- Arun R Bharadwaj (1): pSeries: cede latency specifier helper function. Gautham R Shenoy (2): cpu: Implement cpu-offline-state callbacks for pSeries. cpu: Offline state Framework. Documentation/cpu-hotplug.txt | 22 +++ arch/powerpc/include/asm/lppaca.h |9 + arch/powerpc/platforms/pseries/Makefile |2 arch/powerpc/platforms/pseries/hotplug-cpu.c| 88 ++- arch/powerpc/platforms/pseries/offline_driver.c | 148 +++ arch/powerpc/platforms/pseries/offline_driver.h | 20 +++ arch/powerpc/platforms/pseries/plpar_wrappers.h | 17 ++ arch/powerpc/platforms/pseries/smp.c| 17 ++ arch/powerpc/xmon/xmon.c|3 drivers/base/cpu.c | 181 ++- include/linux/cpu.h | 10 + 11 files changed, 498 insertions(+), 19 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/offline_driver.c create mode 100644 arch/powerpc/platforms/pseries/offline_driver.h -- Thanks and Regards gautham. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. Yeah it probably is a layering violation, but when has that stopped us before :) Is it anticipated that this will be useful on platforms other than pseries? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra a.p.zijls...@chello.nl [2009-09-15 14:11:41]: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: 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. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. 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. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. From a design standpoint where we stand today is 1. A cede indicates that the CPU is no longer needed and can be reassigned (remember we do dedicated CPU partitions in power) 2. What this patch is trying to do is to say We don't need the CPU, but please don't reassign, put it to sleep We work the same way with the hypervisor, that applications work with the OS today, by providing madvise and other hints. -- Balbir ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
