Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Gerry, Khalid, On Mon, 2012-07-09 at 02:40 +, Jiang Liu wrote: > Hi Khalid, > It depends on it's running on physical or virtualizaiton host. If > it's a native OS running on physical platforms, we have real platforms > to support physical processor, memory board, IOH(PCIe host bridge) and > node (including mem/cpu/IOH) hotplug, but we haven't really seen a > platform supporting CPU(core) hotplug yet. > I think CPU(core) hotplug is for virtualization, where each physical > core is presented as a virtual processor to guest OS. So to > dynamically reconfigure guest OS capabilties, we need to support CPU > hotplug. Agreed. We need to enable CPU hot-add/remove features for visualization, such as KVM. > Actually we are working on a project to enhance ACPI based physical > device hotplug, which aims to unify the way to support physical > processor(ACPI Container), memory board(ACPI Memory Device), PCI root > bridge(ACPI PCI Host bridge) and node (ACPI Container) hotplug. Cool. > Toshi, seems there's ongoing effort from both you, Yinghai, Yasuaki > Ishimatsu and us to enable ACPI based physical device hotplug. It > would be great if we could cooperate on this area. Absolutely! It will be great for us to collaborate in this area. Gerry, Khalid, please let me know if you have any further comments on this patch. Thanks, -Toshi > Thanks! > Gerry > > > > On Sat, Jul 7, 2012 at 5:00 AM, Toshi Kani wrote: > On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: > > On 07/06/2012 01:13 PM, Toshi Kani wrote: > > > > > > > > For step 2) and 4), I am wondering if they are relevant to CPU > hotplug > > > these days. In ACPI namespace, a processor object represents a > logical > > > processor (or a core when hyper-threading is disabled). A > physical > > > processor (i.e. a socket) usually has multiple cores, and memory > > > controller and bus interface are part of the socket functionality. > > > Hence, I think step 2) and 4) belong to socket-level hot-removal > > > operation, which can be implemented as container hot-remove when a > > > socket is represented with a container object. > > > > What does it mean to eject just a core in that case? If there are > seven > > other cores in the physical processor and you get a request to eject > > one core, what would you expect kernel to do - simply move all > processes > > and interrupts off of that core, take it out of scheduling > consideration > > and simply idle the core? If yes, how is that any different from > simply > > offlining a core? > > > Yes, offlining and eject are similar operations to a core as it alone > cannot be removed physically. Ejecting a core is a logical eject > operation, which updates the status (_STA) of the object in ACPI after > offlining. The difference from the offlining is that the ejected core > is no longer assigned to the partition. Here is one example. Say, a > core is assigned to a guest partition as a dedicated resource (ex.100% > of its CPU time is bound to the partition). Offlining this core saves > the power-consumption, but this core is still bound to the partition. > Ejecting the core removes it from the partition (logically), and > allows it to be assigned to other partition as a dedicated resource > with hot-add. > > > > If you are ejecting individual cores at a time, do you > > keep track of how many you have ejected and then eject the entire > physical > > CPU along with memory and IOH associated with the socket when the > last > > core is ejected? > > > It depends on the firmware implementation, but typically the answer is > no. _EJ0 of a core object only removes the associated core object. It > will require a separate socket hot-remove request to eject the > socket-level resources. That is, the OS may not call _EJ0 of a socket > object from the core hot-remove operation just because all children > cores are removed. > > Thanks, > -Toshi > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Gerry, Khalid, On Mon, 2012-07-09 at 02:40 +, Jiang Liu wrote: Hi Khalid, It depends on it's running on physical or virtualizaiton host. If it's a native OS running on physical platforms, we have real platforms to support physical processor, memory board, IOH(PCIe host bridge) and node (including mem/cpu/IOH) hotplug, but we haven't really seen a platform supporting CPU(core) hotplug yet. I think CPU(core) hotplug is for virtualization, where each physical core is presented as a virtual processor to guest OS. So to dynamically reconfigure guest OS capabilties, we need to support CPU hotplug. Agreed. We need to enable CPU hot-add/remove features for visualization, such as KVM. Actually we are working on a project to enhance ACPI based physical device hotplug, which aims to unify the way to support physical processor(ACPI Container), memory board(ACPI Memory Device), PCI root bridge(ACPI PCI Host bridge) and node (ACPI Container) hotplug. Cool. Toshi, seems there's ongoing effort from both you, Yinghai, Yasuaki Ishimatsu and us to enable ACPI based physical device hotplug. It would be great if we could cooperate on this area. Absolutely! It will be great for us to collaborate in this area. Gerry, Khalid, please let me know if you have any further comments on this patch. Thanks, -Toshi Thanks! Gerry On Sat, Jul 7, 2012 at 5:00 AM, Toshi Kani toshi.k...@hp.com wrote: On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: On 07/06/2012 01:13 PM, Toshi Kani wrote: For step 2) and 4), I am wondering if they are relevant to CPU hotplug these days. In ACPI namespace, a processor object represents a logical processor (or a core when hyper-threading is disabled). A physical processor (i.e. a socket) usually has multiple cores, and memory controller and bus interface are part of the socket functionality. Hence, I think step 2) and 4) belong to socket-level hot-removal operation, which can be implemented as container hot-remove when a socket is represented with a container object. What does it mean to eject just a core in that case? If there are seven other cores in the physical processor and you get a request to eject one core, what would you expect kernel to do - simply move all processes and interrupts off of that core, take it out of scheduling consideration and simply idle the core? If yes, how is that any different from simply offlining a core? Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex.100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. If you are ejecting individual cores at a time, do you keep track of how many you have ejected and then eject the entire physical CPU along with memory and IOH associated with the socket when the last core is ejected? It depends on the firmware implementation, but typically the answer is no. _EJ0 of a core object only removes the associated core object. It will require a separate socket hot-remove request to eject the socket-level resources. That is, the OS may not call _EJ0 of a socket object from the core hot-remove operation just because all children cores are removed. Thanks, -Toshi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Mon, 2012-07-16 at 04:53 +, Pandarathil, Vijaymohan R wrote:
> Hi Toshi,
>
> Did some basic KVM guest cpu hotplug testing of this patch over your OST
> patchset along with fixes in qemu-kvm for guest cpu hotplug.
>
> Vijay
>
> virsh # vcpucount vmb91g1
> maximum config 4
> maximum live 4
> current config 4
> current live 4
>
> virsh # setvcpus vmb91g1 3
>
> virsh # vcpucount vmb91g1
> maximum config 4
> maximum live 4
> current config 4
> current live 3
>
> virsh # setvcpus vmb91g1 4
>
> virsh # vcpucount vmb91g1
> maximum config 4
> maximum live 4
> current config 4
> current live 4
>
> virsh # setvcpus vmb91g1 2
>
> virsh # vcpucount vmb91g1
> maximum config 4
> maximum live 4
> current config 4
> current live 2
>
> The guest cpu counts (as shown by lscpu in the guest) also changes.
>
>
> Tested-by: Vijay Mohan Pandarathil
Hi Vijay,
Great! Thanks for the testing!
-Toshi
>
>
> -Original Message-
> From: Kani, Toshimitsu
> Sent: Friday, June 29, 2012 7:51 AM
> To: l...@kernel.org; linux-a...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Kani, Toshimitsu
> Subject: [PATCH] ACPI: Add ACPI CPU hot-remove support
>
> Added CPU hot-remove support through an ACPI eject notification.
> It calls acpi_bus_hot_remove_device(), which shares the same code
> path with the sysfs eject operation. acpi_os_hotplug_execute()
> serializes hot-remove operations between ACPI hot-remove and sysfs
> eject requests.
>
> Signed-off-by: Toshi Kani
>
> ---
> This patch applies on top of the patchset below.
>
> [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
> http://marc.info/?l=linux-acpi=134074381322973=2
>
> ---
> drivers/acpi/processor_driver.c | 27 +--
> 1 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index f9fa1b2..a6f6bde 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
> acpi_device **device)
> static void acpi_processor_hotplug_notify(acpi_handle handle,
> u32 event, void *data)
> {
> - struct acpi_processor *pr;
> struct acpi_device *device = NULL;
> + struct acpi_eject_event *ej_event = NULL;
> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
> int result;
>
> @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
> handle,
> "received ACPI_NOTIFY_EJECT_REQUEST\n"));
>
> if (acpi_bus_get_device(handle, )) {
> - printk(KERN_ERR PREFIX
> - "Device don't exist, dropping EJECT\n");
> + pr_err(PREFIX "Device don't exist, dropping EJECT\n");
> break;
> }
> - pr = acpi_driver_data(device);
> - if (!pr) {
> - printk(KERN_ERR PREFIX
> - "Driver data is NULL, dropping EJECT\n");
> + if (!acpi_driver_data(device)) {
> + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n");
> break;
> }
>
> - /* REVISIT: update when eject is supported */
> - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
> - break;
> + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
> + if (!ej_event) {
> + pr_err(PREFIX "No memory, dropping EJECT\n");
> + break;
> + }
> +
> + ej_event->handle = handle;
> + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> + acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
> + (void *)ej_event);
> +
> + /* eject is performed asynchronously */
> + return;
>
> default:
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Mon, 2012-07-16 at 04:53 +, Pandarathil, Vijaymohan R wrote:
Hi Toshi,
Did some basic KVM guest cpu hotplug testing of this patch over your OST
patchset along with fixes in qemu-kvm for guest cpu hotplug.
Vijay
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 3
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 3
virsh # setvcpus vmb91g1 4
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 2
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 2
The guest cpu counts (as shown by lscpu in the guest) also changes.
Tested-by: Vijay Mohan Pandarathilvijaymohan.pandarat...@hp.com
Hi Vijay,
Great! Thanks for the testing!
-Toshi
-Original Message-
From: Kani, Toshimitsu
Sent: Friday, June 29, 2012 7:51 AM
To: l...@kernel.org; linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Kani, Toshimitsu
Subject: [PATCH] ACPI: Add ACPI CPU hot-remove support
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani toshi.k...@hp.com
---
This patch applies on top of the patchset below.
[PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
http://marc.info/?l=linux-acpim=134074381322973w=2
---
drivers/acpi/processor_driver.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index f9fa1b2..a6f6bde 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- printk(KERN_ERR PREFIX
- Device don't exist, dropping EJECT\n);
+ pr_err(PREFIX Device don't exist, dropping EJECT\n);
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- Driver data is NULL, dropping EJECT\n);
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX Driver data is NULL, dropping EJECT\n);
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX No memory, dropping EJECT\n);
+ break;
+ }
+
+ ej_event-handle = handle;
+ ej_event-event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Toshi,
Did some basic KVM guest cpu hotplug testing of this patch over your OST
patchset along with fixes in qemu-kvm for guest cpu hotplug.
Vijay
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 3
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 3
virsh # setvcpus vmb91g1 4
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 2
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 2
The guest cpu counts (as shown by lscpu in the guest) also changes.
Tested-by: Vijay Mohan Pandarathil
-Original Message-
From: Kani, Toshimitsu
Sent: Friday, June 29, 2012 7:51 AM
To: l...@kernel.org; linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Kani, Toshimitsu
Subject: [PATCH] ACPI: Add ACPI CPU hot-remove support
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani
---
This patch applies on top of the patchset below.
[PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
http://marc.info/?l=linux-acpi=134074381322973=2
---
drivers/acpi/processor_driver.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index f9fa1b2..a6f6bde 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
"received ACPI_NOTIFY_EJECT_REQUEST\n"));
if (acpi_bus_get_device(handle, )) {
- printk(KERN_ERR PREFIX
- "Device don't exist, dropping EJECT\n");
+ pr_err(PREFIX "Device don't exist, dropping EJECT\n");
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- "Driver data is NULL, dropping EJECT\n");
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX "Driver data is NULL, dropping EJECT\n");
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX "No memory, dropping EJECT\n");
+ break;
+ }
+
+ ej_event->handle = handle;
+ ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
1.7.7.6
RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Toshi,
Did some basic KVM guest cpu hotplug testing of this patch over your OST
patchset along with fixes in qemu-kvm for guest cpu hotplug.
Vijay
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 3
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 3
virsh # setvcpus vmb91g1 4
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 4
virsh # setvcpus vmb91g1 2
virsh # vcpucount vmb91g1
maximum config 4
maximum live 4
current config 4
current live 2
The guest cpu counts (as shown by lscpu in the guest) also changes.
Tested-by: Vijay Mohan Pandarathilvijaymohan.pandarat...@hp.com
-Original Message-
From: Kani, Toshimitsu
Sent: Friday, June 29, 2012 7:51 AM
To: l...@kernel.org; linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Kani, Toshimitsu
Subject: [PATCH] ACPI: Add ACPI CPU hot-remove support
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani toshi.k...@hp.com
---
This patch applies on top of the patchset below.
[PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
http://marc.info/?l=linux-acpim=134074381322973w=2
---
drivers/acpi/processor_driver.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index f9fa1b2..a6f6bde 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- printk(KERN_ERR PREFIX
- Device don't exist, dropping EJECT\n);
+ pr_err(PREFIX Device don't exist, dropping EJECT\n);
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- Driver data is NULL, dropping EJECT\n);
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX Driver data is NULL, dropping EJECT\n);
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX No memory, dropping EJECT\n);
+ break;
+ }
+
+ ej_event-handle = handle;
+ ej_event-event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
1.7.7.6
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Tue, 2012-07-10 at 16:56 -0600, Khalid Aziz wrote: > On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: > > Yes, offlining and eject are similar operations to a core as it alone > > cannot be removed physically. Ejecting a core is a logical eject > > operation, which updates the status (_STA) of the object in ACPI after > > offlining. The difference from the offlining is that the ejected core > > is no longer assigned to the partition. Here is one example. Say, a > > core is assigned to a guest partition as a dedicated resource (ex. 100% > > of its CPU time is bound to the partition). Offlining this core saves > > the power-consumption, but this core is still bound to the partition. > > Ejecting the core removes it from the partition (logically), and allows > > it to be assigned to other partition as a dedicated resource with > > hot-add. > > > > Ejecting a core is reasonable when eject happens from a guest. I still > wonder what firmware would do if kernel calls eject method on a core > when running on the native host platform. If firmware behavior is not > well defined in this case, there might be some risk associated with > calling eject method on core. > > Makes sense? No, that's not the case. The firmware only implements _EJ0 when it supports the behavior on the environment. It is true for both native and virtual platforms. Note that the presence of a CPU is abstracted with _STA in ACPI, so it does not matter to the kernel if an eject is a physical or logical operation. For example, HP Superdome 2 implements _EJ0 on the native platform to support capacity-on-demand and RAS features (which are supported by HP-UX). _EJ0 is still a logical eject operation in this case. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: > Yes, offlining and eject are similar operations to a core as it alone > cannot be removed physically. Ejecting a core is a logical eject > operation, which updates the status (_STA) of the object in ACPI after > offlining. The difference from the offlining is that the ejected core > is no longer assigned to the partition. Here is one example. Say, a > core is assigned to a guest partition as a dedicated resource (ex. 100% > of its CPU time is bound to the partition). Offlining this core saves > the power-consumption, but this core is still bound to the partition. > Ejecting the core removes it from the partition (logically), and allows > it to be assigned to other partition as a dedicated resource with > hot-add. > Ejecting a core is reasonable when eject happens from a guest. I still wonder what firmware would do if kernel calls eject method on a core when running on the native host platform. If firmware behavior is not well defined in this case, there might be some risk associated with calling eject method on core. Makes sense? -- Khalid Aziz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Tue, 2012-07-10 at 11:29 +, IgorMammedov wrote: > domain.invalid> writes: > > > > > From: Toshi Kani hp.com> > > > > Added CPU hot-remove support through an ACPI eject notification. > > It calls acpi_bus_hot_remove_device(), which shares the same code > > path with the sysfs eject operation. acpi_os_hotplug_execute() > > serializes hot-remove operations between ACPI hot-remove and sysfs > > eject requests. > > > > Signed-off-by: Toshi Kani hp.com> > > > > --- > > This patch applies on top of the patchset below. > > > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > > http://marc.info/?l=linux-acpi=134074381322973=2 > > > Hi Toshi, > > Tested patches on RHEL6.3, ejected cpu is removed from sysfs and corresponding > _EJxx method is called as expected upon receiving notify with eject request. > > Tested-by: IgorMammedov Great! Thanks Igor for testing it! -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
domain.invalid> writes: > > From: Toshi Kani hp.com> > > Added CPU hot-remove support through an ACPI eject notification. > It calls acpi_bus_hot_remove_device(), which shares the same code > path with the sysfs eject operation. acpi_os_hotplug_execute() > serializes hot-remove operations between ACPI hot-remove and sysfs > eject requests. > > Signed-off-by: Toshi Kani hp.com> > > --- > This patch applies on top of the patchset below. > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > http://marc.info/?l=linux-acpi=134074381322973=2 > Hi Toshi, Tested patches on RHEL6.3, ejected cpu is removed from sysfs and corresponding _EJxx method is called as expected upon receiving notify with eject request. Tested-by: IgorMammedov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
y at domain.invalid writes: From: Toshi Kani toshi.kani at hp.com Added CPU hot-remove support through an ACPI eject notification. It calls acpi_bus_hot_remove_device(), which shares the same code path with the sysfs eject operation. acpi_os_hotplug_execute() serializes hot-remove operations between ACPI hot-remove and sysfs eject requests. Signed-off-by: Toshi Kani toshi.kani at hp.com --- This patch applies on top of the patchset below. [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug http://marc.info/?l=linux-acpim=134074381322973w=2 Hi Toshi, Tested patches on RHEL6.3, ejected cpu is removed from sysfs and corresponding _EJxx method is called as expected upon receiving notify with eject request. Tested-by: IgorMammedov imamm...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Tue, 2012-07-10 at 11:29 +, IgorMammedov wrote: y at domain.invalid writes: From: Toshi Kani toshi.kani at hp.com Added CPU hot-remove support through an ACPI eject notification. It calls acpi_bus_hot_remove_device(), which shares the same code path with the sysfs eject operation. acpi_os_hotplug_execute() serializes hot-remove operations between ACPI hot-remove and sysfs eject requests. Signed-off-by: Toshi Kani toshi.kani at hp.com --- This patch applies on top of the patchset below. [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug http://marc.info/?l=linux-acpim=134074381322973w=2 Hi Toshi, Tested patches on RHEL6.3, ejected cpu is removed from sysfs and corresponding _EJxx method is called as expected upon receiving notify with eject request. Tested-by: IgorMammedov imamm...@redhat.com Great! Thanks Igor for testing it! -Toshi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex. 100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. Ejecting a core is reasonable when eject happens from a guest. I still wonder what firmware would do if kernel calls eject method on a core when running on the native host platform. If firmware behavior is not well defined in this case, there might be some risk associated with calling eject method on core. Makes sense? -- Khalid Aziz khalid.a...@hp.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Tue, 2012-07-10 at 16:56 -0600, Khalid Aziz wrote: On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex. 100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. Ejecting a core is reasonable when eject happens from a guest. I still wonder what firmware would do if kernel calls eject method on a core when running on the native host platform. If firmware behavior is not well defined in this case, there might be some risk associated with calling eject method on core. Makes sense? No, that's not the case. The firmware only implements _EJ0 when it supports the behavior on the environment. It is true for both native and virtual platforms. Note that the presence of a CPU is abstracted with _STA in ACPI, so it does not matter to the kernel if an eject is a physical or logical operation. For example, HP Superdome 2 implements _EJ0 on the native platform to support capacity-on-demand and RAS features (which are supported by HP-UX). _EJ0 is still a logical eject operation in this case. Thanks, -Toshi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: > On 07/06/2012 01:13 PM, Toshi Kani wrote: > > > > > For step 2) and 4), I am wondering if they are relevant to CPU hotplug > > these days. In ACPI namespace, a processor object represents a logical > > processor (or a core when hyper-threading is disabled). A physical > > processor (i.e. a socket) usually has multiple cores, and memory > > controller and bus interface are part of the socket functionality. > > Hence, I think step 2) and 4) belong to socket-level hot-removal > > operation, which can be implemented as container hot-remove when a > > socket is represented with a container object. > > What does it mean to eject just a core in that case? If there are seven > other cores in the physical processor and you get a request to eject > one core, what would you expect kernel to do - simply move all processes > and interrupts off of that core, take it out of scheduling consideration > and simply idle the core? If yes, how is that any different from simply > offlining a core? Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex. 100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. > If you are ejecting individual cores at a time, do you > keep track of how many you have ejected and then eject the entire physical > CPU along with memory and IOH associated with the socket when the last > core is ejected? It depends on the firmware implementation, but typically the answer is no. _EJ0 of a core object only removes the associated core object. It will require a separate socket hot-remove request to eject the socket-level resources. That is, the OS may not call _EJ0 of a socket object from the core hot-remove operation just because all children cores are removed. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On 07/06/2012 01:13 PM, Toshi Kani wrote: For step 2) and 4), I am wondering if they are relevant to CPU hotplug these days. In ACPI namespace, a processor object represents a logical processor (or a core when hyper-threading is disabled). A physical processor (i.e. a socket) usually has multiple cores, and memory controller and bus interface are part of the socket functionality. Hence, I think step 2) and 4) belong to socket-level hot-removal operation, which can be implemented as container hot-remove when a socket is represented with a container object. What does it mean to eject just a core in that case? If there are seven other cores in the physical processor and you get a request to eject one core, what would you expect kernel to do - simply move all processes and interrupts off of that core, take it out of scheduling consideration and simply idle the core? If yes, how is that any different from simply offlining a core? If you are ejecting individual cores at a time, do you keep track of how many you have ejected and then eject the entire physical CPU along with memory and IOH associated with the socket when the last core is ejected? -- Khalid Khalid Aziz Unix Systems Lab (970)898-9214Hewlett-Packard khalid.a...@hp.com Fort Collins, CO -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Sat, 2012-07-07 at 00:27 +0800, Jiang Liu wrote:
> Hi Toshi,
> I think a better solution here is to send a notification to acpid
> daemon instead of directly ejecting the physical processor in kernel by
> apci hotplug work thread. The daemon should do:
> 1) check whether user policy allows to remove the physical processor
> 2) resolve any dependency issues, such as some memory/IOHs may have
> dependency on the processor.
> 3) Remove all devices on the physical processor through sysfs.
> 4) Power off the physical processor through sysfs.
>
> If we rely on the acpi hotplug work thread to do the hard work, it
> may block the work thread for a very long time and it won't respond to other
> hotplug events.
> Thanks!
> Gerry
Hi Gerry,
Good points. I agree with your concerns in general.
For step 2) and 4), I am wondering if they are relevant to CPU hotplug
these days. In ACPI namespace, a processor object represents a logical
processor (or a core when hyper-threading is disabled). A physical
processor (i.e. a socket) usually has multiple cores, and memory
controller and bus interface are part of the socket functionality.
Hence, I think step 2) and 4) belong to socket-level hot-removal
operation, which can be implemented as container hot-remove when a
socket is represented with a container object.
I agree that step 1) needs to be concerned for CPU hotplug. Other
approach (which has been implemented in other OS) is that such user
policy can be managed by management console or hypervisor, which becomes
a single place to manage the policy for multiple OS instances, i.e. if
hot-remove is disallowed on a target, it fails a request and does not
send a GPE. Asking customers to setup the policy to each OS instance
can be problematic, esp. when there are many OS instances on virtualized
environment. Other issue is that when a hot-remove request is failed or
ignored in user space, we do not have a way to fail the request with
_OST at this point. Therefore, from the management console /
hypervisor, where a hot-remove request was made from, this case can be
seen as a hang in the hot-remove request.
Thanks,
-Toshi
> On 06/29/2012 10:51 PM, Toshi Kani wrote:
> > Added CPU hot-remove support through an ACPI eject notification.
> > It calls acpi_bus_hot_remove_device(), which shares the same code
> > path with the sysfs eject operation. acpi_os_hotplug_execute()
> > serializes hot-remove operations between ACPI hot-remove and sysfs
> > eject requests.
> >
> > Signed-off-by: Toshi Kani
> >
> > ---
> > This patch applies on top of the patchset below.
> >
> > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
> > http://marc.info/?l=linux-acpi=134074381322973=2
> >
> > ---
> > drivers/acpi/processor_driver.c | 27 +--
> > 1 files changed, 17 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c
> > b/drivers/acpi/processor_driver.c
> > index f9fa1b2..a6f6bde 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle,
> > struct acpi_device **device)
> > static void acpi_processor_hotplug_notify(acpi_handle handle,
> > u32 event, void *data)
> > {
> > - struct acpi_processor *pr;
> > struct acpi_device *device = NULL;
> > + struct acpi_eject_event *ej_event = NULL;
> > u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
> > int result;
> >
> > @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
> > handle,
> > "received ACPI_NOTIFY_EJECT_REQUEST\n"));
> >
> > if (acpi_bus_get_device(handle, )) {
> > - printk(KERN_ERR PREFIX
> > - "Device don't exist, dropping EJECT\n");
> > + pr_err(PREFIX "Device don't exist, dropping EJECT\n");
> > break;
> > }
> > - pr = acpi_driver_data(device);
> > - if (!pr) {
> > - printk(KERN_ERR PREFIX
> > - "Driver data is NULL, dropping EJECT\n");
> > + if (!acpi_driver_data(device)) {
> > + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n");
> > break;
> > }
> >
> > - /* REVISIT: update when eject is supported */
> > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
> > - break;
> > + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
> > + if (!ej_event) {
> > + pr_err(PREFIX "No memory, dropping EJECT\n");
> > + break;
> > + }
> > +
> > + ej_event->handle = handle;
> > + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> > + acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
> >
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Toshi,
I think a better solution here is to send a notification to acpid
daemon instead of directly ejecting the physical processor in kernel by
apci hotplug work thread. The daemon should do:
1) check whether user policy allows to remove the physical processor
2) resolve any dependency issues, such as some memory/IOHs may have
dependency on the processor.
3) Remove all devices on the physical processor through sysfs.
4) Power off the physical processor through sysfs.
If we rely on the acpi hotplug work thread to do the hard work, it
may block the work thread for a very long time and it won't respond to other
hotplug events.
Thanks!
Gerry
On 06/29/2012 10:51 PM, Toshi Kani wrote:
> Added CPU hot-remove support through an ACPI eject notification.
> It calls acpi_bus_hot_remove_device(), which shares the same code
> path with the sysfs eject operation. acpi_os_hotplug_execute()
> serializes hot-remove operations between ACPI hot-remove and sysfs
> eject requests.
>
> Signed-off-by: Toshi Kani
>
> ---
> This patch applies on top of the patchset below.
>
> [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
> http://marc.info/?l=linux-acpi=134074381322973=2
>
> ---
> drivers/acpi/processor_driver.c | 27 +--
> 1 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index f9fa1b2..a6f6bde 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
> acpi_device **device)
> static void acpi_processor_hotplug_notify(acpi_handle handle,
> u32 event, void *data)
> {
> - struct acpi_processor *pr;
> struct acpi_device *device = NULL;
> + struct acpi_eject_event *ej_event = NULL;
> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
> int result;
>
> @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
> handle,
> "received ACPI_NOTIFY_EJECT_REQUEST\n"));
>
> if (acpi_bus_get_device(handle, )) {
> - printk(KERN_ERR PREFIX
> - "Device don't exist, dropping EJECT\n");
> + pr_err(PREFIX "Device don't exist, dropping EJECT\n");
> break;
> }
> - pr = acpi_driver_data(device);
> - if (!pr) {
> - printk(KERN_ERR PREFIX
> - "Driver data is NULL, dropping EJECT\n");
> + if (!acpi_driver_data(device)) {
> + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n");
> break;
> }
>
> - /* REVISIT: update when eject is supported */
> - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
> - break;
> + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
> + if (!ej_event) {
> + pr_err(PREFIX "No memory, dropping EJECT\n");
> + break;
> + }
> +
> + ej_event->handle = handle;
> + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> + acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
> + (void *)ej_event);
> +
> + /* eject is performed asynchronously */
> + return;
>
> default:
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
Hi Toshi,
I think a better solution here is to send a notification to acpid
daemon instead of directly ejecting the physical processor in kernel by
apci hotplug work thread. The daemon should do:
1) check whether user policy allows to remove the physical processor
2) resolve any dependency issues, such as some memory/IOHs may have
dependency on the processor.
3) Remove all devices on the physical processor through sysfs.
4) Power off the physical processor through sysfs.
If we rely on the acpi hotplug work thread to do the hard work, it
may block the work thread for a very long time and it won't respond to other
hotplug events.
Thanks!
Gerry
On 06/29/2012 10:51 PM, Toshi Kani wrote:
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani toshi.k...@hp.com
---
This patch applies on top of the patchset below.
[PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
http://marc.info/?l=linux-acpim=134074381322973w=2
---
drivers/acpi/processor_driver.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index f9fa1b2..a6f6bde 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- printk(KERN_ERR PREFIX
- Device don't exist, dropping EJECT\n);
+ pr_err(PREFIX Device don't exist, dropping EJECT\n);
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- Driver data is NULL, dropping EJECT\n);
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX Driver data is NULL, dropping EJECT\n);
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX No memory, dropping EJECT\n);
+ break;
+ }
+
+ ej_event-handle = handle;
+ ej_event-event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Sat, 2012-07-07 at 00:27 +0800, Jiang Liu wrote:
Hi Toshi,
I think a better solution here is to send a notification to acpid
daemon instead of directly ejecting the physical processor in kernel by
apci hotplug work thread. The daemon should do:
1) check whether user policy allows to remove the physical processor
2) resolve any dependency issues, such as some memory/IOHs may have
dependency on the processor.
3) Remove all devices on the physical processor through sysfs.
4) Power off the physical processor through sysfs.
If we rely on the acpi hotplug work thread to do the hard work, it
may block the work thread for a very long time and it won't respond to other
hotplug events.
Thanks!
Gerry
Hi Gerry,
Good points. I agree with your concerns in general.
For step 2) and 4), I am wondering if they are relevant to CPU hotplug
these days. In ACPI namespace, a processor object represents a logical
processor (or a core when hyper-threading is disabled). A physical
processor (i.e. a socket) usually has multiple cores, and memory
controller and bus interface are part of the socket functionality.
Hence, I think step 2) and 4) belong to socket-level hot-removal
operation, which can be implemented as container hot-remove when a
socket is represented with a container object.
I agree that step 1) needs to be concerned for CPU hotplug. Other
approach (which has been implemented in other OS) is that such user
policy can be managed by management console or hypervisor, which becomes
a single place to manage the policy for multiple OS instances, i.e. if
hot-remove is disallowed on a target, it fails a request and does not
send a GPE. Asking customers to setup the policy to each OS instance
can be problematic, esp. when there are many OS instances on virtualized
environment. Other issue is that when a hot-remove request is failed or
ignored in user space, we do not have a way to fail the request with
_OST at this point. Therefore, from the management console /
hypervisor, where a hot-remove request was made from, this case can be
seen as a hang in the hot-remove request.
Thanks,
-Toshi
On 06/29/2012 10:51 PM, Toshi Kani wrote:
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani toshi.k...@hp.com
---
This patch applies on top of the patchset below.
[PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug
http://marc.info/?l=linux-acpim=134074381322973w=2
---
drivers/acpi/processor_driver.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c
b/drivers/acpi/processor_driver.c
index f9fa1b2..a6f6bde 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle,
struct acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- printk(KERN_ERR PREFIX
- Device don't exist, dropping EJECT\n);
+ pr_err(PREFIX Device don't exist, dropping EJECT\n);
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- Driver data is NULL, dropping EJECT\n);
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX Driver data is NULL, dropping EJECT\n);
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX No memory, dropping EJECT\n);
+ break;
+ }
+
+ ej_event-handle = handle;
+ ej_event-event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On 07/06/2012 01:13 PM, Toshi Kani wrote: For step 2) and 4), I am wondering if they are relevant to CPU hotplug these days. In ACPI namespace, a processor object represents a logical processor (or a core when hyper-threading is disabled). A physical processor (i.e. a socket) usually has multiple cores, and memory controller and bus interface are part of the socket functionality. Hence, I think step 2) and 4) belong to socket-level hot-removal operation, which can be implemented as container hot-remove when a socket is represented with a container object. What does it mean to eject just a core in that case? If there are seven other cores in the physical processor and you get a request to eject one core, what would you expect kernel to do - simply move all processes and interrupts off of that core, take it out of scheduling consideration and simply idle the core? If yes, how is that any different from simply offlining a core? If you are ejecting individual cores at a time, do you keep track of how many you have ejected and then eject the entire physical CPU along with memory and IOH associated with the socket when the last core is ejected? -- Khalid Khalid Aziz Unix Systems Lab (970)898-9214Hewlett-Packard khalid.a...@hp.com Fort Collins, CO -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: On 07/06/2012 01:13 PM, Toshi Kani wrote: For step 2) and 4), I am wondering if they are relevant to CPU hotplug these days. In ACPI namespace, a processor object represents a logical processor (or a core when hyper-threading is disabled). A physical processor (i.e. a socket) usually has multiple cores, and memory controller and bus interface are part of the socket functionality. Hence, I think step 2) and 4) belong to socket-level hot-removal operation, which can be implemented as container hot-remove when a socket is represented with a container object. What does it mean to eject just a core in that case? If there are seven other cores in the physical processor and you get a request to eject one core, what would you expect kernel to do - simply move all processes and interrupts off of that core, take it out of scheduling consideration and simply idle the core? If yes, how is that any different from simply offlining a core? Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex. 100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. If you are ejecting individual cores at a time, do you keep track of how many you have ejected and then eject the entire physical CPU along with memory and IOH associated with the socket when the last core is ejected? It depends on the firmware implementation, but typically the answer is no. _EJ0 of a core object only removes the associated core object. It will require a separate socket hot-remove request to eject the socket-level resources. That is, the OS may not call _EJ0 of a socket object from the core hot-remove operation just because all children cores are removed. Thanks, -Toshi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
