[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <hnpzad4aehmp6ncgwhlinzx55z3zst5dlkhsjphpazccy5lzpv@hfj2eyewuplz>
Date: Fri, 3 Oct 2025 15:41:05 +0100
From: Kiryl Shutsemau <kas@...nel.org>
To: Dmitry Ilvokhin <d@...okhin.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Kemeng Shi <shikemeng@...weicloud.com>, Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>,
Baoquan He <bhe@...hat.com>, Barry Song <baohua@...nel.org>, Chris Li <chrisl@...nel.org>,
Axel Rasmussen <axelrasmussen@...gle.com>, Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
Usama Arif <usamaarif642@...il.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kernel-team@...a.com
Subject: Re: [PATCH] mm: skip folio_activate() for mlocked folios
On Fri, Oct 03, 2025 at 02:19:55PM +0000, Dmitry Ilvokhin wrote:
> __mlock_folio() should update stats, when lruvec_add_folio() is called,
The update of stats is incidental to moving to unevicable LRU. But okay.
> but if folio_test_clear_lru() check failed, then __mlock_folio() gives
> up early. From the other hand, folio_mark_accessed() calls
> folio_activate() which also calls folio_test_clear_lru() down the line.
> When folio_activate() successfully removed folio from LRU,
> __mlock_folio() will not update any stats, which will lead to inaccurate
> values in /proc/meminfo as well as cgroup memory.stat.
>
> To prevent this case from happening 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.
>
> 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
I think it is worth starting with the problem statement.
I like to follow this pattern of commit messages:
<Background, if needed>
<Issue statement>
<Proposed solution>
>
> [1]: https://gist.github.com/ilvokhin/e50c3d2ff5d9f70dcbb378c6695386dd
>
> Co-developed-by: Kiryl Shutsemau <kas@...nel.org>
> Signed-off-by: Kiryl Shutsemau <kas@...nel.org>
> Signed-off-by: Dmitry Ilvokhin <d@...okhin.com>
Your Co-developed-by is missing. See submitting-patches.rst.
> ---
> mm/swap.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/mm/swap.c b/mm/swap.c
> index 2260dcd2775e..f682f070160b 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -469,6 +469,16 @@ void folio_mark_accessed(struct folio *folio)
> * this list is never rotated or maintained, so marking an
> * unevictable page accessed has no effect.
> */
> + } else if (folio_test_mlocked(folio)) {
> + /*
> + * Pages that are mlocked, but not yet on unevictable LRU.
> + * They might be still in mlock_fbatch waiting to be processed
> + * and activating it here might interfere with
> + * mlock_folio_batch(). __mlock_folio() will fail
> + * folio_test_clear_lru() check and give up. It happens because
> + * __folio_batch_add_and_move() clears LRU flag, when adding
> + * folio to activate batch.
> + */
> } else if (!folio_test_active(folio)) {
> /*
> * If the folio is on the LRU, queue it for activation via
> --
> 2.47.3
>
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists