[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2788e6e6-6916-5f95-51f5-336b8edaee2f@shipmail.org>
Date: Mon, 30 Sep 2019 19:38:31 +0200
From: Thomas Hellström (VMware)
<thomas_os@...pmail.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill@...temov.name>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux-MM <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add
write-protect and clean utilities for address space ranges
On 9/30/19 7:12 PM, Linus Torvalds wrote:
> On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov <kirill@...temov.name> wrote:
>> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
>> to cover cases when a THP is mapped with PTEs. To me it's not a big
>> stretch to make it cover multiple pages too.
> I agree that is closer, but it does make for calling that big complex
> function for every iteration step.
>
> Of course, you are right that the callback approach is problematic
> too, now that we have retpoline issues, making those very expensive.
> But at least that hopefully gets fixed some day and gets to be a rare
> problem.
>
> Matter ot taste, I guess.
>
> Linus
Matthew Wilcox suggested something similar before the pagewalk.c rewrite:
https://lore.kernel.org/lkml/20190806190937.GD30179@bombadil.infradead.org/
Still, In this case I'd opt for using the pagewalk code: In the dirty
helpers we don't ever use a struct page, but only deal with PTE entries,
same as the pagewalk code does, but not page_vma_mapped_walk(). The
underlying memory may well be IO memory.
/Thomas
Powered by blists - more mailing lists