From: Wen Congyang <[email protected]>
The patch-set implements a framework for hot removing memory.
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.
acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct . But
acpi_memory_device_remove() has not implemented it yet.
So the patch prepares the framework for hot removing memory and
adds the framework into acpi_memory_device_remove().
The last version of this patchset is here:
https://lkml.org/lkml/2012/10/3/126
Changelos from v1 to v2:
Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
Patch2: new patch, introduce a lock to protect the list
Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
Note: I don't send [Patch2-4 v1] in this series because they
are no logical changes in these 3 patches.
Wen Congyang (2):
acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
acpi,memory-hotplug: introduce a mutex lock to protect the list in
acpi_memory_device
Yasuaki Ishimatsu (1):
acpi,memory-hotplug : add memory offline code to
acpi_memory_device_remove()
drivers/acpi/acpi_memhotplug.c | 51 ++++++++++++++++++++++++++++++++--------
1 files changed, 41 insertions(+), 10 deletions(-)
From: Yasuaki Ishimatsu <[email protected]>
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.
acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct. But
acpi_memory_device_remove() has not implemented it yet.
So the patch move offlining memory and releasing acpi_memory_info struct
codes to a new function acpi_memory_remove_memory(). And it is used by both
acpi_memory_device_remove() and acpi_memory_disable_device().
CC: David Rientjes <[email protected]>
CC: Jiang Liu <[email protected]>
CC: Len Brown <[email protected]>
CC: Christoph Lameter <[email protected]>
Cc: Minchan Kim <[email protected]>
CC: Andrew Morton <[email protected]>
CC: KOSAKI Motohiro <[email protected]>
Signed-off-by: Yasuaki Ishimatsu <[email protected]>
Signed-off-by: Wen Congyang <[email protected]>
---
drivers/acpi/acpi_memhotplug.c | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 8ff2976..5b28aa9 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -316,16 +316,11 @@ static int acpi_memory_powerdown_device(struct acpi_memory_device *mem_device)
return 0;
}
-static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
{
int result;
struct acpi_memory_info *info, *n;
-
- /*
- * Ask the VM to offline this memory range.
- * Note: Assume that this function returns zero on success
- */
mutex_lock(&mem_device->lock);
list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
if (info->enabled) {
@@ -333,10 +328,27 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
if (result)
return result;
}
+
+ list_del(&info->list);
kfree(info);
}
mutex_unlock(&mem_device->lock);
+ return 0;
+}
+
+static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+{
+ int result;
+
+ /*
+ * Ask the VM to offline this memory range.
+ * Note: Assume that this function returns zero on success
+ */
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
+
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
if (result) {
@@ -487,12 +499,17 @@ static int acpi_memory_device_add(struct acpi_device *device)
static int acpi_memory_device_remove(struct acpi_device *device, int type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ int result;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
+
kfree(mem_device);
return 0;
--
1.7.1
From: Wen Congyang <[email protected]>
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
This 2 events may happen at the same time, so we may touch
acpi_memory_device.res_list at the same time. This patch
introduce a lock to protect this list.
CC: David Rientjes <[email protected]>
CC: Jiang Liu <[email protected]>
CC: Len Brown <[email protected]>
CC: Christoph Lameter <[email protected]>
Cc: Minchan Kim <[email protected]>
CC: Andrew Morton <[email protected]>
CC: KOSAKI Motohiro <[email protected]>
CC: Yasuaki Ishimatsu <[email protected]>
Signed-off-by: Wen Congyang <[email protected]>
---
drivers/acpi/acpi_memhotplug.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 1e90e8f..8ff2976 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -83,7 +83,8 @@ struct acpi_memory_info {
struct acpi_memory_device {
struct acpi_device * device;
unsigned int state; /* State of the memory device */
- struct list_head res_list;
+ struct mutex lock;
+ struct list_head res_list; /* protected by lock */
};
static int acpi_hotmem_initialized;
@@ -101,19 +102,23 @@ acpi_memory_get_resource(struct acpi_resource *resource, void *context)
(address64.resource_type != ACPI_MEMORY_RANGE))
return AE_OK;
+ mutex_lock(&mem_device->lock);
list_for_each_entry(info, &mem_device->res_list, list) {
/* Can we combine the resource range information? */
if ((info->caching == address64.info.mem.caching) &&
(info->write_protect == address64.info.mem.write_protect) &&
(info->start_addr + info->length == address64.minimum)) {
info->length += address64.address_length;
+ mutex_unlock(&mem_device->lock);
return AE_OK;
}
}
new = kzalloc(sizeof(struct acpi_memory_info), GFP_KERNEL);
- if (!new)
+ if (!new) {
+ mutex_unlock(&mem_device->lock);
return AE_ERROR;
+ }
INIT_LIST_HEAD(&new->list);
new->caching = address64.info.mem.caching;
@@ -121,6 +126,7 @@ acpi_memory_get_resource(struct acpi_resource *resource, void *context)
new->start_addr = address64.minimum;
new->length = address64.address_length;
list_add_tail(&new->list, &mem_device->res_list);
+ mutex_unlock(&mem_device->lock);
return AE_OK;
}
@@ -138,9 +144,11 @@ acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
status = acpi_walk_resources(mem_device->device->handle, METHOD_NAME__CRS,
acpi_memory_get_resource, mem_device);
if (ACPI_FAILURE(status)) {
+ mutex_lock(&mem_device->lock);
list_for_each_entry_safe(info, n, &mem_device->res_list, list)
kfree(info);
INIT_LIST_HEAD(&mem_device->res_list);
+ mutex_unlock(&mem_device->lock);
return -EINVAL;
}
@@ -236,6 +244,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
* We don't have memory-hot-add rollback function,now.
* (i.e. memory-hot-remove function)
*/
+ mutex_lock(&mem_device->lock);
list_for_each_entry(info, &mem_device->res_list, list) {
if (info->enabled) { /* just sanity check...*/
num_enabled++;
@@ -256,6 +265,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
info->enabled = 1;
num_enabled++;
}
+ mutex_unlock(&mem_device->lock);
if (!num_enabled) {
printk(KERN_ERR PREFIX "add_memory failed\n");
mem_device->state = MEMORY_INVALID_STATE;
@@ -316,6 +326,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
* Ask the VM to offline this memory range.
* Note: Assume that this function returns zero on success
*/
+ mutex_lock(&mem_device->lock);
list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
if (info->enabled) {
result = remove_memory(info->start_addr, info->length);
@@ -324,6 +335,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
}
kfree(info);
}
+ mutex_unlock(&mem_device->lock);
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
@@ -438,6 +450,7 @@ static int acpi_memory_device_add(struct acpi_device *device)
mem_device->device = device;
sprintf(acpi_device_name(device), "%s", ACPI_MEMORY_DEVICE_NAME);
sprintf(acpi_device_class(device), "%s", ACPI_MEMORY_DEVICE_CLASS);
+ mutex_init(&mem_device->lock);
device->driver_data = mem_device;
/* Get the range from the _CRS */
--
1.7.1
From: Wen Congyang <[email protected]>
The memory device has been ejected and powoffed, so we can call
acpi_bus_trim() to remove the memory device from acpi bus.
CC: David Rientjes <[email protected]>
CC: Jiang Liu <[email protected]>
CC: Len Brown <[email protected]>
CC: Benjamin Herrenschmidt <[email protected]>
CC: Paul Mackerras <[email protected]>
CC: Christoph Lameter <[email protected]>
Cc: Minchan Kim <[email protected]>
CC: Andrew Morton <[email protected]>
CC: KOSAKI Motohiro <[email protected]>
CC: Yasuaki Ishimatsu <[email protected]>
Signed-off-by: Wen Congyang <[email protected]>
---
drivers/acpi/acpi_memhotplug.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..1e90e8f 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -401,8 +401,9 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
}
/*
- * TBD: Invoke acpi_bus_remove to cleanup data structures
+ * Invoke acpi_bus_trim() to remove memory device
*/
+ acpi_bus_trim(device, 1);
/* _EJ0 succeeded; _OST is not necessary */
return;
--
1.7.1
CCing Rafael, because he become ACPI Maintainer.
Hi Wen,
If you update the patch-set, please CCing Rafael from the next time.
Thanks,
Yasuaki Ishimatsu
2012/10/19 19:03, [email protected] wrote:
> From: Wen Congyang <[email protected]>
>
> The patch-set implements a framework for hot removing memory.
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> In the 1st case, acpi_memory_disable_device() will be called.
> In the 2nd case, acpi_memory_device_remove() will be called.
> acpi_memory_device_remove() will also be called when we unbind the
> memory device from the driver acpi_memhotplug or a driver initialization
> fails.
>
> acpi_memory_disable_device() has already implemented a code which
> offlines memory and releases acpi_memory_info struct . But
> acpi_memory_device_remove() has not implemented it yet.
>
> So the patch prepares the framework for hot removing memory and
> adds the framework into acpi_memory_device_remove().
>
> The last version of this patchset is here:
> https://lkml.org/lkml/2012/10/3/126
>
> Changelos from v1 to v2:
> Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
> Patch2: new patch, introduce a lock to protect the list
> Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
> Note: I don't send [Patch2-4 v1] in this series because they
> are no logical changes in these 3 patches.
>
> Wen Congyang (2):
> acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
> acpi,memory-hotplug: introduce a mutex lock to protect the list in
> acpi_memory_device
>
> Yasuaki Ishimatsu (1):
> acpi,memory-hotplug : add memory offline code to
> acpi_memory_device_remove()
>
> drivers/acpi/acpi_memhotplug.c | 51 ++++++++++++++++++++++++++++++++--------
> 1 files changed, 41 insertions(+), 10 deletions(-)
>
At 10/19/2012 06:19 PM, Yasuaki Ishimatsu Wrote:
> CCing Rafael, because he become ACPI Maintainer.
>
> Hi Wen,
>
> If you update the patch-set, please CCing Rafael from the next time.
OK.
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
> 2012/10/19 19:03, [email protected] wrote:
>> From: Wen Congyang <[email protected]>
>>
>> The patch-set implements a framework for hot removing memory.
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug or a driver initialization
>> fails.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch prepares the framework for hot removing memory and
>> adds the framework into acpi_memory_device_remove().
>>
>> The last version of this patchset is here:
>> https://lkml.org/lkml/2012/10/3/126
>>
>> Changelos from v1 to v2:
>> Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>> Patch2: new patch, introduce a lock to protect the list
>> Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>> Note: I don't send [Patch2-4 v1] in this series because they
>> are no logical changes in these 3 patches.
>>
>> Wen Congyang (2):
>> acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>> acpi,memory-hotplug: introduce a mutex lock to protect the list in
>> acpi_memory_device
>>
>> Yasuaki Ishimatsu (1):
>> acpi,memory-hotplug : add memory offline code to
>> acpi_memory_device_remove()
>>
>> drivers/acpi/acpi_memhotplug.c | 51 ++++++++++++++++++++++++++++++++--------
>> 1 files changed, 41 insertions(+), 10 deletions(-)
>>
>
>
>
On Friday 19 of October 2012 18:03:57 [email protected] wrote:
> From: Wen Congyang <[email protected]>
>
> The patch-set implements a framework for hot removing memory.
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> In the 1st case, acpi_memory_disable_device() will be called.
> In the 2nd case, acpi_memory_device_remove() will be called.
> acpi_memory_device_remove() will also be called when we unbind the
> memory device from the driver acpi_memhotplug or a driver initialization
> fails.
>
> acpi_memory_disable_device() has already implemented a code which
> offlines memory and releases acpi_memory_info struct . But
> acpi_memory_device_remove() has not implemented it yet.
>
> So the patch prepares the framework for hot removing memory and
> adds the framework into acpi_memory_device_remove().
>
> The last version of this patchset is here:
> https://lkml.org/lkml/2012/10/3/126
>
> Changelos from v1 to v2:
> Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
> Patch2: new patch, introduce a lock to protect the list
> Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
> Note: I don't send [Patch2-4 v1] in this series because they
> are no logical changes in these 3 patches.
>
> Wen Congyang (2):
> acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
> acpi,memory-hotplug: introduce a mutex lock to protect the list in
> acpi_memory_device
>
> Yasuaki Ishimatsu (1):
> acpi,memory-hotplug : add memory offline code to
> acpi_memory_device_remove()
>
> drivers/acpi/acpi_memhotplug.c | 51 ++++++++++++++++++++++++++++++++--------
> 1 files changed, 41 insertions(+), 10 deletions(-)
>
> --
Can you please tell me what kernel is the series supposed to apply to?
Is it the current Linus' tree, or linux-next, or something else?
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Fri, Oct 19, 2012 at 6:03 AM, <[email protected]> wrote:
> From: Wen Congyang <[email protected]>
>
> The memory device has been ejected and powoffed, so we can call
> acpi_bus_trim() to remove the memory device from acpi bus.
>
> CC: David Rientjes <[email protected]>
> CC: Jiang Liu <[email protected]>
> CC: Len Brown <[email protected]>
> CC: Benjamin Herrenschmidt <[email protected]>
> CC: Paul Mackerras <[email protected]>
> CC: Christoph Lameter <[email protected]>
> Cc: Minchan Kim <[email protected]>
> CC: Andrew Morton <[email protected]>
> CC: KOSAKI Motohiro <[email protected]>
> CC: Yasuaki Ishimatsu <[email protected]>
> Signed-off-by: Wen Congyang <[email protected]>
> ---
> drivers/acpi/acpi_memhotplug.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24c807f..1e90e8f 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -401,8 +401,9 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
> }
>
> /*
> - * TBD: Invoke acpi_bus_remove to cleanup data structures
> + * Invoke acpi_bus_trim() to remove memory device
> */
> + acpi_bus_trim(device, 1);
I'm happy we removed mysterious acpi_bus_remove().
On Fri, Oct 19, 2012 at 6:03 AM, <[email protected]> wrote:
> From: Wen Congyang <[email protected]>
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> This 2 events may happen at the same time, so we may touch
> acpi_memory_device.res_list at the same time. This patch
> introduce a lock to protect this list.
>
> CC: David Rientjes <[email protected]>
> CC: Jiang Liu <[email protected]>
> CC: Len Brown <[email protected]>
> CC: Christoph Lameter <[email protected]>
> Cc: Minchan Kim <[email protected]>
> CC: Andrew Morton <[email protected]>
> CC: KOSAKI Motohiro <[email protected]>
> CC: Yasuaki Ishimatsu <[email protected]>
> Signed-off-by: Wen Congyang <[email protected]>
> ---
> drivers/acpi/acpi_memhotplug.c | 17 +++++++++++++++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 1e90e8f..8ff2976 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -83,7 +83,8 @@ struct acpi_memory_info {
> struct acpi_memory_device {
> struct acpi_device * device;
> unsigned int state; /* State of the memory device */
> - struct list_head res_list;
> + struct mutex lock;
> + struct list_head res_list; /* protected by lock */
> };
Please avoid grep unfriendly name. "lock" is too common. res_list_lock
or list_lock
are better IMHO.
At 10/20/2012 12:32 AM, Rafael J. Wysocki Wrote:
> On Friday 19 of October 2012 18:03:57 [email protected] wrote:
>> From: Wen Congyang <[email protected]>
>>
>> The patch-set implements a framework for hot removing memory.
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug or a driver initialization
>> fails.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch prepares the framework for hot removing memory and
>> adds the framework into acpi_memory_device_remove().
>>
>> The last version of this patchset is here:
>> https://lkml.org/lkml/2012/10/3/126
>>
>> Changelos from v1 to v2:
>> Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>> Patch2: new patch, introduce a lock to protect the list
>> Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>> Note: I don't send [Patch2-4 v1] in this series because they
>> are no logical changes in these 3 patches.
>>
>> Wen Congyang (2):
>> acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>> acpi,memory-hotplug: introduce a mutex lock to protect the list in
>> acpi_memory_device
>>
>> Yasuaki Ishimatsu (1):
>> acpi,memory-hotplug : add memory offline code to
>> acpi_memory_device_remove()
>>
>> drivers/acpi/acpi_memhotplug.c | 51 ++++++++++++++++++++++++++++++++--------
>> 1 files changed, 41 insertions(+), 10 deletions(-)
>>
>> --
>
> Can you please tell me what kernel is the series supposed to apply to?
> Is it the current Linus' tree, or linux-next, or something else?
Current Linux's tree.
Thanks
Wen Congyang
>
> Thanks,
> Rafael
>
>