From: Wen Congyang <wency@cn.fujitsu.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: isimatu.yasuaki@jp.fujitsu.com, linux-acpi@vger.kernel.org
Subject: Re: enabled and failed flags in acpi_memory_info
Date: Wed, 16 Jan 2013 22:33:13 +0800 [thread overview]
Message-ID: <50F6BA29.9020201@cn.fujitsu.com> (raw)
In-Reply-To: <1358197617.14145.92.camel@misato.fc.hp.com>
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
>
>
>
next prev parent reply other threads:[~2013-01-16 14:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 1:04 enabled and failed flags in acpi_memory_info Toshi Kani
2013-01-14 21:06 ` Toshi Kani
2013-01-16 14:33 ` Wen Congyang [this message]
2013-01-16 17:09 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50F6BA29.9020201@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=toshi.kani@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.