On 2/23/21 4:50 PM, Dan Williams wrote: > On Tue, Feb 23, 2021 at 7:46 AM Joao Martins <joao.m.mart...@oracle.com> > wrote: >> On 2/22/21 8:37 PM, Dan Williams wrote: >>> On Mon, Feb 22, 2021 at 3:24 AM Joao Martins <joao.m.mart...@oracle.com> >>> wrote: >>>> On 2/20/21 1:43 AM, Dan Williams wrote: >>>>> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard <jhubb...@nvidia.com> wrote: >>>>>> On 12/8/20 9:28 AM, Joao Martins wrote:
[...] >>> Don't get me wrong the >>> capability is still needed for filesystem-dax, but the distinction is >>> that vmemmap_populate_compound_pages() need never worry about an >>> altmap. >>> >> IMO there's not much added complexity strictly speaking about altmap. We >> still use the >> same vmemmap_{pmd,pte,pgd}_populate helpers which just pass an altmap. So >> whatever it is >> being maintained for fsdax or other altmap consumers (e.g. we seem to be >> working towards >> hotplug making use of it) we are using it in the exact same way. >> >> The complexity of the future vmemmap_populate_compound_pages() has more to >> do with reusing >> vmemmap blocks allocated in previous vmemmap pages, and preserving that >> across section >> onlining (for 1G pages). > > True, I'm less worried about the complexity as much as > opportunistically converting configurations to RAM backed pages. It's > already the case that poison handling is page mapping size aligned for > device-dax, and filesystem-dax needs to stick with non-compound-pages > for the foreseeable future. > Hmm, I was sort off wondering that fsdax could move to compound pages too as opposed to base pages, albeit not necessarily using the vmemmap page reuse as it splits pages IIUC. > Ok, let's try to keep altmap in vmemmap_populate_compound_pages() and > see how it looks. > OK, will do. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org