linux-kernel - Re: [PATCH] mm: vmscan: add skipexec mode not to reclaim pages with VM

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] [day] [month] [year] [list]

Message-Id: <20260121034000.51915-1-jackzxcui1989@163.com>
Date: Wed, 21 Jan 2026 11:40:00 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: shakeel.butt@...ux.dev
Cc: Liam.Howlett@...cle.com,
	akpm@...ux-foundation.org,
	axelrasmussen@...gle.com,
	david@...nel.org,
	hannes@...xchg.org,
	harry.yoo@...cle.com,
	jackzxcui1989@....com,
	jannh@...gle.com,
	kuba@...nel.org,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	lorenzo.stoakes@...cle.com,
	mhocko@...nel.org,
	riel@...riel.com,
	vbabka@...e.cz,
	weixugc@...gle.com,
	willy@...radead.org,
	yuanchu@...gle.com,
	zhengqi.arch@...edance.com
Subject: Re: [PATCH] mm: vmscan: add skipexec mode not to reclaim pages with VM_EXEC vma flag

On Tue, 20 Jan 2026 14:20:23 -0800 Shakeel Butt <shakeel.butt@...ux.dev> wrote:
> > 1. The reclaimed code segments are often those that handle exceptional
> > scenarios, which are not frequently executed. When memory pressure
> > increases, the entire system can become sluggish, leading to execution of
> > these seldom-used exception-handling code segments. Since these segments
> > are more likely to be reclaimed from memory, this exacerbates system
> > sluggishness.
> > 
> > 2. The reclaimed code segments used for exception handling are often
> > shared by multiple tasks, causing these tasks to wait on the folio's
> > PG_locked bit, further increasing I/O wait.
> > 
> > 3. Under memory pressure, the reclamation of code segments is often
> > scattered and randomly distributed, slowing down the efficiency of block
> > device reads and further exacerbating I/O wait.
> > 
> > While this issue could be addressed by preloading a library mlock all
> > executable segments, it would lead to many code segments that are never
> > used being locked, resulting in memory waste.
> > 
> > In systems where code execution is relatively fixed, preventing currently
> > in-use code segments from being reclaimed makes sense. This acts as a
> > self-adaptive way for the system to lock the necessary portions, which
> > saves memory compared to locking all code segments with mlock.
> 
> Have you tried mlock2(MLOCK_ONFAULT) for your application? It will not
> bring in unaccessed segments into memory and only mlocks which is
> already in memory or accessed in future?

It's a good idea :)  Thanks.
We may also try this solution in our project later.

--
Xin Zhao