[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJj2-QE10YknASd9b=_Qe8dWt4eRD1ZtOSFMYe3-26M0aEpUcQ@mail.gmail.com>
Date: Wed, 5 Feb 2025 19:14:42 -0800
From: Yuanchu Xie <yuanchu@...gle.com>
To: Hyeonggon Yoo <hyeonggon.yoo@...com>, Raghavendra K T <raghavendra.kt@....com>,
"bharata@....com" <bharata@....com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>, kernel_team@...ynix.com,
42.hyeyoo@...il.com, "gourry@...rry.net" <gourry@...rry.net>,
"nehagholkar@...a.com" <nehagholkar@...a.com>, "abhishekd@...a.com" <abhishekd@...a.com>,
"ying.huang@...ux.alibaba.com" <ying.huang@...ux.alibaba.com>, "nphamcs@...il.com" <nphamcs@...il.com>,
"hannes@...xchg.org" <hannes@...xchg.org>, "feng.tang@...el.com" <feng.tang@...el.com>,
"kbusch@...a.com" <kbusch@...a.com>, "Hasan.Maruf@....com" <Hasan.Maruf@....com>, "sj@...nel.org" <sj@...nel.org>,
"david@...hat.com" <david@...hat.com>, "willy@...radead.org" <willy@...radead.org>,
"k.shutemov@...il.com" <k.shutemov@...il.com>,
"mgorman@...hsingularity.net" <mgorman@...hsingularity.net>, "vbabka@...e.cz" <vbabka@...e.cz>,
"hughd@...gle.com" <hughd@...gle.com>, "rientjes@...gle.com" <rientjes@...gle.com>,
"shy828301@...il.com" <shy828301@...il.com>, "liam.howlett@...cle.com" <liam.howlett@...cle.com>,
"peterz@...radead.org" <peterz@...radead.org>, "mingo@...hat.com" <mingo@...hat.com>,
"nadav.amit@...il.com" <nadav.amit@...il.com>, "shivankg@....com" <shivankg@....com>,
"ziy@...dia.com" <ziy@...dia.com>, "jhubbard@...dia.com" <jhubbard@...dia.com>,
"AneeshKumar.KizhakeVeetil@....com" <AneeshKumar.KizhakeVeetil@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "jon.grimm@....com" <jon.grimm@....com>,
"santosh.shukla@....com" <santosh.shukla@....com>, "Michael.Day@....com" <Michael.Day@....com>,
"riel@...riel.com" <riel@...riel.com>, "weixugc@...gle.com" <weixugc@...gle.com>,
"leesuyeon0506@...il.com" <leesuyeon0506@...il.com>, honggyu.kim@...com,
"leillc@...gle.com" <leillc@...gle.com>, "kmanaouil.dev@...il.com" <kmanaouil.dev@...il.com>,
"rppt@...nel.org" <rppt@...nel.org>, "dave.hansen@...el.com" <dave.hansen@...el.com>, Kinsey Ho <kinseyho@...gle.com>
Subject: Re: [LSF/MM/BPF TOPIC] Overhauling hot page detection and promotion
based on PTE A bit scanning
On Thu, Jan 23, 2025 at 9:53 PM Hyeonggon Yoo <hyeonggon.yoo@...com> wrote:
> On 1/23/2025 7:57 PM, Raghavendra K T wrote:
> > Bharata and I would like to propose the following topic for LSFMM.
> >
> > Here is the list of potential discussion points:
> > 1. Other improvements and enhancements to PTE A bit scanning approach. Use of
> > multiple kernel threads, throttling improvements, promotion policies, per-process
> > opt-in via prctl, virtual vs physical address based scanning, tuning hot page
> > detection algorithm etc.
>
> Yuanchu's MGLRU periodic aging series [1] seems quite relevant here,
> you might want to look at it. adding Yuanchu to Cc.
Thanks for the mention, Hyeonggon Yoo.
Working set reporting doesn't aim to promote/demote/reclaim pages, but
to show aggregate stats of the memory in access recency. The periodic
aging part is optional since client devices wouldn't want a background
daemon wasting battery aging lruvecs when nothing is happening.
For the server use case, the aging kthread periodically invoke MGLRU
aging, which performs the PTE A bit scanning. MGLRU handles unmapped
page cache as well for reclaim purposes.
Reading through the kmmscand patch series.
Kmmscand also keeps a list of mm_struct and performs scanning on them,
so given there're many use cases for PTE A bit scanning, this seems
like an opportunity to abstract some of the mm_struct scanning.
Code-wise the A bit scanners do very similar things, and the MGLRU
version has optional optimizations that reduce the scanning overhead.
I wonder if you have considered migrating pages from the MGLRU young
generation of a remote node, or pages that have remained in the young
generation. Some changes to MGLRU would be necessary in that case.
Also adding Kinsey Ho since he's been looking at page promotion as well.
Thanks,
Yuanchu
Powered by blists - more mailing lists