enabled and failed flags in acpi_memory_info

enabled and failed flags in acpi_memory_info

[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

Re: enabled and failed flags in acpi_memory_info

[Toshi Kani]

Wen, Yasuaki, any thoughts on this?

Thanks,
-Toshi


On Tue, 2013-01-08 at 18:04 -0700, Toshi Kani wrote:
> 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

Re: enabled and failed flags in acpi_memory_info

[Wen Congyang]

Sorry for late reply.

At 01/15/2013 05:06 AM, Toshi Kani Wrote:
> Wen, Yasuaki, any thoughts on this?
> 
> Thanks,
> -Toshi
> 
> 
> On Tue, 2013-01-08 at 18:04 -0700, Toshi Kani wrote:
>> 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
>>
>> 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
> 
> 
> 

Re: enabled and failed flags in acpi_memory_info

[Toshi Kani]

On Wed, 2013-01-16 at 22:33 +0800, Wen Congyang wrote:
> Sorry for late reply.
> 
> At 01/15/2013 05:06 AM, Toshi Kani Wrote:
> > Wen, Yasuaki, any thoughts on this?
> > 
> > Thanks,
> > -Toshi
> > 
> > 
> > On Tue, 2013-01-08 at 18:04 -0700, Toshi Kani wrote:
> >> 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...

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.

> 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


> Thanks
> Wen Congyang
> >>
> >> 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
> > 
> > 
> > 
>