public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hp.com>
To: wency@cn.fujitsu.com
Cc: isimatu.yasuaki@jp.fujitsu.com, linux-acpi@vger.kernel.org
Subject: enabled and failed flags in acpi_memory_info
Date: Tue, 08 Jan 2013 18:04:32 -0700	[thread overview]
Message-ID: <1357693472.14145.42.camel@misato.fc.hp.com> (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


             reply	other threads:[~2013-01-09  1:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09  1:04 Toshi Kani [this message]
2013-01-14 21:06 ` enabled and failed flags in acpi_memory_info Toshi Kani
2013-01-16 14:33   ` Wen Congyang
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=1357693472.14145.42.camel@misato.fc.hp.com \
    --to=toshi.kani@hp.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=wency@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox