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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 5, 2021 at 7:10 AM Joao Martins <joao.m.martins@xxxxxxxxxx> wrote:
>
> 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' ?

Reviewed-by: Dan Williams <dan.j.williams@xxxxxxxxx>

> 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.

Sounds good.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux