linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).