enabled and failed flags in acpi_memory_info

DISCUSSION Toshi Kani 2 participants 4 messages Jan 9, 2013 – Jan 16, 2013 ACPI

Share & tools

Toshi Kani

author

2013-01-09 01:14 UTC #0 lore raw

Hi Wen,

I have a question about the change you made in commit 65479472 in acpi_memhotplug.c. This change seems to require that acpi_memory_enable_device() calls add_memory() to add all memory ranges represented by memory device objects at boot-time, and keep the results be used for hot-remove.

If I understand it right, this add_memory() call fails with EEXIST at boot-time since all memory ranges should have been added from EFI memory table (or e820) already. This results all memory ranges be marked as ! enabled & !failed. I think this means that we cannot hot-delete any memory ranges presented at boot-time since acpi_memory_remove_memory() only calls remove_memory() when the enabled flag is set. Is that correct? If so, why do we need such restriction?

In addition, as part of RFC patchset of proposed hotplug framework below (well, this is why I am wondering this... :), I simply called add_memory() and remove_memory() for the ranges requested for hot-add / hot-delete. It does not call add_memory() at boot-time and set the enabled & failed flags. But it does not eject memory when remove_memory() failed, either. Do you see any problems with this approach?
https://lkml.org/lkml/2012/12/12/457

Thanks,
-Toshi

Toshi Kani

author

2013-01-14 21:16 UTC #1 lore raw

Wen, Yasuaki, any thoughts on this?

Thanks,
-Toshi

Quoted 27 lines · Toshi Kani

Hi Wen,
I have a question about the change you made in commit 65479472 in acpi_memhotplug.c. This change seems to require that acpi_memory_enable_device() calls add_memory() to add all memory ranges represented by memory device objects at boot-time, and keep the results be used for hot-remove.
If I understand it right, this add_memory() call fails with EEXIST at boot-time since all memory ranges should have been added from EFI memory table (or e820) already. This results all memory ranges be marked as ! enabled & !failed. I think this means that we cannot hot-delete any memory ranges presented at boot-time since acpi_memory_remove_memory() only calls remove_memory() when the enabled flag is set. Is that correct? If so, why do we need such restriction?
In addition, as part of RFC patchset of proposed hotplug framework below (well, this is why I am wondering this... :), I simply called add_memory() and remove_memory() for the ranges requested for hot-add / hot-delete. It does not call add_memory() at boot-time and set the enabled & failed flags. But it does not eject memory when remove_memory() failed, either. Do you see any problems with this approach?
https://lkml.org/lkml/2012/12/12/457
Thanks,
-Toshi

Wen Congyang

2013-01-16 14:26 UTC #2 lore raw

Sorry for late reply.

At 01/15/2013 05:06 AM, Toshi Kani Wrote:

Quoted 22 lines

Wen, Yasuaki, any thoughts on this?
Thanks,
-Toshi
Quoted 15 lines · Toshi Kani
Hi Wen,
I have a question about the change you made in commit 65479472 in acpi_memhotplug.c. This change seems to require that acpi_memory_enable_device() calls add_memory() to add all memory ranges represented by memory device objects at boot-time, and keep the results be used for hot-remove.
If I understand it right, this add_memory() call fails with EEXIST at boot-time since all memory ranges should have been added from EFI memory table (or e820) already. This results all memory ranges be marked as ! enabled & !failed. I think this means that we cannot hot-delete any memory ranges presented at boot-time since acpi_memory_remove_memory() only calls remove_memory() when the enabled flag is set. Is that correct? If so, why do we need such restriction?t

Hmm, it means that this memory range is not managed by this driver. I am not sure it is safe to remove it, so I restrict it...

If it is safe to remove such memory, you can remove this restriction.

Thanks
Wen Congyang

Quoted 15 lines

Quoted 12 lines
In addition, as part of RFC patchset of proposed hotplug framework below (well, this is why I am wondering this... :), I simply called add_memory() and remove_memory() for the ranges requested for hot-add / hot-delete. It does not call add_memory() at boot-time and set the enabled & failed flags. But it does not eject memory when remove_memory() failed, either. Do you see any problems with this approach?
https://lkml.org/lkml/2012/12/12/457
Thanks,
-Toshi

Toshi Kani

author

2013-01-16 17:19 UTC #3 lore raw

Quoted 26 lines · Wen Congyang

Sorry for late reply.
At 01/15/2013 05:06 AM, Toshi Kani Wrote:
Quoted 22 lines
Wen, Yasuaki, any thoughts on this?
Thanks,
-Toshi
Quoted 15 lines · Toshi Kani
Hi Wen,
I have a question about the change you made in commit 65479472 in acpi_memhotplug.c. This change seems to require that acpi_memory_enable_device() calls add_memory() to add all memory ranges represented by memory device objects at boot-time, and keep the results be used for hot-remove.
If I understand it right, this add_memory() call fails with EEXIST at boot-time since all memory ranges should have been added from EFI memory table (or e820) already. This results all memory ranges be marked as ! enabled & !failed. I think this means that we cannot hot-delete any memory ranges presented at boot-time since acpi_memory_remove_memory() only calls remove_memory() when the enabled flag is set. Is that correct? If so, why do we need such restriction?t

Quoted 2 lines

Hmm, it means that this memory range is not managed by this driver. I am not sure it is safe to remove it, so I restrict it...

Well, let me clarify what I think the role model should be as follows.
- The ACPI memory driver enumerates memory device information and
maintains the "HW" information.
- The mm module manages the "OS use" of enumerated memory ranges.

Therefore, the ACPI memory driver should not attempt to manage how memory ranges are being used by the OS. It is solely the mm module's responsibility. Hence, it does not matter if the memory ranges managed by the mm module are initially enumerated from EFI (or e820) as long as the ACPI memory driver maintains the "current" HW info.

Quoted 1 line

If it is safe to remove such memory, you can remove this restriction.

It should be safe with the role model above. The ACPI memory driver receives a hot-plug request and updates its HW information. Then, the mm module decides if a given memory range can be added or deleted based on the memory usages.

If you see any issues in this model, please let me know. Thanks,
-Toshi

Quoted 18 lines

Thanks
Wen Congyang
Quoted 15 lines
Quoted 12 lines
In addition, as part of RFC patchset of proposed hotplug framework below (well, this is why I am wondering this... :), I simply called add_memory() and remove_memory() for the ranges requested for hot-add / hot-delete. It does not call add_memory() at boot-time and set the enabled & failed flags. But it does not eject memory when remove_memory() failed, either. Do you see any problems with this approach?
https://lkml.org/lkml/2012/12/12/457
Thanks,
-Toshi