linux-kernel - Re: [PATCH v10 07/14] mm: multi-gen LRU: exploit locality in rmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOUHufah=yc7pucvWg83pymHX4+govxaYiLYDt7dHnGVTfJMQg@mail.gmail.com>
Date:   Wed, 27 Apr 2022 00:00:47 -0600
From:   Yu Zhao <yuzhao@...gle.com>
To:     Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
Cc:     Stephen Rothwell <sfr@...hwell.id.au>,
        Linux-MM <linux-mm@...ck.org>, Andi Kleen <ak@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Barry Song <21cnbao@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Hillf Danton <hdanton@...a.com>, Jens Axboe <axboe@...nel.dk>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Mel Gorman <mgorman@...e.de>,
        Michael Larabel <Michael@...haellarabel.com>,
        Michal Hocko <mhocko@...nel.org>,
        Mike Rapoport <rppt@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Will Deacon <will@...nel.org>,
        Ying Huang <ying.huang@...el.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Kernel Page Reclaim v2 <page-reclaim@...gle.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Brian Geffon <bgeffon@...gle.com>,
        Jan Alexander Steffens <heftig@...hlinux.org>,
        Oleksandr Natalenko <oleksandr@...alenko.name>,
        Steven Barrett <steven@...uorix.net>,
        Suleiman Souhlal <suleiman@...gle.com>,
        Daniel Byrne <djbyrne@....edu>,
        Donald Carr <d@...os-reins.com>,
        Holger Hoffstätte <holger@...lied-asynchrony.com>,
        Konstantin Kharlamov <Hi-Angel@...dex.ru>,
        Shuang Zhai <szhai2@...rochester.edu>,
        Sofia Trinh <sofia.trinh@....works>,
        Vaibhav Jain <vaibhav@...ux.ibm.com>
Subject: Re: [PATCH v10 07/14] mm: multi-gen LRU: exploit locality in rmap

On Tue, Apr 26, 2022 at 11:31 PM Aneesh Kumar K V
<aneesh.kumar@...ux.ibm.com> wrote:
>
> On 4/27/22 10:08 AM, Yu Zhao wrote:
> > On Tue, Apr 26, 2022 at 10:33 PM Aneesh Kumar K.V
> > <aneesh.kumar@...ux.ibm.com> wrote:
> >>
> >> Yu Zhao <yuzhao@...gle.com> writes:
> >>
> >> ....
> >>
> >>   diff --git a/mm/rmap.c b/mm/rmap.c
> >>> index fedb82371efe..7cb7ef29088a 100644
> >>> --- a/mm/rmap.c
> >>> +++ b/mm/rmap.c
> >>> @@ -73,6 +73,7 @@
> >>>   #include <linux/page_idle.h>
> >>>   #include <linux/memremap.h>
> >>>   #include <linux/userfaultfd_k.h>
> >>> +#include <linux/mm_inline.h>
> >>>
> >>>   #include <asm/tlbflush.h>
> >>>
> >>> @@ -821,6 +822,12 @@ static bool folio_referenced_one(struct folio *folio,
> >>>                }
> >>>
> >>>                if (pvmw.pte) {
> >>> +                     if (lru_gen_enabled() && pte_young(*pvmw.pte) &&
> >>> +                         !(vma->vm_flags & (VM_SEQ_READ | VM_RAND_READ))) {
> >>> +                             lru_gen_look_around(&pvmw);
> >>> +                             referenced++;
> >>> +                     }
> >>
> >> Is it required to update referenced here? we do that below after
> >> clearing the young bit. Or is the goal to identify whether we found any
> >> young pte around?
> >
> > referenced++ is needed because lru_gen_look_around() also clears the
> > young bit in pvmw.pte. And ptep_clear_flush_young_notify() will return
> > false unless mmu notifier returns true.
>
> should we then use a mmu notifier variant of clear_young in
> lru_gen_look_around() ?

Generally multiple sets of page tables don't share the same memory
locality. E.g., for kvm, its secondary page tables map to guest
physical address space, whose locality is very different from typical
virtual address space. In this case lru_gen_look_around() is generally
not helpful. For this reason, we don't use the mmu notifier variants
of pte_young() or clear_young().