From: Andrea Reale <ar@linux.vnet.ibm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Scott Branden <scott.branden@broadcom.com>,
Maciej Bielski <m.bielski@virtualopensystems.com>,
will.deacon@arm.com, linux-arm-kernel@lists.infradead.org,
qiuxishi@huawei.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] Memory hotplug support for arm64 platform
Date: Fri, 31 Mar 2017 15:16:04 +0100 [thread overview]
Message-ID: <20170331141603.GA1440@samekh> (raw)
In-Reply-To: <ef53951f-ff03-91d2-506a-c5eccb6512b4@gmail.com>
Hi Florian,
thanks for your message. Please, find the replies in-line.
On Wed, Mar 29, 2017 at 05:40:02PM -0700, Florian Fainelli wrote:
> While the "hack" that sets/clears NOMAP in order for pfn_valid() to
> return false/true when appropriate during __add_pages() definitively
> does seem to work to probe the memory section, don't you also hit the
> same warning when you try to online that memory section in
> pages_correctly_reserved() once you have cleared the NOMAP flag?
Before arch_add_memory returns, we clear the nomap flag on the blocks,
so that pfn_valid will return true when executing on the corresponding
pages. This means that the condition in pages_correctly_reserved in
drivers/base/memory.c:
if (WARN_ON_ONCE(!pfn_valid(pfn)))
will evaluate to false, so no warning should be issued, and the function
should continue to execute as expected.
Is it that you were referring to or did I miss the point?
> I will definitively give this a try on ARM64 since I need to get it
> working there.
Thanks a lot, any help in testing is really appreciated.
> Do you mind posting a non-RFC patch?
We should release the hot-remove code that myself and Maciej have been
working on very soon (say, around one week); the plan is to rebase
everything and release hot-add and hot-remove as a single patch series
(including Scott's original patches and our hot-add patches). If you
can wait until then, we will probably minimize entropy; otherwise we
can also re-post the hot-add patches earlier and separately.
Thanks and regards,
Andrea
prev parent reply other threads:[~2017-03-31 14:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 12:16 [RFC PATCH] Memory hotplug support for arm64 platform Maciej Bielski
2016-12-15 6:18 ` Xishi Qiu
2016-12-15 6:40 ` Xishi Qiu
2016-12-15 18:31 ` Andrea Reale
2016-12-16 1:31 ` Xishi Qiu
2016-12-20 19:12 ` Scott Branden
2016-12-21 9:44 ` Maciej Bielski
2016-12-22 1:20 ` Scott Branden
2017-02-06 11:17 ` Andrea Reale
2017-02-08 20:08 ` Scott Branden
2017-03-30 0:40 ` Florian Fainelli
2017-03-31 14:16 ` Andrea Reale [this message]
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=20170331141603.GA1440@samekh \
--to=ar@linux.vnet.ibm.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.bielski@virtualopensystems.com \
--cc=qiuxishi@huawei.com \
--cc=scott.branden@broadcom.com \
--cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).