Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting

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

 



On Mon, Dec 14, 2020 at 8:07 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
>
> Here it is. Still barely tested.

Ok, from looking at the patch (not applying it and looking at the end
result), I think the locking - at least for the filemap_map_pages()
case - is a lot easier to understand.

So you seem to have fixed the thing I personally found most confusing. Thanks.

> I expected to hate it more, but it looks reasonable. Opencoded
> xas_for_each() smells bad, but...

I think the open-coded xas_for_each() per se isn't a problem, but I
agree that the startup condition is a bit ugly. And I'm actually
personally more confused by why xas_retry() is needed here, bit not in
many other places. That is perhaps more obvious now that it shows up
twice.

Adding Willy to the cc in case he has comments on that, and can
explain it to me in small words.

[ https://lore.kernel.org/lkml/20201214160724.ewhjqoi32chheone@box/
for context ]

And I actually think it might make even more sense if you moved more
of the pmd handling into "filemap_map_pages_pmd()".

Now it's a bit odd, with filemap_map_pages() containing part of the
pmd handling, and then part being in filemap_map_pages_pmd().

Could we have a "filemap_map_pmd()" that does it all, and then the
filemap_map_pages() logic would be more along the lines of

    if (filemap_map_pmd(vmf, xas)) {
            rcu_read_unlock();
            return;
    }

    ... then handle pte's ...

Hmm?

There may be some shared state thing why you didn't do it, the above
is mostly a syntactic issue.

Thanks,

              Linus




[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