From: SeongJae Park <sj@kernel.org>
To: Dmitry Ilvokhin <d@ilvokhin.com>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Kairui Song <kasong@tencent.com>, Nhat Pham <nphamcs@gmail.com>,
Baoquan He <bhe@redhat.com>, Barry Song <baohua@kernel.org>,
Chris Li <chrisl@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Kiryl Shutsemau <kas@kernel.org>,
Usama Arif <usamaarif642@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v2] mm: skip folio_activate() for mlocked folios
Date: Tue, 7 Oct 2025 12:53:13 -0700 [thread overview]
Message-ID: <20251007195313.7336-1-sj@kernel.org> (raw)
In-Reply-To: <aOPDRmk2Zd20qxfk@shell.ilvokhin.com>
On Mon, 6 Oct 2025 13:25:26 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> __mlock_folio() does not move folio to unevicable LRU, when
> folio_activate() removes folio from LRU.
A trivial opinion. So the user-visible issue is the incorrect meminfo, right?
I read your changelog below saying you changed this message from v1 to frame on
unevictable LRU rather than stat accounting, and I think that's nice to
understand the detail. But I think further describing the resulting
user-visible issue can be helpful at better understanding the motivation of
this nice patch.
>
> To prevent this case also check for folio_test_mlocked() in
> folio_mark_accessed(). If folio is not yet marked as unevictable, but
> already marked as mlocked, then skip folio_activate() call to allow
> __mlock_folio() to make all necessary updates. It should be safe to skip
> folio_activate() here, because mlocked folio should end up in
> unevictable LRU eventually anyway.
>
> To observe the problem mmap() and mlock() big file and check Unevictable
> and Mlocked values from /proc/meminfo. On freshly booted system without
> any other mlocked memory we expect them to match or be quite close.
>
> See below for more detailed reproduction steps. Source code of stat.c is
> available at [1].
>
> $ head -c 8G < /dev/urandom > /tmp/random.bin
>
> $ cc -pedantic -Wall -std=c99 stat.c -O3 -o /tmp/stat
> $ /tmp/stat
> Unevictable: 8389668 kB
> Mlocked: 8389700 kB
>
> Need to run binary twice. Problem does not reproduce on the first run,
> but always reproduces on the second run.
>
> $ /tmp/stat
> Unevictable: 5374676 kB
> Mlocked: 8389332 kB
>
> [1]: https://gist.github.com/ilvokhin/e50c3d2ff5d9f70dcbb378c6695386dd
>
> Co-developed-by: Kiryl Shutsemau <kas@kernel.org>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Usama Arif <usamaarif642@gmail.com>
Because this is a fix of a user-visible issue, I'm wondering if this deserves
Fixes: and Cc: stable@.
Anyway my comments are only trivial ones, and I think the change is good.
Reviewed-by: SeongJae Park <sj@kernel.org>
> ---
> Changes in v2:
> - Rephrase commit message: frame it in terms of unevicable LRU, not stat
> accounting.
Yet another trivial and personal opinion. Adding a link to the previous
version could be helpful for reviewers like me.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-10-07 19:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 13:25 [PATCH v2] mm: skip folio_activate() for mlocked folios Dmitry Ilvokhin
2025-10-07 16:26 ` Nhat Pham
2025-10-07 19:53 ` SeongJae Park [this message]
2025-10-08 10:33 ` Kiryl Shutsemau
2025-10-08 16:29 ` SeongJae Park
2025-10-08 16:17 ` Shakeel Butt
2025-10-08 18:06 ` Dmitry Ilvokhin
2025-10-15 19:59 ` Andrew Morton
2025-10-15 20:09 ` Dmitry Ilvokhin
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=20251007195313.7336-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=d@ilvokhin.com \
--cc=kas@kernel.org \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=usamaarif642@gmail.com \
--cc=weixugc@google.com \
--cc=yuanchu@google.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.