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]
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().

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ