From: Oscar Salvador <osalvador@suse.de>
To: Dan Williams <dan.j.williams@intel.com>, akpm@linux-foundation.org
Cc: Michal Hocko <mhocko@suse.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
David Hildenbrand <david@redhat.com>,
linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Qian Cai <cai@lca.pw>
Subject: Re: [PATCH v10 02/13] mm/sparsemem: Introduce a SECTION_IS_EARLY flag
Date: Mon, 24 Jun 2019 19:54:29 +0200 [thread overview]
Message-ID: <1561398869.3073.4.camel@suse.de> (raw)
In-Reply-To: <156092350358.979959.5817209875548072819.stgit@dwillia2-desk3.amr.corp.intel.com>
On Tue, 2019-06-18 at 22:51 -0700, Dan Williams wrote:
> In preparation for sub-section hotplug, track whether a given section
> was created during early memory initialization, or later via memory
> hotplug. This distinction is needed to maintain the coarse
> expectation
> that pfn_valid() returns true for any pfn within a given section even
> if
> that section has pages that are reserved from the page allocator.
>
> For example one of the of goals of subsection hotplug is to support
> cases where the system physical memory layout collides System RAM and
> PMEM within a section. Several pfn_valid() users expect to just check
> if
> a section is valid, but they are not careful to check if the given
> pfn
> is within a "System RAM" boundary and instead expect pgdat
> information
> to further validate the pfn.
>
> Rather than unwind those paths to make their pfn_valid() queries more
> precise a follow on patch uses the SECTION_IS_EARLY flag to maintain
> the
> traditional expectation that pfn_valid() returns true for all early
> sections.
>
> Link: https://lore.kernel.org/lkml/1560366952-10660-1-git-send-email-
> cai@lca.pw/
> Reported-by: Qian Cai <cai@lca.pw>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
[...]
> @@ -731,7 +732,7 @@ int __meminit sparse_add_one_section(int nid,
> unsigned long start_pfn,
> page_init_poison(memmap, sizeof(struct page) *
> PAGES_PER_SECTION);
>
> section_mark_present(ms);
> - sparse_init_one_section(ms, section_nr, memmap, usage);
> + sparse_init_one_section(ms, section_nr, memmap, usage, 0);
I think this is an improvment, and I really like the idea of leveraring
a new section's flag for this, but I have mixed feelings about the way
to mark a section as an early one.
IMHO, I think that a new "section_mark_early" function would be better
than passing a new flag parameter to sparse_init_one_section().
But I do not feel strong on this:
Reviewed-by: Oscar Salvador <osalvador@suse.de>
--
Oscar Salvador
SUSE L3
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Oscar Salvador <osalvador@suse.de>
To: Dan Williams <dan.j.williams@intel.com>, akpm@linux-foundation.org
Cc: Qian Cai <cai@lca.pw>, Michal Hocko <mhocko@suse.com>,
Logan Gunthorpe <logang@deltatee.com>,
David Hildenbrand <david@redhat.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-mm@kvack.org, linux-nvdimm@lists.01.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 02/13] mm/sparsemem: Introduce a SECTION_IS_EARLY flag
Date: Mon, 24 Jun 2019 19:54:29 +0200 [thread overview]
Message-ID: <1561398869.3073.4.camel@suse.de> (raw)
In-Reply-To: <156092350358.979959.5817209875548072819.stgit@dwillia2-desk3.amr.corp.intel.com>
On Tue, 2019-06-18 at 22:51 -0700, Dan Williams wrote:
> In preparation for sub-section hotplug, track whether a given section
> was created during early memory initialization, or later via memory
> hotplug. This distinction is needed to maintain the coarse
> expectation
> that pfn_valid() returns true for any pfn within a given section even
> if
> that section has pages that are reserved from the page allocator.
>
> For example one of the of goals of subsection hotplug is to support
> cases where the system physical memory layout collides System RAM and
> PMEM within a section. Several pfn_valid() users expect to just check
> if
> a section is valid, but they are not careful to check if the given
> pfn
> is within a "System RAM" boundary and instead expect pgdat
> information
> to further validate the pfn.
>
> Rather than unwind those paths to make their pfn_valid() queries more
> precise a follow on patch uses the SECTION_IS_EARLY flag to maintain
> the
> traditional expectation that pfn_valid() returns true for all early
> sections.
>
> Link: https://lore.kernel.org/lkml/1560366952-10660-1-git-send-email-
> cai@lca.pw/
> Reported-by: Qian Cai <cai@lca.pw>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
[...]
> @@ -731,7 +732,7 @@ int __meminit sparse_add_one_section(int nid,
> unsigned long start_pfn,
> page_init_poison(memmap, sizeof(struct page) *
> PAGES_PER_SECTION);
>
> section_mark_present(ms);
> - sparse_init_one_section(ms, section_nr, memmap, usage);
> + sparse_init_one_section(ms, section_nr, memmap, usage, 0);
I think this is an improvment, and I really like the idea of leveraring
a new section's flag for this, but I have mixed feelings about the way
to mark a section as an early one.
IMHO, I think that a new "section_mark_early" function would be better
than passing a new flag parameter to sparse_init_one_section().
But I do not feel strong on this:
Reviewed-by: Oscar Salvador <osalvador@suse.de>
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2019-06-24 17:54 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 5:51 [PATCH v10 00/13] mm: Sub-section memory hotplug support Dan Williams
2019-06-19 5:51 ` Dan Williams
2019-06-19 5:51 ` [PATCH v10 01/13] mm/sparsemem: Introduce struct mem_section_usage Dan Williams
2019-06-19 5:51 ` Dan Williams
2019-06-19 5:51 ` [PATCH v10 02/13] mm/sparsemem: Introduce a SECTION_IS_EARLY flag Dan Williams
2019-06-19 5:51 ` Dan Williams
2019-06-24 17:54 ` Oscar Salvador [this message]
2019-06-24 17:54 ` Oscar Salvador
2019-06-19 5:51 ` [PATCH v10 03/13] mm/sparsemem: Add helpers track active portions of a section at boot Dan Williams
2019-06-19 5:51 ` Dan Williams
2019-06-24 17:57 ` Oscar Salvador
2019-06-24 17:57 ` Oscar Salvador
2019-06-19 5:51 ` [PATCH v10 04/13] mm/hotplug: Prepare shrink_{zone, pgdat}_span for sub-section removal Dan Williams
2019-06-19 5:51 ` Dan Williams
2019-06-19 5:52 ` [PATCH v10 05/13] mm/sparsemem: Convert kmalloc_section_memmap() to populate_section_memmap() Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-24 18:00 ` Oscar Salvador
2019-06-24 18:00 ` Oscar Salvador
2019-06-19 5:52 ` [PATCH v10 06/13] mm/hotplug: Kill is_dev_zone() usage in __remove_pages() Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-19 5:52 ` [PATCH v10 07/13] mm: Kill is_dev_zone() helper Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-19 5:52 ` [PATCH v10 08/13] mm/sparsemem: Prepare for sub-section ranges Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-20 10:31 ` David Hildenbrand
2019-06-20 10:31 ` David Hildenbrand
2019-06-20 16:19 ` Dan Williams
2019-06-20 16:35 ` David Hildenbrand
2019-06-20 16:35 ` David Hildenbrand
2019-06-20 16:56 ` Dan Williams
2019-06-20 16:56 ` Dan Williams
2019-06-24 18:05 ` Oscar Salvador
2019-06-24 18:05 ` Oscar Salvador
2019-06-19 5:52 ` [PATCH v10 09/13] mm/sparsemem: Support sub-section hotplug Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-24 20:45 ` Oscar Salvador
2019-06-24 20:45 ` Oscar Salvador
2019-06-19 5:52 ` [PATCH v10 10/13] mm: Document ZONE_DEVICE memory-model implications Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-20 12:30 ` Mike Rapoport
2019-06-20 12:30 ` Mike Rapoport
2019-06-19 5:52 ` [PATCH v10 11/13] mm/devm_memremap_pages: Enable sub-section remap Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-19 5:52 ` [PATCH v10 12/13] libnvdimm/pfn: Fix fsdax-mode namespace info-block zero-fields Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-19 16:30 ` Aneesh Kumar K.V
2019-06-19 17:06 ` Dan Williams
2019-06-19 17:06 ` Dan Williams
2019-06-19 5:52 ` [PATCH v10 13/13] libnvdimm/pfn: Stop padding pmem namespaces to section alignment Dan Williams
2019-06-19 5:52 ` Dan Williams
2019-06-20 12:30 ` [PATCH v10 00/13] mm: Sub-section memory hotplug support Aneesh Kumar K.V
2019-06-20 12:30 ` Aneesh Kumar K.V
2019-06-20 16:30 ` Dan Williams
2019-06-20 16:30 ` Dan Williams
2019-06-20 17:00 ` Oscar Salvador
2019-06-20 17:00 ` 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=1561398869.3073.4.camel@suse.de \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.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.