From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Michal Hocko <mhocko@suse.com>, Linux MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm,memory_hotplug: Fix shrink_{zone,node}_span
Date: Wed, 17 Jul 2019 10:08:03 +0200 [thread overview]
Message-ID: <20190717080755.GA22661@linux> (raw)
In-Reply-To: <da07d964-fcfa-1406-bc12-faebbe38696e@redhat.com>
On Wed, Jul 17, 2019 at 10:01:01AM +0200, David Hildenbrand wrote:
> I'd also like to note that we should strive for making all zone-related
> changes when offlining in the future, not when removing memory. So
> ideally, any core changes we perform from now, should make that step
> (IOW implementing that) easier, not harder. Of course, BUGs have to be
> fixed.
>
> The rough idea would be to also mark ZONE_DEVICE sections as ONLINE (or
> rather rename it to "ACTIVE" to generalize).
>
> For each section we would then have
>
> - pfn_valid(): We have a valid "struct page" / memmap
> - pfn_present(): We have actually added that memory via an oficial
> interface to mm (e.g., arch_add_memory() )
> - pfn_online() / (or pfn_active()): Memory is active (online in "buddy"-
> speak, or memory that was moved to the ZONE_DEVICE zone)
>
> When resizing the zones (e.g., when offlining memory), we would then
> search for pfn_online(), not pfn_present().
>
> In addition to move_pfn_range_to_zone(), we would have
> remove_pfn_range_from_zone(), called during offline_pages() / by
> devmem/hmm/pmem code before removing.
>
> (I started to look into this, but I don't have any patches yet)
Yes, it seems like a good approach, and something that makes sense
to pursue.
FWIF, I sent a patchset [1] for that a long time ago, but I could not
follow-up due to time constraints.
[1] https://patchwork.kernel.org/cover/10700783/
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2019-07-17 8:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-15 8:15 [PATCH 0/2] Fixes for sub-section hotplug Oscar Salvador
2019-07-15 8:15 ` [PATCH 1/2] mm,sparse: Fix deactivate_section for early sections Oscar Salvador
2019-07-15 16:02 ` Aneesh Kumar K.V
2019-07-16 4:33 ` Dan Williams
2019-07-18 12:07 ` David Hildenbrand
2019-07-15 8:15 ` [PATCH 2/2] mm,memory_hotplug: Fix shrink_{zone,node}_span Oscar Salvador
2019-07-15 16:11 ` Aneesh Kumar K.V
2019-07-15 21:24 ` Oscar Salvador
2019-07-17 2:28 ` Dan Williams
2019-07-17 7:38 ` Oscar Salvador
2019-07-17 8:01 ` David Hildenbrand
2019-07-17 8:08 ` Oscar Salvador [this message]
2019-07-17 5:38 ` Aneesh Kumar K.V
2019-07-17 7:42 ` Oscar Salvador
2019-07-18 12:05 ` Oscar Salvador
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=20190717080755.GA22661@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pasha.tatashin@soleen.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.