From: Shakeel Butt <shakeel.butt@linux.dev>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, riel@surriel.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, harry.yoo@oracle.com,
jannh@google.com, willy@infradead.org, axelrasmussen@google.com,
yuanchu@google.com, weixugc@google.com, hannes@cmpxchg.org,
mhocko@kernel.org, zhengqi.arch@bytedance.com, kuba@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm: vmscan: add skipexec mode not to reclaim pages with VM_EXEC vma flag
Date: Tue, 20 Jan 2026 14:20:23 -0800 [thread overview]
Message-ID: <aW__D24ZrpeSPKZN@linux.dev> (raw)
In-Reply-To: <20260116042817.3790405-1-jackzxcui1989@163.com>
On Fri, Jan 16, 2026 at 12:28:17PM +0800, Xin Zhao wrote:
> For some embedded systems, .text segments are often fixed. In situations
> of high memory pressure, these fixed segments may be reclaimed by the
> system, leading to iowait when these segments will be used again.
> The iowait problem becomes even more severe due to the following reasons:
>
> 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?
next prev parent reply other threads:[~2026-01-20 22:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 4:28 [PATCH] mm: vmscan: add skipexec mode not to reclaim pages with VM_EXEC vma flag Xin Zhao
2026-01-16 8:20 ` Lorenzo Stoakes
2026-01-16 8:53 ` Xin Zhao
2026-01-20 22:20 ` Shakeel Butt [this message]
2026-01-21 3:40 ` Xin Zhao
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=aW__D24ZrpeSPKZN@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=jackzxcui1989@163.com \
--cc=jannh@google.com \
--cc=kuba@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.