On 2/23/21 4:50 PM, Dan Williams wrote:

On Tue, Feb 23, 2021 at 7:46 AM Joao Martins [off-list ref] wrote:

quoted

On 2/22/21 8:37 PM, Dan Williams wrote:

quoted

On Mon, Feb 22, 2021 at 3:24 AM Joao Martins [off-list ref] wrote:

quoted

On 2/20/21 1:43 AM, Dan Williams wrote:

quoted

On Tue, Dec 8, 2020 at 9:59 PM John Hubbard [off-list ref] wrote:

quoted

On 12/8/20 9:28 AM, Joao Martins wrote:

[...]

quoted

quoted

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.