From: Dan Williams <email@example.com> To: Alexander Duyck <firstname.lastname@example.org> Cc: email@example.com, "Michal Hocko" <firstname.lastname@example.org>, linux-nvdimm <email@example.com>, "Dave Hansen" <firstname.lastname@example.org>, LKML <email@example.com>, linux-mm <firstname.lastname@example.org>, "Jérôme Glisse" <email@example.com>, "Andrew Morton" <firstname.lastname@example.org>, "Ingo Molnar" <email@example.com>, "Kirill A. Shutemov" <firstname.lastname@example.org> Subject: Re: [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Date: Tue, 11 Sep 2018 17:59:25 -0700 [thread overview] Message-ID: <CAPcyv4iiR3JgHg+Xyw-zON4+66stf917kUqNBxMFFLwT=H14qg@mail.gmail.com> (raw) In-Reply-To: <CAKgT0UdmkAXLdR6cfgmu-LcJUOO8a4qAS8zO3Bn+LwjJ9rT3pg@mail.gmail.com> On Tue, Sep 11, 2018 at 5:51 PM, Alexander Duyck <email@example.com> wrote: > On Tue, Sep 11, 2018 at 3:35 PM Dan Williams <firstname.lastname@example.org> wrote: >> >> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck >> <email@example.com> wrote: >> > >> > From: Alexander Duyck <firstname.lastname@example.org> >> > >> > The ZONE_DEVICE pages were being initialized in two locations. One was with >> > the memory_hotplug lock held and another was outside of that lock. The >> > problem with this is that it was nearly doubling the memory initialization >> > time. Instead of doing this twice, once while holding a global lock and >> > once without, I am opting to defer the initialization to the one outside of >> > the lock. This allows us to avoid serializing the overhead for memory init >> > and we can instead focus on per-node init times. >> > >> > One issue I encountered is that devm_memremap_pages and >> > hmm_devmmem_pages_create were initializing only the pgmap field the same >> > way. One wasn't initializing hmm_data, and the other was initializing it to >> > a poison value. Since this is something that is exposed to the driver in >> > the case of hmm I am opting for a third option and just initializing >> > hmm_data to 0 since this is going to be exposed to unknown third party >> > drivers. >> > >> > Signed-off-by: Alexander Duyck <email@example.com> >> > --- >> > include/linux/mm.h | 2 + >> > kernel/memremap.c | 24 +++++--------- >> > mm/hmm.c | 12 ++++--- >> > mm/page_alloc.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++- >> >> Hmm, why mm/page_alloc.c and not kernel/memremap.c for this new >> helper? I think that would address the kbuild reports and keeps all >> the devm_memremap_pages / ZONE_DEVICE special casing centralized. I >> also think it makes sense to move memremap.c to mm/ rather than >> kernel/ especially since commit 5981690ddb8f "memremap: split >> devm_memremap_pages() and memremap() infrastructure". Arguably, that >> commit should have went ahead with the directory move. > > The issue ends up being the fact that I would then have to start > exporting infrastructure such as __init_single_page from page_alloc. I > have some follow-up patches I am working on that will generate some > other shared functions that can be used by both memmap_init_zone and > memmap_init_zone_device, as well as pulling in some of the code from > the deferred memory init. You wouldn't need to export it, just make it public to mm/ in mm/internal.h, or a similar local header. With kernel/memremap.c moved to mm/memremap.c this becomes even easier and better scoped for the shared symbols. _______________________________________________ Linux-nvdimm mailing list Linuxfirstname.lastname@example.org https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-09-12 0:59 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-10 23:43 [PATCH 0/4] Address issues slowing persistent memory initialization Alexander Duyck 2018-09-10 23:43 ` [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Alexander Duyck 2018-09-11 0:35 ` Alexander Duyck 2018-09-11 16:50 ` Dan Williams 2018-09-11 20:01 ` Alexander Duyck 2018-09-11 20:24 ` Dan Williams 2018-09-12 13:24 ` Pasha Tatashin 2018-09-12 14:10 ` Michal Hocko 2018-09-12 14:49 ` Alexander Duyck 2018-09-12 15:23 ` Dave Hansen 2018-09-12 16:36 ` Alexander Duyck 2018-09-12 16:43 ` Dave Hansen 2018-09-10 23:43 ` [PATCH 2/4] mm: Create non-atomic version of SetPageReserved for init use Alexander Duyck 2018-09-12 13:28 ` Pasha Tatashin 2018-09-10 23:43 ` [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Alexander Duyck 2018-09-11 7:49 ` kbuild test robot 2018-09-11 7:54 ` kbuild test robot 2018-09-11 22:35 ` Dan Williams 2018-09-12 0:51 ` Alexander Duyck 2018-09-12 0:59 ` Dan Williams [this message] 2018-09-12 13:59 ` Pasha Tatashin 2018-09-12 15:48 ` Alexander Duyck 2018-09-12 15:54 ` Pasha Tatashin 2018-09-12 16:44 ` Alexander Duyck 2018-09-12 16:50 ` Dan Williams 2018-09-12 17:46 ` Pasha Tatashin 2018-09-12 19:11 ` Dan Williams 2018-09-10 23:44 ` [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device Alexander Duyck 2018-09-11 0:37 ` Alexander Duyck 2018-09-12 5:48 ` Dan Williams 2018-09-12 13:44 ` Pasha Tatashin
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='CAPcyv4iiR3JgHg+Xyw-zON4+66stf917kUqNBxMFFLwT=H14qg@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap' \ /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
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).