All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Oscar Salvador <osalvador@suse.de>, Qian Cai <cai@lca.pw>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jmoyer <jmoyer@redhat.com>
Subject: Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page()
Date: Sun, 16 Jun 2019 09:19:42 +0530	[thread overview]
Message-ID: <87imt6i3zd.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4j_QQB8SrhTqL2mnEEHGYCg4H7kYanChiww35k0fwNv8Q@mail.gmail.com>

Dan Williams <dan.j.williams@intel.com> writes:

> On Fri, Jun 14, 2019 at 9:18 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> On 6/14/19 9:05 PM, Oscar Salvador wrote:
>> > On Fri, Jun 14, 2019 at 02:28:40PM +0530, Aneesh Kumar K.V wrote:
>> >> Can you check with this change on ppc64.  I haven't reviewed this series yet.
>> >> I did limited testing with change . Before merging this I need to go
>> >> through the full series again. The vmemmap poplulate on ppc64 needs to
>> >> handle two translation mode (hash and radix). With respect to vmemap
>> >> hash doesn't setup a translation in the linux page table. Hence we need
>> >> to make sure we don't try to setup a mapping for a range which is
>> >> arleady convered by an existing mapping.
>> >>
>> >> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
>> >> index a4e17a979e45..15c342f0a543 100644
>> >> --- a/arch/powerpc/mm/init_64.c
>> >> +++ b/arch/powerpc/mm/init_64.c
>> >> @@ -88,16 +88,23 @@ static unsigned long __meminit vmemmap_section_start(unsigned long page)
>> >>    * which overlaps this vmemmap page is initialised then this page is
>> >>    * initialised already.
>> >>    */
>> >> -static int __meminit vmemmap_populated(unsigned long start, int page_size)
>> >> +static bool __meminit vmemmap_populated(unsigned long start, int page_size)
>> >>   {
>> >>      unsigned long end = start + page_size;
>> >>      start = (unsigned long)(pfn_to_page(vmemmap_section_start(start)));
>> >>
>> >> -    for (; start < end; start += (PAGES_PER_SECTION * sizeof(struct page)))
>> >> -            if (pfn_valid(page_to_pfn((struct page *)start)))
>> >> -                    return 1;
>> >> +    for (; start < end; start += (PAGES_PER_SECTION * sizeof(struct page))) {
>> >>
>> >> -    return 0;
>> >> +            struct mem_section *ms;
>> >> +            unsigned long pfn = page_to_pfn((struct page *)start);
>> >> +
>> >> +            if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>> >> +                    return 0;
>> >
>> > I might be missing something, but is this right?
>> > Having a section_nr above NR_MEM_SECTIONS is invalid, but if we return 0 here,
>> > vmemmap_populate will go on and populate it.
>>
>> I should drop that completely. We should not hit that condition at all.
>> I will send a final patch once I go through the full patch series making
>> sure we are not breaking any ppc64 details.
>>
>> Wondering why we did the below
>>
>> #if defined(ARCH_SUBSECTION_SHIFT)
>> #define SUBSECTION_SHIFT (ARCH_SUBSECTION_SHIFT)
>> #elif defined(PMD_SHIFT)
>> #define SUBSECTION_SHIFT (PMD_SHIFT)
>> #else
>> /*
>>   * Memory hotplug enabled platforms avoid this default because they
>>   * either define ARCH_SUBSECTION_SHIFT, or PMD_SHIFT is a constant, but
>>   * this is kept as a backstop to allow compilation on
>>   * !ARCH_ENABLE_MEMORY_HOTPLUG archs.
>>   */
>> #define SUBSECTION_SHIFT 21
>> #endif
>>
>> why not
>>
>> #if defined(ARCH_SUBSECTION_SHIFT)
>> #define SUBSECTION_SHIFT (ARCH_SUBSECTION_SHIFT)
>> #else
>> #define SUBSECTION_SHIFT  SECTION_SHIFT
>> #endif
>>
>> ie, if SUBSECTION is not supported by arch we have one sub-section per
>> section?
>
> A couple comments:
>
> The only reason ARCH_SUBSECTION_SHIFT exists is because PMD_SHIFT on
> PowerPC was a non-constant value. However, I'm planning to remove the
> distinction in the next rev of the patches. Jeff rightly points out
> that having a variable subsection size per arch will lead to
> situations where persistent memory namespaces are not portable across
> archs. So I plan to just make SUBSECTION_SHIFT 21 everywhere.

What is the dependency between subsection and pageblock_order? Shouldn't
subsection size >= pageblock size?

We do have pageblock size drived from HugeTLB size.

-aneesh


  parent reply	other threads:[~2019-06-16  3:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-12 19:15 [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page() Qian Cai
2019-06-12 19:37 ` Dan Williams
2019-06-12 19:38   ` Dan Williams
2019-06-12 21:47     ` Qian Cai
2019-06-12 21:52       ` Dan Williams
2019-06-12 23:13         ` Dan Williams
2019-06-13  0:06       ` Dan Williams
2019-06-14  8:58       ` Aneesh Kumar K.V
2019-06-14 14:59         ` Qian Cai
2019-06-14 18:03           ` Dan Williams
2019-06-14 18:57             ` Dan Williams
2019-06-14 19:40               ` Qian Cai
2019-06-14 19:48                 ` Dan Williams
2019-06-14 20:43                   ` Qian Cai
2019-06-16 15:42                     ` Dan Williams
2019-06-17  2:25                       ` Qian Cai
2019-06-14 15:35         ` Oscar Salvador
2019-06-14 16:18           ` Aneesh Kumar K.V
2019-06-14 16:22             ` Dan Williams
2019-06-14 16:26               ` Aneesh Kumar K.V
2019-06-14 16:36                 ` Dan Williams
2019-06-14 16:36                   ` Dan Williams
2019-06-14 16:50                   ` Aneesh Kumar K.V
2019-06-14 16:55                   ` Aneesh Kumar K.V
2019-06-14 17:08                     ` Jeff Moyer
2019-06-14 17:08                       ` Jeff Moyer
2019-06-14 17:14                       ` Dan Williams
2019-06-14 17:14                         ` Dan Williams
2019-06-14 17:40                       ` Aneesh Kumar K.V
2019-06-16  3:49               ` Aneesh Kumar K.V [this message]
2019-06-17 17:21                 ` Dan Williams
2019-06-13 18:42   ` Qian Cai
2019-06-14  1:17     ` Dan Williams
2019-06-14  1:29       ` Qian Cai

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=87imt6i3zd.fsf@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=cai@lca.pw \
    --cc=dan.j.williams@intel.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    /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.