linux-kernel - Re: [RFC PATCH 1/4] mm: migrate: Allow misplaced migration without VMA too

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: <Z8n_ovXcdAzcUNrw@gourry-fedora-PF4VCD3F>
Date: Thu, 6 Mar 2025 15:03:46 -0500
From: Gregory Price <gourry@...rry.net>
To: Matthew Wilcox <willy@...radead.org>
Cc: Bharata B Rao <bharata@....com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, AneeshKumar.KizhakeVeetil@....com,
	Hasan.Maruf@....com, Jonathan.Cameron@...wei.com,
	Michael.Day@....com, akpm@...ux-foundation.org,
	dave.hansen@...el.com, david@...hat.com, feng.tang@...el.com,
	hannes@...xchg.org, honggyu.kim@...com, hughd@...gle.com,
	jhubbard@...dia.com, k.shutemov@...il.com, kbusch@...a.com,
	kmanaouil.dev@...il.com, leesuyeon0506@...il.com, leillc@...gle.com,
	liam.howlett@...cle.com, mgorman@...hsingularity.net,
	mingo@...hat.com, nadav.amit@...il.com, nphamcs@...il.com,
	peterz@...radead.org, raghavendra.kt@....com, riel@...riel.com,
	rientjes@...gle.com, rppt@...nel.org, shivankg@....com,
	shy828301@...il.com, sj@...nel.org, vbabka@...e.cz,
	weixugc@...gle.com, ying.huang@...ux.alibaba.com, ziy@...dia.com,
	dave@...olabs.net, yuanchu@...gle.com, hyeonggon.yoo@...com
Subject: Re: [RFC PATCH 1/4] mm: migrate: Allow misplaced migration without
 VMA too

On Thu, Mar 06, 2025 at 06:42:10PM +0000, Matthew Wilcox wrote:
> On Thu, Mar 06, 2025 at 01:19:41PM -0500, Gregory Price wrote:
> > Divorced from the tiering mechanisms, is making misplaced migration able
> > to migrate unmapped pages not generally useful?
> 
> The only thing I can think of is if you have a process or set of
> processes on node A calling read() and the file is cached on node B.
> But in order to decide if the page is on the wrong node, you'd need
> to track a lot of information about which nodes the page is being
> accessed from.  Which is probably why we've never bothered to do it.
> 
> This is not a large patch for you to carry as part of your patchset.
> There's nothing intrinsically wrong with it; it just has no users in
> mainline and no real prospect of any being added soon.

That's fair, I'm just tracking 3-4 different RFCs that are going to butt
up against this, so wanted to assess whether getting the patches out
ahead would save some strife.

~Gregory