From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: devnull+kasong.tencent.com@kernel.org
Cc: akpm@linux-foundation.org, axelrasmussen@google.com,
baohua@kernel.org, baolin.wang@linux.alibaba.com,
baoquan.he@linux.dev, cgroups@vger.kernel.org,
chenridong@xiaomi.com, chrisl@kernel.org, damon@lists.linux.dev,
david@kernel.org, dev.jain@arm.com, ehab.ababneh@intel.com,
gourry@gourry.net, hannes@cmpxchg.org, hughd@google.com,
kasong@tencent.com, kunwu.chan@gmail.com, lance.yang@linux.dev,
liam@infradead.org, lianux.mm@gmail.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
liuxiang.277@bytedance.com, ljs@kernel.org, mhocko@kernel.org,
muchun.song@linux.dev, nico.pache@linux.dev, nphamcs@gmail.com,
qi.zheng@linux.dev, rientjes@google.com,
roman.gushchin@linux.dev, ryan.roberts@arm.com, ryncsn@gmail.com,
shakeel.butt@linux.dev, shikemeng@huaweicloud.com, sj@kernel.org,
surenb@google.com, tz2294@columbia.edu, usama.arif@linux.dev,
vbabka@kernel.org, vernon2gm@gmail.com, wangzicheng@honor.com,
weixugc@google.com, willy@infradead.org,
ying.huang@linux.alibaba.com, youngjun.park@lge.com,
yuanchu@google.com, yuzhao@google.com,
zhaozhengzhuo@uniontech.com, ziy@nvidia.com
Subject: [PATCH v4 01/17] mm/memcontrol: allow update of LRU statistic without holding LRU lock
Date: Tue, 3 Nov 2026 05:39:15 +0800 [thread overview]
Message-ID: <20261102213915.57805-1-baohua@kernel.org> (raw)
In-Reply-To: <20261016-mglru-fg-v4-1-2106750c0bfa@tencent.com>
On Fri, Oct 16, 2026 at 2:15 AM Kairui Song via B4 Relay <devnull+kasong.tencent.com@kernel.org> wrote:
>
> From: Kairui Song <kasong@tencent.com>
>
> To enable moving file pages in folio_mark_accessed directly and lazily
> for MGLRU, allow updating the LRU statistic atomically without holding a
> lock. It may cause temporary counter underflow, which should be fine as
> we still follow final consistency of the counter, and it only serves as
> a estimated metrics, a little inaccuracy has no visible effect.
This might be a good idea. Updating the LRU size without
holding lru_lock could open up possibilities for further
optimizations.
Recently, I've been thinking about something in the aging
path. For example, suppose a folio belongs to the root
memcg and is heavily shared by some of its descendant
memcgs, which also access it.
Currently, aging in those descendant memcgs will simply
skip this folio. Eventually, we'll have to rely on the
rmap of the root memcg to determine whether the folio is
hot or cold within the root memcg.
Since the shared folio may have a very large mapcount,
walking its rmap could be quite expensive.
So I've been thinking about this and put together some
very PoC code. It doesn't really work; it's just meant to
illustrate what I have in mind:
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7ddef3b488b3..31b02478269b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3618,7 +3618,7 @@ static struct folio *get_pfn_folio(unsigned long pfn, struct mem_cgroup *memcg,
return NULL;
rcu_read_lock();
- if (folio_memcg(folio) != memcg)
+ if (!mem_cgroup_is_descendant(memcg, folio_memcg(folio)))
folio = NULL;
rcu_read_unlock();
@@ -3723,7 +3723,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
continue;
if (last != folio) {
- walk_update_folio(walk, args->vma, walk->lruvec, last, dirty);
+ walk_update_folio(walk, args->vma, folio_lruvec(last), last, dirty);
last = folio;
dirty = false;
@@ -3736,7 +3736,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
walk->mm_stats[MM_LEAF_YOUNG] += nr;
}
- walk_update_folio(walk, args->vma, walk->lruvec, last, dirty);
+ walk_update_folio(walk, args->vma, folio_lruvec(last), last, dirty);
last = NULL;
if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
@@ -3812,7 +3812,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
goto next;
if (last != folio) {
- walk_update_folio(walk, vma, walk->lruvec, last, dirty);
+ walk_update_folio(walk, vma, folio_lruvec(last), last, dirty);
last = folio;
dirty = false;
@@ -3826,7 +3826,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
i = i > MIN_LRU_BATCH ? 0 : find_next_bit(bitmap, MIN_LRU_BATCH, i) + 1;
} while (i <= MIN_LRU_BATCH);
- walk_update_folio(walk, vma, walk->lruvec, last, dirty);
+ walk_update_folio(walk, vma, folio_lruvec(last), last, dirty);
lazy_mmu_mode_disable();
spin_unlock(ptl);
@@ -4499,7 +4499,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
continue;
if (last != folio) {
- walk_update_folio(walk, vma, lruvec, last, dirty);
+ walk_update_folio(walk, vma, folio_lruvec(last), last, dirty);
last = folio;
dirty = false;
@@ -4511,7 +4511,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
young += nr;
}
- walk_update_folio(walk, vma, lruvec, last, dirty);
+ walk_update_folio(walk, vma, folio_lruvec(last), last, dirty);
lazy_mmu_mode_disable();
We may want to explore this after mglru-fg. What are your
thoughts on this?
>
> Signed-off-by: Kairui Song <kasong@tencent.com>
> ---
> include/linux/mm_inline.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> index ab69b9930893..597f013c8e04 100644
> --- a/include/linux/mm_inline.h
> +++ b/include/linux/mm_inline.h
> @@ -47,11 +47,10 @@ static __always_inline void __update_lru_size(struct lruvec *lruvec,
> {
> struct pglist_data *pgdat = lruvec_pgdat(lruvec);
>
> - lockdep_assert_held(&lruvec->lru_lock);
> WARN_ON_ONCE(nr_pages != (int)nr_pages);
>
> mod_lruvec_state(lruvec, NR_LRU_BASE + lru, nr_pages);
> - __mod_zone_page_state(&pgdat->node_zones[zid],
> + mod_zone_page_state(&pgdat->node_zones[zid],
> NR_ZONE_LRU_BASE + lru, nr_pages);
> }
>
>
> --
> 2.56.0
>
>
Best,
Barry
next prev parent reply other threads:[~2026-11-02 21:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 18:15 [PATCH v4 00/17] mm/mglru: frequency guided promotion (MGLRU-FG) and flag cleanup Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 01/17] mm/memcontrol: allow update of LRU statistic without holding LRU lock Kairui Song via B4 Relay
2026-11-02 21:39 ` Barry Song (Xiaomi) [this message]
2026-10-15 18:15 ` [PATCH v4 02/17] mm/mglru: make generation page counters atomic Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 03/17] mm/memcg: add folio-based lruvec live helper Kairui Song via B4 Relay
2026-10-15 19:11 ` Harry Yoo
2026-10-16 6:15 ` Kairui Song
2026-10-19 13:46 ` Harry Yoo
2026-10-19 14:14 ` Harry Yoo
2026-10-16 7:39 ` Muchun Song
2026-10-16 7:54 ` Kairui Song
2026-10-16 9:09 ` Muchun Song
2026-10-15 18:15 ` [PATCH v4 04/17] mm/mglru: frequency guided workingset promotion (MGLRU-FG) Kairui Song via B4 Relay
2026-10-19 10:10 ` Barry Song
2026-10-19 12:08 ` Kairui Song
2026-10-26 22:34 ` Barry Song
2026-10-15 18:15 ` [PATCH v4 05/17] mm/mglru: make folio lru referenced times count a generic API Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 06/17] mm/mglru: move add/del LRU size accounting out of lru_gen_update_size() Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 07/17] mm/mglru, gup: mark folios referenced via a fast helper Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 08/17] mm/mglru, smaps: convert to LRU refs based operations for MGLRU Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 09/17] mm/damon: " Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 10/17] mm/khugepaged: " Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 11/17] mm/madvise: adapt for " Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 12/17] mm/huge_memory: mark folio as accessed more accurately on split Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 13/17] mm/mglru: folio LRU refs based active/inactive number accounting Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 14/17] mm/mglru: reparent folios from all generations Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 15/17] mm/mglru: make folio_inc_lru_refs lruvec lockless Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 16/17] mm/mglru: make folio_test_workingset() work based on folio LRU refs Kairui Song via B4 Relay
2026-10-15 18:16 ` [PATCH v4 17/17] Documentation/mm: multi-gen LRU: update for frequency guided promotion Kairui Song via B4 Relay
2026-10-16 8:42 ` [PATCH v4 00/17] mm/mglru: frequency guided promotion (MGLRU-FG) and flag cleanup Barry Song (Xiaomi)
2026-10-16 11:43 ` Kairui Song
2026-10-16 12:11 ` Kairui Song
2026-10-20 20:47 ` Barry Song
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=20261102213915.57805-1-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@xiaomi.com \
--cc=chrisl@kernel.org \
--cc=damon@lists.linux.dev \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=devnull+kasong.tencent.com@kernel.org \
--cc=ehab.ababneh@intel.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kasong@tencent.com \
--cc=kunwu.chan@gmail.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=lianux.mm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuxiang.277@bytedance.com \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=nphamcs@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=sj@kernel.org \
--cc=surenb@google.com \
--cc=tz2294@columbia.edu \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=vernon2gm@gmail.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=youngjun.park@lge.com \
--cc=yuanchu@google.com \
--cc=yuzhao@google.com \
--cc=zhaozhengzhuo@uniontech.com \
--cc=ziy@nvidia.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
all inboxes | Powered by JetHome®