linux-kernel - Re: [RFC PATCH v3 1/8] mm: multi-gen LRU: ignore non-leaf pmd_young for force

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 09 Apr 2024 14:50:42 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Yuanchu Xie <yuanchu@...gle.com>
Cc: David Hildenbrand <david@...hat.com>,  "Aneesh Kumar K.V"
 <aneesh.kumar@...ux.ibm.com>,  Khalid Aziz <khalid.aziz@...cle.com>,
  Henry Huang <henry.hj@...group.com>,  Yu Zhao <yuzhao@...gle.com>,  Dan
 Williams <dan.j.williams@...el.com>,  Gregory Price
 <gregory.price@...verge.com>,  Wei Xu <weixugc@...gle.com>,  David
 Rientjes <rientjes@...gle.com>,  Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>,  "Rafael J. Wysocki" <rafael@...nel.org>,
  Andrew Morton <akpm@...ux-foundation.org>,  Johannes Weiner
 <hannes@...xchg.org>,  Michal Hocko <mhocko@...nel.org>,  Roman Gushchin
 <roman.gushchin@...ux.dev>,  Muchun Song <muchun.song@...ux.dev>,  Shuah
 Khan <shuah@...nel.org>,  Yosry Ahmed <yosryahmed@...gle.com>,  Matthew
 Wilcox <willy@...radead.org>,  Sudarshan Rajagopalan
 <quic_sudaraja@...cinc.com>,  Kairui Song <kasong@...cent.com>,  "Michael
 S. Tsirkin" <mst@...hat.com>,  Vasily Averin <vasily.averin@...ux.dev>,
  Nhat Pham <nphamcs@...il.com>,  Miaohe Lin <linmiaohe@...wei.com>,  Qi
 Zheng <zhengqi.arch@...edance.com>,  Abel Wu <wuyun.abel@...edance.com>,
  "Vishal Moola (Oracle)" <vishal.moola@...il.com>,  Kefeng Wang
 <wangkefeng.wang@...wei.com>,  linux-kernel@...r.kernel.org,
  linux-mm@...ck.org,  cgroups@...r.kernel.org,
  linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH v3 1/8] mm: multi-gen LRU: ignore non-leaf pmd_young
 for force_scan=true

Yuanchu Xie <yuanchu@...gle.com> writes:

> When non-leaf pmd accessed bits are available, MGLRU page table walks
> can clear the accessed bit and promptly ignore the accessed bit on the
> pte because it's on a different node, so the walk does not update the
> generation of said page. When the next scan comes around on the right
> node, the non-leaf pmd accessed bit might remain cleared and the pte
> accessed bits won't be checked. While this is sufficient for
> reclaim-driven aging, where the goal is to select a reasonably cold
> page, the access can be missed when aging proactively for measuring the
> working set size of a node/memcg.
>
> Since force_scan disables various other optimizations, we check
> force_scan to ignore the non-leaf pmd accessed bit.
>
> Signed-off-by: Yuanchu Xie <yuanchu@...gle.com>
> ---
>  mm/vmscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 4f9c854ce6cc..1a7c7d537db6 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3522,7 +3522,7 @@ static void walk_pmd_range(pud_t *pud, unsigned long start, unsigned long end,
>  
>  		walk->mm_stats[MM_NONLEAF_TOTAL]++;
>  
> -		if (should_clear_pmd_young()) {
> +		if (!walk->force_scan && should_clear_pmd_young()) {
>  			if (!pmd_young(val))
>  				continue;

Sorry, I don't understand why we need this.  If !pmd_young(val), we
don't need to update the generation.  If pmd_young(val), the bloom
filter will be ignored if force_scan == true.  Or do I miss something?

--
Best Regards,
Huang, Ying