[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B39368D9-7E5D-4864-819C-CDEEAB4BD92D@gmail.com>
Date: Sat, 29 Oct 2022 13:56:31 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: John Hubbard <jhubbard@...dia.com>,
Peter Zijlstra <peterz@...radead.org>,
Jann Horn <jannh@...gle.com>, X86 ML <x86@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
kernel list <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
jroedel@...e.de, ubizjak@...il.com,
Alistair Popple <apopple@...dia.com>
Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment
On Oct 29, 2022, at 1:15 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> (b) we could move the "page_remove_rmap()" into the "flush-and-free" path too
>
> And (b) would be fairly easy - same model as that dirty bit patch,
> just a 'do page_remove_rmap too' - except page_remove_rmap() wants the
> vma as well (and we delay the TLB flush over multiple vma's, so it's
> not just a "save vma in mmu_gather”).
(b) sounds reasonable and may potentially allow future performance
improvements (batching, doing stuff without locks).
It does appear to break a potential hidden assumption that rmap is removed
while the ptl is acquired (at least in the several instances I samples).
Yet, anyhow page_vma_mapped_walk() checks the PTE before calling the
function, so it should be fine.
I’ll give it a try.
Powered by blists - more mailing lists