[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2SyJuohLFLqIhlZ@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com>
Date: Fri, 4 Nov 2022 07:33:10 +0100
From: Alexander Gordeev <agordeev@...ux.ibm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Aneesh Kumar <aneesh.kumar@...ux.ibm.com>,
Nick Piggin <npiggin@...il.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Nadav Amit <nadav.amit@...il.com>,
Jann Horn <jannh@...gle.com>,
John Hubbard <jhubbard@...dia.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>,
Joerg Roedel <jroedel@...e.de>,
Uros Bizjak <ubizjak@...il.com>,
Alistair Popple <apopple@...dia.com>,
linux-arch <linux-arch@...r.kernel.org>
Subject: Re: mm: delay rmap removal until after TLB flush
On Mon, Oct 31, 2022 at 11:43:30AM -0700, Linus Torvalds wrote:
[...]
> If people really want to see the patches in email again, I can do
> that, but most of you already have, and the changes are either trivial
> fixes or the s390 updates.
>
> For the s390 people that I've now added to the participant list maybe
> the git tree is fine - and the fundamental explanation of the problem
> is in that top-most commit (with the three preceding commits being
> prep-work). Or that link to the thread about this all.
I rather have a question to the generic part (had to master the code quotting).
> static void clean_and_free_pages_and_swap_cache(struct encoded_page **pages, unsigned int nr)
> {
> for (unsigned int i = 0; i < nr; i++) {
> struct encoded_page *encoded = pages[i];
> unsigned int flags = encoded_page_flags(encoded);
> if (flags) {
> /* Clean the flagged pointer in-place */
> struct page *page = encoded_page_ptr(encoded);
> pages[i] = encode_page(page, 0);
>
> /* The flag bit being set means that we should zap the rmap */
Why TLB_ZAP_RMAP bit is not checked explicitly here, like in s390 version?
(I assume, when/if ENCODE_PAGE_BITS is not TLB_ZAP_RMAP only, calling
page_zap_pte_rmap() without such a check would be a bug).
> page_zap_pte_rmap(page);
> VM_WARN_ON_ONCE_PAGE(page_mapcount(page) < 0, page);
> }
> }
>
> /*
> * Now all entries have been un-encoded, and changed to plain
> * page pointers, so we can cast the 'encoded_page' array to
> * a plain page array and free them
> */
> free_pages_and_swap_cache((struct page **)pages, nr);
> }
Thanks!
Powered by blists - more mailing lists