From: "Henry Huang" <henry.hj@antgroup.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: 谈鉴锋 <henry.tjf@antgroup.com>, "朱辉(茶水)" <teawater@antgroup.com>,
akpm@linux-foundation.org, "Henry Huang" <henry.hj@antgroup.com>
Subject: [RFC v2] mm: Multi-Gen LRU: fix use mm/page_idle/bitmap
Date: Wed, 06 Dec 2023 20:50:06 +0800 [thread overview]
Message-ID: <cover.1701853894.git.henry.hj@antgroup.com> (raw)
When Multi-Gen LRU is enabled, we can't use /sys/kernel/mm/page_idle/bitmap
to track memory which is actually been used.
Multi-Gen LRU page-table walker clears pte young flag, but it doesn't
clear page idle flag. When we use /sys/kernel/mm/page_idle/bitmap to check
whether one page is accessed, it would tell us this page is idle,
but actually this page has been accessed.
For those unmapped filecache pages, page idle flag would not been
cleared in folio_mark_accessed if Multi-Gen LRU is enabled.
So we couln't use /sys/kernel/mm/page_idle/bitmap to check whether
a filecache page is read or written.
What's more, /sys/kernel/mm/page_idle/bitmap also clears pte young flag.
If one page is accessed, it would set page young flag. Multi-Gen LRU
page-table walker should check both page&pte young flags.
Changes in V2:
We move folio_clear_idle into get_pfn_folio to improve efficiency of
read /sys/kernel/mm/page_idle/bitmap.
Sometimes memcg of process may be changed, but memcg of page would not be
changed. Page idle flag would not be cleared when multi-gen LRU scan
this process's page-table.
We think it's better to clear page idle flag as soon as possible when
walking page-table. For those non-idle pages, it's not necessary to walk
rmap and clear pte young(read /sys/kernel/mm/page_idle/bitmap) if
multi-gen LRU page-table walker already scanned once before.
Henry Huang (1):
mm: Multi-Gen LRU: fix use mm/page_idle/bitmap
mm/swap.c | 3 +++
mm/vmscan.c | 40 ++++++++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 12 deletions(-)
--
2.43.0
next reply other threads:[~2023-12-06 12:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 12:50 Henry Huang [this message]
2023-12-06 12:50 ` Henry Huang
2023-12-07 1:30 ` Yu Zhao
2023-12-08 7:12 ` Henry Huang
2023-12-15 6:46 ` Yu Zhao
2023-12-15 10:53 ` Henry Huang
2023-12-16 21:06 ` Yu Zhao
2023-12-17 6:59 ` Henry Huang
2023-12-21 23:15 ` Yuanchu Xie
2023-12-22 2:44 ` Henry Huang
2023-12-22 4:35 ` Yu Zhao
2023-12-22 5:14 ` David Rientjes
2023-12-22 15:40 ` Henry Huang
2024-01-10 19:24 ` Yuanchu Xie
2024-01-12 4:40 ` Henry Huang
2023-12-15 7:23 ` Yu Zhao
2023-12-15 12:44 ` Henry Huang
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=cover.1701853894.git.henry.hj@antgroup.com \
--to=henry.hj@antgroup.com \
--cc=akpm@linux-foundation.org \
--cc=henry.tjf@antgroup.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=teawater@antgroup.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox