Re: [PATCH v4 07/14] device-dax: compound devmap support

On Fri, Nov 5, 2021 at 7:10 AM Joao Martins [off-list ref] wrote:

On 11/5/21 00:38, Dan Williams wrote:

quoted

On Fri, Aug 27, 2021 at 7:59 AM Joao Martins [off-list ref] wrote:

quoted

Use the newly added compound devmap facility which maps the assigned dax
ranges as compound pages at a page size of @align. Currently, this means,
that region/namespace bootstrap would take considerably less, given that
you would initialize considerably less pages.

On setups with 128G NVDIMMs the initialization with DRAM stored struct
pages improves from ~268-358 ms to ~78-100 ms with 2M pages, and to less
than a 1msec with 1G pages.

dax devices are created with a fixed @align (huge page size) which is
enforced through as well at mmap() of the device. Faults, consequently
happen too at the specified @align specified at the creation, and those
don't change through out dax device lifetime.

s/through out/throughout/

quoted

MCEs poisons a whole dax huge page, as well as splits occurring at the configured page size.

A clarification here, MCEs trigger memory_failure() to *unmap* a whole
dax huge page, the poison stays limited to a single cacheline.

Ah, yes. I'll fix it for v5.

quoted

Otherwise the patch looks good to me.

Thanks!

Btw, does 'looks good' == Reviewed-by (with the commit message clarification above) or is
it that 'should be good with the ammend above and you get the tag in the next round' ?

Reviewed-by: Dan Williams <redacted>

Asking as IIRC you mentioned this too some other time(s) (in the simpler sparse-vmemmap
patches) hence just clarifying to understand your expected 'process' better.

Also, I will be splitting this series as mentioned in the other discussion ...

https://lore.kernel.org/linux-mm/20211019160136.GH3686969@ziepe.ca/ (local)

... So this patch and the previous one should be the last two patches of the series
and the rest (gup, sparse-vmemmmap) will go in parallel.

Sounds good.