On 11/5/21 00:38, Dan Williams wrote: > On Fri, Aug 27, 2021 at 7:59 AM Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: >> >> 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/ > >> 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. > 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' ? 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@xxxxxxxx/ ... 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.
