From: David Rientjes <rientjes@google.com>
To: Raghavendra K T <raghavendra.kt@amd.com>
Cc: Hyeonggon Yoo <hyeonggon.yoo@sk.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"bharata@amd.com" <bharata@amd.com>,
kernel_team@skhynix.com, 42.hyeyoo@gmail.com,
"gourry@gourry.net" <gourry@gourry.net>,
"nehagholkar@meta.com" <nehagholkar@meta.com>,
"abhishekd@meta.com" <abhishekd@meta.com>,
"ying.huang@linux.alibaba.com" <ying.huang@linux.alibaba.com>,
"nphamcs@gmail.com" <nphamcs@gmail.com>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"feng.tang@intel.com" <feng.tang@intel.com>,
"kbusch@meta.com" <kbusch@meta.com>,
"Hasan.Maruf@amd.com" <Hasan.Maruf@amd.com>,
"sj@kernel.org" <sj@kernel.org>,
"david@redhat.com" <david@redhat.com>,
"willy@infradead.org" <willy@infradead.org>,
"k.shutemov@gmail.com" <k.shutemov@gmail.com>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"hughd@google.com" <hughd@google.com>,
"shy828301@gmail.com" <shy828301@gmail.com>,
"liam.howlett@oracle.com" <liam.howlett@oracle.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"nadav.amit@gmail.com" <nadav.amit@gmail.com>,
"shivankg@amd.com" <shivankg@amd.com>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
"AneeshKumar.KizhakeVeetil@arm.com"
<AneeshKumar.KizhakeVeetil@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jon.grimm@amd.com" <jon.grimm@amd.com>,
"santosh.shukla@amd.com" <santosh.shukla@amd.com>,
"Michael.Day@amd.com" <Michael.Day@amd.com>,
"riel@surriel.com" <riel@surriel.com>,
"weixugc@google.com" <weixugc@google.com>,
"leesuyeon0506@gmail.com" <leesuyeon0506@gmail.com>,
honggyu.kim@sk.com, "leillc@google.com" <leillc@google.com>,
"kmanaouil.dev@gmail.com" <kmanaouil.dev@gmail.com>,
"rppt@kernel.org" <rppt@kernel.org>,
"dave.hansen@intel.com" <dave.hansen@intel.com>,
yuanchu@google.com
Subject: Re: [LSF/MM/BPF TOPIC] Overhauling hot page detection and promotion based on PTE A bit scanning
Date: Sun, 26 Jan 2025 23:01:25 -0800 (PST) [thread overview]
Message-ID: <4c805e3c-4d5d-6880-7e65-cce1041f7d35@google.com> (raw)
In-Reply-To: <0571919b-52e1-4981-8d34-bcc781c0561a@amd.com>
On Fri, 24 Jan 2025, Raghavendra K T wrote:
> On 1/24/2025 11:23 AM, Hyeonggon Yoo wrote:
> >
> >
> > On 1/23/2025 7:57 PM, Raghavendra K T wrote:
> > > Bharata and I would like to propose the following topic for LSFMM.
> > >
> > > Topic: Overhauling hot page detection and promotion based on PTE A bit
> > > scanning.
> [...]
> > > 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.
>
> Thank you for pointing that.
>
+1. Yuanchu, do you have ideas for how MGLRU periodic aging and working
set can play a role in this?
> > By the way, do you have any reason why you'd prefer opt-in prctl
> > over per-memcg control?
> >
>
> opt-in prctl came in the MM alignment discussion, and have added that.
Are you planning on sending a refresh of that patch series? :)
> per-memcg also definitely makes sense. I am not aware which is the most
> used usecase. But adding provision for both with one having more
> priority over other may be the way to go.
>
I would suggest leveraging prctl() for this as opposed to memcg. I think
making this part of memcg is beyond the scope for what memcg is intended
to do, limitation of memory resources, similar to the recent discussions
on per-cgroup control for THP.
Additionally, the current memcg configuration of the system may also not
be convenient for using for this purpose, especially if one process should
be opted out in the memcg hierarchy. Requiring users to change how their
memcg is configured just to opt out would be rather unfortunate.
> Overall point here is to save time in unnecessary scanning.
> will be adding prctl in the upcoming version to start with.
>
Fully agreed.
Thanks very much for proposing this topic, Raghu, I think it will be very
useful to discuss! Looking forward to it!
next prev parent reply other threads:[~2025-01-27 7:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 10:57 Raghavendra K T
2025-01-23 18:20 ` SeongJae Park
2025-01-24 8:54 ` Raghavendra K T
2025-01-24 18:05 ` Jonathan Cameron
2025-01-24 5:53 ` Hyeonggon Yoo
2025-01-24 9:02 ` Raghavendra K T
2025-01-27 7:01 ` David Rientjes [this message]
2025-01-27 7:11 ` Raghavendra K T
2025-02-06 3:14 ` Yuanchu Xie
2025-01-26 2:27 ` Huang, Ying
2025-01-27 5:11 ` Bharata B Rao
2025-01-27 18:34 ` SeongJae Park
2025-02-07 8:10 ` Huang, Ying
2025-02-07 9:06 ` Gregory Price
2025-02-07 19:52 ` SeongJae Park
2025-02-07 19:06 ` Davidlohr Bueso
2025-03-14 1:56 ` Raghavendra K T
2025-03-14 2:12 ` Raghavendra K T
2025-01-31 12:28 ` Jonathan Cameron
2025-01-31 13:09 ` [LSF/MM/BPF TOPIC] Unifying sources of page temperature information - what info is actually wanted? Jonathan Cameron
2025-02-05 6:24 ` Bharata B Rao
2025-02-05 16:05 ` Johannes Weiner
2025-02-06 6:46 ` SeongJae Park
2025-02-06 15:30 ` Jonathan Cameron
2025-02-07 9:50 ` Matthew Wilcox
2025-02-16 7:04 ` Huang, Ying
2025-02-16 6:49 ` Huang, Ying
2025-02-17 4:10 ` Bharata B Rao
2025-02-17 8:06 ` Huang, Ying
2025-03-14 14:24 ` Jonathan Cameron
2025-03-17 22:34 ` Davidlohr Bueso
2025-02-03 2:23 ` [LSF/MM/BPF TOPIC] Overhauling hot page detection and promotion based on PTE A bit scanning Raghavendra K T
2025-04-07 3:13 ` Bharata B Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c805e3c-4d5d-6880-7e65-cce1041f7d35@google.com \
--to=rientjes@google.com \
--cc=42.hyeyoo@gmail.com \
--cc=AneeshKumar.KizhakeVeetil@arm.com \
--cc=Hasan.Maruf@amd.com \
--cc=Michael.Day@amd.com \
--cc=abhishekd@meta.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@amd.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=feng.tang@intel.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=honggyu.kim@sk.com \
--cc=hughd@google.com \
--cc=hyeonggon.yoo@sk.com \
--cc=jhubbard@nvidia.com \
--cc=jon.grimm@amd.com \
--cc=k.shutemov@gmail.com \
--cc=kbusch@meta.com \
--cc=kernel_team@skhynix.com \
--cc=kmanaouil.dev@gmail.com \
--cc=leesuyeon0506@gmail.com \
--cc=leillc@google.com \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=nehagholkar@meta.com \
--cc=nphamcs@gmail.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=santosh.shukla@amd.com \
--cc=shivankg@amd.com \
--cc=shy828301@gmail.com \
--cc=sj@kernel.org \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox