* [PATCH] ACPI: Add ACPI CPU hot-remove support
@ 2012-06-29 14:47 y
0 siblings, 0 replies; 15+ messages in thread
From: y @ 2012-06-29 14:47 UTC (permalink / raw)
To: lenb, linux-acpi; +Cc: linux-kernel, Toshi Kani
From: Toshi Kani <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 <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&m=134074381322973&w=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
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
[not found] ` <CAOEr4mpL952Z2iPuhfad+jhxUpOdHPRenEVmTUkU9LC8kKR29w@mail.gmail.com>
@ 2012-08-13 15:21 ` Toshi Kani
0 siblings, 0 replies; 15+ messages in thread
From: Toshi Kani @ 2012-08-13 15:21 UTC (permalink / raw)
To: Jiang Liu; +Cc: lenb, khalid.aziz, linux-acpi, linux-kernel
Hi Gerry, Khalid,
On Mon, 2012-07-09 at 02:40 +0000, 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.kani@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
>
>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-16 4:53 ` Pandarathil, Vijaymohan R
@ 2012-07-16 14:48 ` Toshi Kani
0 siblings, 0 replies; 15+ messages in thread
From: Toshi Kani @ 2012-07-16 14:48 UTC (permalink / raw)
To: Pandarathil, Vijaymohan R; +Cc: lenb, linux-acpi, linux-kernel
On Mon, 2012-07-16 at 04:53 +0000, 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<vijaymohan.pandarathil@hp.com>
Hi Vijay,
Great! Thanks for the testing!
-Toshi
>
>
> -----Original Message-----
> From: Kani, Toshimitsu
> Sent: Friday, June 29, 2012 7:51 AM
> To: lenb@kernel.org; linux-acpi@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.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&m=134074381322973&w=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,
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-06-29 14:51 Toshi Kani
2012-07-06 3:02 ` Yasuaki Ishimatsu
2012-07-06 16:27 ` Jiang Liu
@ 2012-07-16 4:53 ` Pandarathil, Vijaymohan R
2012-07-16 14:48 ` Toshi Kani
2 siblings, 1 reply; 15+ messages in thread
From: Pandarathil, Vijaymohan R @ 2012-07-16 4:53 UTC (permalink / raw)
To: Kani, Toshimitsu, lenb, linux-acpi; +Cc: linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3650 bytes --]
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<vijaymohan.pandarathil@hp.com>
-----Original Message-----
From: Kani, Toshimitsu
Sent: Friday, June 29, 2012 7:51 AM
To: lenb@kernel.org; linux-acpi@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.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&m=134074381322973&w=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
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-10 22:56 ` Khalid Aziz
@ 2012-07-10 23:30 ` Toshi Kani
0 siblings, 0 replies; 15+ messages in thread
From: Toshi Kani @ 2012-07-10 23:30 UTC (permalink / raw)
To: Khalid Aziz; +Cc: Jiang Liu, lenb, linux-acpi, linux-kernel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-06 21:00 ` Toshi Kani
@ 2012-07-10 22:56 ` Khalid Aziz
2012-07-10 23:30 ` Toshi Kani
[not found] ` <CAOEr4mpL952Z2iPuhfad+jhxUpOdHPRenEVmTUkU9LC8kKR29w@mail.gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: Khalid Aziz @ 2012-07-10 22:56 UTC (permalink / raw)
To: Toshi Kani; +Cc: Jiang Liu, lenb, linux-acpi, linux-kernel
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.aziz@hp.com>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-10 11:29 ` IgorMammedov
@ 2012-07-10 17:36 ` Toshi Kani
0 siblings, 0 replies; 15+ messages in thread
From: Toshi Kani @ 2012-07-10 17:36 UTC (permalink / raw)
To: IgorMammedov; +Cc: linux-kernel, lenb, linux-acpi
On Tue, 2012-07-10 at 11:29 +0000, 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-acpi&m=134074381322973&w=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 <imammedo@redhat.com>
Great! Thanks Igor for testing it!
-Toshi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
[not found] <16070.2632544146$1340981518@news.gmane.org>
@ 2012-07-10 11:29 ` IgorMammedov
2012-07-10 17:36 ` Toshi Kani
0 siblings, 1 reply; 15+ messages in thread
From: IgorMammedov @ 2012-07-10 11:29 UTC (permalink / raw)
To: linux-kernel
<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-acpi&m=134074381322973&w=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 <imammedo@redhat.com>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-06 20:09 ` Khalid Aziz
@ 2012-07-06 21:00 ` Toshi Kani
2012-07-10 22:56 ` Khalid Aziz
[not found] ` <CAOEr4mpL952Z2iPuhfad+jhxUpOdHPRenEVmTUkU9LC8kKR29w@mail.gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: Toshi Kani @ 2012-07-06 21:00 UTC (permalink / raw)
To: Khalid Aziz; +Cc: Jiang Liu, lenb, linux-acpi, linux-kernel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-06 19:13 ` Toshi Kani
@ 2012-07-06 20:09 ` Khalid Aziz
2012-07-06 21:00 ` Toshi Kani
0 siblings, 1 reply; 15+ messages in thread
From: Khalid Aziz @ 2012-07-06 20:09 UTC (permalink / raw)
To: Toshi Kani; +Cc: Jiang Liu, lenb, linux-acpi, linux-kernel
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-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-06 16:27 ` Jiang Liu
@ 2012-07-06 19:13 ` Toshi Kani
2012-07-06 20:09 ` Khalid Aziz
0 siblings, 1 reply; 15+ messages in thread
From: Toshi Kani @ 2012-07-06 19:13 UTC (permalink / raw)
To: Jiang Liu; +Cc: lenb, linux-acpi, linux-kernel
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.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&m=134074381322973&w=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-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-06-29 14:51 Toshi Kani
2012-07-06 3:02 ` Yasuaki Ishimatsu
@ 2012-07-06 16:27 ` Jiang Liu
2012-07-06 19:13 ` Toshi Kani
2012-07-16 4:53 ` Pandarathil, Vijaymohan R
2 siblings, 1 reply; 15+ messages in thread
From: Jiang Liu @ 2012-07-06 16:27 UTC (permalink / raw)
To: Toshi Kani; +Cc: lenb, linux-acpi, linux-kernel
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.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&m=134074381322973&w=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,
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-07-06 3:02 ` Yasuaki Ishimatsu
@ 2012-07-06 14:17 ` Toshi Kani
0 siblings, 0 replies; 15+ messages in thread
From: Toshi Kani @ 2012-07-06 14:17 UTC (permalink / raw)
To: Yasuaki Ishimatsu; +Cc: lenb, linux-acpi, linux-kernel
On Fri, 2012-07-06 at 12:02 +0900, Yasuaki Ishimatsu wrote:
> Hi Toshi,
>
> 2012/06/29 23:51, 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.kani@hp.com>
>
> Looks good to me.
>
> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Great! Thanks Yasuaki for reviewing!
-Toshi
> >
> > ---
> > 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&m=134074381322973&w=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-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] ACPI: Add ACPI CPU hot-remove support
2012-06-29 14:51 Toshi Kani
@ 2012-07-06 3:02 ` Yasuaki Ishimatsu
2012-07-06 14:17 ` Toshi Kani
2012-07-06 16:27 ` Jiang Liu
2012-07-16 4:53 ` Pandarathil, Vijaymohan R
2 siblings, 1 reply; 15+ messages in thread
From: Yasuaki Ishimatsu @ 2012-07-06 3:02 UTC (permalink / raw)
To: Toshi Kani; +Cc: lenb, linux-acpi, linux-kernel
Hi Toshi,
2012/06/29 23:51, 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.kani@hp.com>
Looks good to me.
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.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&m=134074381322973&w=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,
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] ACPI: Add ACPI CPU hot-remove support
@ 2012-06-29 14:51 Toshi Kani
2012-07-06 3:02 ` Yasuaki Ishimatsu
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Toshi Kani @ 2012-06-29 14:51 UTC (permalink / raw)
To: lenb, linux-acpi; +Cc: linux-kernel, Toshi Kani
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@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&m=134074381322973&w=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
^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-08-13 15:26 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-29 14:47 [PATCH] ACPI: Add ACPI CPU hot-remove support y
2012-06-29 14:51 Toshi Kani
2012-07-06 3:02 ` Yasuaki Ishimatsu
2012-07-06 14:17 ` Toshi Kani
2012-07-06 16:27 ` Jiang Liu
2012-07-06 19:13 ` Toshi Kani
2012-07-06 20:09 ` Khalid Aziz
2012-07-06 21:00 ` Toshi Kani
2012-07-10 22:56 ` Khalid Aziz
2012-07-10 23:30 ` Toshi Kani
[not found] ` <CAOEr4mpL952Z2iPuhfad+jhxUpOdHPRenEVmTUkU9LC8kKR29w@mail.gmail.com>
2012-08-13 15:21 ` Toshi Kani
2012-07-16 4:53 ` Pandarathil, Vijaymohan R
2012-07-16 14:48 ` Toshi Kani
[not found] <16070.2632544146$1340981518@news.gmane.org>
2012-07-10 11:29 ` IgorMammedov
2012-07-10 17:36 ` Toshi Kani
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).