linux-kernel - Re: [LSF/MM/BPF TOPIC] Overhauling hot page detection and promotion based on PTE A bit scanning

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]

Message-ID: <Z6XNIuVbYvZMYJs2@gourry-fedora-PF4VCD3F>
Date: Fri, 7 Feb 2025 04:06:42 -0500
From: Gregory Price <gourry@...rry.net>
To: "Huang, Ying" <ying.huang@...ux.alibaba.com>
Cc: SeongJae Park <sj@...nel.org>, Bharata B Rao <bharata@....com>,
	Raghavendra K T <raghavendra.kt@....com>, linux-mm@...ck.org,
	akpm@...ux-foundation.org, lsf-pc@...ts.linux-foundation.org,
	nehagholkar@...a.com, abhishekd@...a.com, nphamcs@...il.com,
	hannes@...xchg.org, feng.tang@...el.com, kbusch@...a.com,
	Hasan.Maruf@....com, david@...hat.com, willy@...radead.org,
	k.shutemov@...il.com, mgorman@...hsingularity.net, vbabka@...e.cz,
	hughd@...gle.com, rientjes@...gle.com, shy828301@...il.com,
	liam.howlett@...cle.com, peterz@...radead.org, mingo@...hat.com,
	nadav.amit@...il.com, shivankg@....com, ziy@...dia.com,
	jhubbard@...dia.com, AneeshKumar.KizhakeVeetil@....com,
	linux-kernel@...r.kernel.org, jon.grimm@....com,
	santosh.shukla@....com, Michael.Day@....com, riel@...riel.com,
	weixugc@...gle.com, leesuyeon0506@...il.com, honggyu.kim@...com,
	leillc@...gle.com, kmanaouil.dev@...il.com, rppt@...nel.org,
	dave.hansen@...el.com
Subject: Re: [LSF/MM/BPF TOPIC] Overhauling hot page detection and promotion
 based on PTE A bit scanning

On Fri, Feb 07, 2025 at 04:10:47PM +0800, Huang, Ying wrote:
> SeongJae Park <sj@...nel.org> writes:
> >
> > I agree the fairness is a thing that we need to aware of.  But IMHO, it is
> > something that the async approach can further be advanced for, not a strict
> > blocker for now.
> 
> Personally, I have no objection to async operations in general.
> However, we may need to find some way to control these async operations
> instead of adding more and more background kthreads blindly.  How to
> charge and constrain the resources used by these async operations is
> important too.  For example, some users may want to bind some async
> operations on some CPUs.
> 
> IMHO, we should think about the requirements and possible solutions
> instead of ignoring the issues.
>

It also concerns me that most every proposal on async promotion ignores
the promotion-node selection problem as if it's a secondary issue.

Async systems fundamentally lack accessor-locality information unless it
is recorded - and recording this information is expensive and/or
heuristically imprecise for memory shared across tasks (two threads in
the same process schedule across sockets).

If we can't agree on a solution to this problem, it undercuts many of
these RFCs which often simply hard-code the target node to "0" because
it's too hard or too expensive to consider the multi-socket scenario.

~Gregory