From: Michal Hocko <mhocko@kernel.org> To: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: "Pasha Tatashin" <pavel.tatashin@microsoft.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, "Dave Hansen" <dave.hansen@intel.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Ingo Molnar" <mingo@kernel.org>, "Linux MM" <linux-mm@kvack.org>, "Jérôme Glisse" <jglisse@redhat.com>, rppt@linux.vnet.ibm.com, "Andrew Morton" <akpm@linux-foundation.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: Re: [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Date: Wed, 17 Oct 2018 09:52:57 +0200 [thread overview] Message-ID: <20181017075257.GF18839@dhcp22.suse.cz> (raw) In-Reply-To: <6f32f23c-c21c-9d42-7dda-a1d18613cd3c@linux.intel.com> On Thu 11-10-18 10:38:39, Alexander Duyck wrote: > On 10/11/2018 1:55 AM, Michal Hocko wrote: > > On Wed 10-10-18 20:52:42, Michal Hocko wrote: > > [...] > > > My recollection was that we do clear the reserved bit in > > > move_pfn_range_to_zone and we indeed do in __init_single_page. But then > > > we set the bit back right afterwards. This seems to be the case since > > > d0dc12e86b319 which reorganized the code. I have to study this some more > > > obviously. > > > > so my recollection was wrong and d0dc12e86b319 hasn't really changed > > much because __init_single_page wouldn't zero out the struct page for > > the hotplug contex. A comment in move_pfn_range_to_zone explains that we > > want the reserved bit because pfn walkers already do see the pfn range > > and the page is not fully associated with the zone until it is onlined. > > > > I am thinking that we might be overzealous here. With the full state > > initialized we shouldn't actually care. pfn_to_online_page should return > > NULL regardless of the reserved bit and normal pfn walkers shouldn't > > touch pages they do not recognize and a plain page with ref. count 1 > > doesn't tell much to anybody. So I _suspect_ that we can simply drop the > > reserved bit setting here. > > So this has me a bit hesitant to want to just drop the bit entirely. If > nothing else I think I may wan to make that a patch onto itself so that if > we aren't going to set it we just drop it there. That way if it does cause > issues we can bisect it to that patch and pinpoint the cause. Yes a patch on its own make sense for bisectability. > > Regarding the post initialization required by devm_memremap_pages and > > potentially others. Can we update the altmap which is already a way how > > to get alternative struct pages by a constructor which we could call > > from memmap_init_zone and do the post initialization? This would reduce > > the additional loop in the caller while it would still fit the overall > > design of the altmap and the core hotplug doesn't have to know anything > > about DAX or whatever needs a special treatment. > > > > Does that make any sense? > > I think the only thing that is currently using the altmap is the ZONE_DEVICE > memory init. Specifically I think it is only really used by the > devm_memremap_pages version of things, and then only under certain > circumstances. Also the HMM driver doesn't pass an altmap. What we would > really need is a non-ZONE_DEVICE users of the altmap to really justify > sticking with that as the preferred argument to pass. I am not aware of any upstream HMM user so I am not sure what are the expectations there. But I thought that ZONE_DEVICE users use altmap. If that is not generally true then we certainly have to think about a better interface. > For those two functions it currently makes much more sense to pass the > dev_pagemap pointer and then reference the altmap from there. Otherwise we > are likely starting to look at something that would be more of a dirty hack > where we are passing a unused altmap in order to get to the dev_pagemap so > that we could populate the page. If dev_pagemap is a general abstraction then I agree. -- Michal Hocko SUSE Labs _______________________________________________ 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: Michal Hocko <mhocko@kernel.org> To: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: "Dan Williams" <dan.j.williams@intel.com>, "Linux MM" <linux-mm@kvack.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-nvdimm <linux-nvdimm@lists.01.org>, "Pasha Tatashin" <pavel.tatashin@microsoft.com>, "Dave Hansen" <dave.hansen@intel.com>, "Jérôme Glisse" <jglisse@redhat.com>, rppt@linux.vnet.ibm.com, "Ingo Molnar" <mingo@kernel.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, yi.z.zhang@linux.intel.com Subject: Re: [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Date: Wed, 17 Oct 2018 09:52:57 +0200 [thread overview] Message-ID: <20181017075257.GF18839@dhcp22.suse.cz> (raw) In-Reply-To: <6f32f23c-c21c-9d42-7dda-a1d18613cd3c@linux.intel.com> On Thu 11-10-18 10:38:39, Alexander Duyck wrote: > On 10/11/2018 1:55 AM, Michal Hocko wrote: > > On Wed 10-10-18 20:52:42, Michal Hocko wrote: > > [...] > > > My recollection was that we do clear the reserved bit in > > > move_pfn_range_to_zone and we indeed do in __init_single_page. But then > > > we set the bit back right afterwards. This seems to be the case since > > > d0dc12e86b319 which reorganized the code. I have to study this some more > > > obviously. > > > > so my recollection was wrong and d0dc12e86b319 hasn't really changed > > much because __init_single_page wouldn't zero out the struct page for > > the hotplug contex. A comment in move_pfn_range_to_zone explains that we > > want the reserved bit because pfn walkers already do see the pfn range > > and the page is not fully associated with the zone until it is onlined. > > > > I am thinking that we might be overzealous here. With the full state > > initialized we shouldn't actually care. pfn_to_online_page should return > > NULL regardless of the reserved bit and normal pfn walkers shouldn't > > touch pages they do not recognize and a plain page with ref. count 1 > > doesn't tell much to anybody. So I _suspect_ that we can simply drop the > > reserved bit setting here. > > So this has me a bit hesitant to want to just drop the bit entirely. If > nothing else I think I may wan to make that a patch onto itself so that if > we aren't going to set it we just drop it there. That way if it does cause > issues we can bisect it to that patch and pinpoint the cause. Yes a patch on its own make sense for bisectability. > > Regarding the post initialization required by devm_memremap_pages and > > potentially others. Can we update the altmap which is already a way how > > to get alternative struct pages by a constructor which we could call > > from memmap_init_zone and do the post initialization? This would reduce > > the additional loop in the caller while it would still fit the overall > > design of the altmap and the core hotplug doesn't have to know anything > > about DAX or whatever needs a special treatment. > > > > Does that make any sense? > > I think the only thing that is currently using the altmap is the ZONE_DEVICE > memory init. Specifically I think it is only really used by the > devm_memremap_pages version of things, and then only under certain > circumstances. Also the HMM driver doesn't pass an altmap. What we would > really need is a non-ZONE_DEVICE users of the altmap to really justify > sticking with that as the preferred argument to pass. I am not aware of any upstream HMM user so I am not sure what are the expectations there. But I thought that ZONE_DEVICE users use altmap. If that is not generally true then we certainly have to think about a better interface. > For those two functions it currently makes much more sense to pass the > dev_pagemap pointer and then reference the altmap from there. Otherwise we > are likely starting to look at something that would be more of a dirty hack > where we are passing a unused altmap in order to get to the dev_pagemap so > that we could populate the page. If dev_pagemap is a general abstraction then I agree. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2018-10-17 7:52 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-25 20:18 [PATCH v5 0/4] Address issues slowing persistent memory initialization Alexander Duyck 2018-09-25 20:18 ` Alexander Duyck 2018-09-25 20:19 ` [PATCH v5 1/4] mm: Remove now defunct NO_BOOTMEM from depends list for deferred init Alexander Duyck 2018-09-25 20:19 ` Alexander Duyck 2018-09-25 21:05 ` Mike Rapoport 2018-09-25 21:05 ` Mike Rapoport 2018-09-25 20:20 ` [PATCH v5 2/4] mm: Provide kernel parameter to allow disabling page init poisoning Alexander Duyck 2018-09-25 20:20 ` Alexander Duyck 2018-09-25 20:26 ` Dave Hansen 2018-09-25 20:26 ` Dave Hansen 2018-09-25 20:38 ` Alexander Duyck 2018-09-25 20:38 ` Alexander Duyck 2018-09-25 22:14 ` Dave Hansen 2018-09-25 22:14 ` Dave Hansen 2018-09-25 22:14 ` Dave Hansen 2018-09-25 22:27 ` Alexander Duyck 2018-09-25 22:27 ` Alexander Duyck 2018-09-25 22:27 ` Alexander Duyck 2018-09-26 7:38 ` Michal Hocko 2018-09-26 7:38 ` Michal Hocko 2018-09-26 15:24 ` Alexander Duyck 2018-09-26 15:39 ` Michal Hocko 2018-09-26 15:39 ` Michal Hocko 2018-09-26 15:41 ` Dave Hansen 2018-09-26 15:41 ` Dave Hansen 2018-09-26 16:18 ` Alexander Duyck 2018-09-26 15:36 ` Dave Hansen 2018-09-26 22:36 ` Andrew Morton 2018-09-26 22:36 ` Andrew Morton 2018-09-25 20:20 ` [PATCH v5 3/4] mm: Create non-atomic version of SetPageReserved for init use Alexander Duyck 2018-09-25 20:20 ` Alexander Duyck 2018-09-25 20:21 ` [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Alexander Duyck 2018-09-25 20:21 ` Alexander Duyck 2018-09-26 7:55 ` Michal Hocko 2018-09-26 18:25 ` Alexander Duyck 2018-09-26 18:25 ` Alexander Duyck 2018-09-26 18:52 ` Dan Williams 2018-09-26 18:52 ` Dan Williams 2018-09-27 11:20 ` Michal Hocko 2018-09-27 11:20 ` Michal Hocko 2018-09-27 11:09 ` Michal Hocko 2018-09-27 11:09 ` Michal Hocko 2018-09-27 12:25 ` Oscar Salvador 2018-09-27 13:13 ` Michal Hocko 2018-09-27 14:50 ` Oscar Salvador 2018-09-27 14:50 ` Oscar Salvador 2018-09-27 14:50 ` Oscar Salvador 2018-09-27 15:41 ` David Hildenbrand 2018-09-27 15:41 ` David Hildenbrand 2018-09-28 8:12 ` Oscar Salvador 2018-09-28 8:12 ` Oscar Salvador 2018-09-28 8:44 ` Oscar Salvador 2018-09-28 8:44 ` Oscar Salvador 2018-09-28 15:50 ` Dan Williams 2018-09-28 15:50 ` Dan Williams 2018-09-27 12:32 ` Oscar Salvador 2018-10-08 21:01 ` Dan Williams 2018-10-08 21:01 ` Dan Williams 2018-10-08 21:38 ` Alexander Duyck 2018-10-08 21:38 ` Alexander Duyck 2018-10-08 22:00 ` Dan Williams 2018-10-08 22:00 ` Dan Williams 2018-10-08 22:00 ` Dan Williams 2018-10-08 22:07 ` Alexander Duyck 2018-10-08 22:07 ` Alexander Duyck 2018-10-08 22:36 ` Alexander Duyck 2018-10-08 22:36 ` Alexander Duyck 2018-10-08 22:59 ` Dan Williams 2018-10-08 23:34 ` [mm PATCH] memremap: Fix reference count for pgmap in devm_memremap_pages Alexander Duyck 2018-10-08 23:34 ` Alexander Duyck 2018-10-09 0:20 ` Dan Williams 2018-10-09 0:20 ` Dan Williams 2018-10-09 17:00 ` [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Yi Zhang 2018-10-09 17:00 ` Yi Zhang 2018-10-09 18:04 ` Dan Williams 2018-10-09 18:04 ` Dan Williams 2018-10-09 20:26 ` Alexander Duyck 2018-10-09 20:26 ` Alexander Duyck 2018-10-09 21:19 ` Dan Williams 2018-10-09 21:19 ` Dan Williams 2018-10-10 12:52 ` Yi Zhang 2018-10-10 12:52 ` Yi Zhang 2018-10-10 15:27 ` Alexander Duyck 2018-10-10 15:27 ` Alexander Duyck 2018-10-11 8:17 ` Yi Zhang 2018-10-11 8:17 ` Yi Zhang 2018-10-10 9:58 ` Michal Hocko 2018-10-10 16:39 ` Alexander Duyck 2018-10-10 16:39 ` Alexander Duyck 2018-10-10 17:24 ` Michal Hocko 2018-10-10 17:24 ` Michal Hocko 2018-10-10 17:39 ` Alexander Duyck 2018-10-10 17:39 ` Alexander Duyck 2018-10-10 17:53 ` Michal Hocko 2018-10-10 17:53 ` Michal Hocko 2018-10-10 18:13 ` Alexander Duyck 2018-10-10 18:13 ` Alexander Duyck 2018-10-10 18:52 ` Michal Hocko 2018-10-10 18:52 ` Michal Hocko 2018-10-11 8:55 ` Michal Hocko 2018-10-11 8:55 ` Michal Hocko 2018-10-11 17:38 ` Alexander Duyck 2018-10-11 18:22 ` Dan Williams 2018-10-11 18:22 ` Dan Williams 2018-10-17 7:52 ` Michal Hocko [this message] 2018-10-17 7:52 ` Michal Hocko 2018-10-17 15:02 ` Alexander Duyck 2018-10-17 15:02 ` Alexander Duyck 2018-10-29 14:12 ` Michal Hocko 2018-10-29 14:12 ` Michal Hocko 2018-10-29 15:59 ` Alexander Duyck 2018-10-29 15:59 ` Alexander Duyck 2018-10-29 15:59 ` Alexander Duyck 2018-10-29 16:35 ` Michal Hocko 2018-10-29 16:35 ` Michal Hocko 2018-10-29 17:01 ` Alexander Duyck 2018-10-29 17:24 ` Michal Hocko 2018-10-29 17:24 ` Michal Hocko 2018-10-29 17:34 ` Dan Williams 2018-10-29 17:34 ` Dan Williams 2018-10-29 17:45 ` Michal Hocko 2018-10-29 17:45 ` Michal Hocko 2018-10-29 17:42 ` Alexander Duyck 2018-10-29 17:42 ` Alexander Duyck 2018-10-29 18:18 ` Michal Hocko 2018-10-29 18:18 ` Michal Hocko 2018-10-29 19:59 ` Alexander Duyck 2018-10-29 19:59 ` Alexander Duyck 2018-10-30 6:29 ` Michal Hocko 2018-10-30 6:29 ` Michal Hocko 2018-10-30 6:55 ` Dan Williams 2018-10-30 8:17 ` Michal Hocko 2018-10-30 8:17 ` Michal Hocko 2018-10-30 15:57 ` Dan Williams 2018-10-30 8:05 ` Oscar Salvador 2018-10-29 15:49 ` Dan Williams 2018-10-29 15:49 ` Dan Williams 2018-10-29 15:56 ` Michal Hocko 2018-10-10 18:18 ` Dan Williams 2018-10-10 18:18 ` Dan Williams 2018-10-11 8:39 ` Yi Zhang 2018-10-11 8:39 ` Yi Zhang 2018-10-11 15:38 ` Alexander Duyck 2018-10-11 15:38 ` Alexander Duyck
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=20181017075257.GF18839@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=alexander.h.duyck@linux.intel.com \ --cc=dave.hansen@intel.com \ --cc=jglisse@redhat.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=mingo@kernel.org \ --cc=pavel.tatashin@microsoft.com \ --cc=rppt@linux.vnet.ibm.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: linkBe 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.