From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta22.hihonor.com (mta22.hihonor.com [81.70.192.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C37992DA756 for ; Thu, 26 Feb 2026 12:57:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=81.70.192.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772110676; cv=none; b=rIfq3HFa4SBWuzpDdJ8QupoPexWrUWso7gV4+CsvfXDJoVvEOiocAzix5kJ6ql4/9E0WUisYjDFU1bpjjYUljBrQ5DpH5eBG6iXcJWxLtFEoeHbC1KyCHlX7b2mx44l5jKFAa3cLRY+dPvdewe3vzo3ZUTH0G7UxxBAXmMCzgVs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772110676; c=relaxed/simple; bh=2JSkUEpzkW7VJiz7+UlVoQ5Ory5yU9CrmtoJXqHlixI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ZXZcyH/a97un/FJ7uU8ZRyiEjIF7LaKOO73YeLNFCVzdy+jX0/9u9zVm3bsdEhtC1L3Geb4cvKgIW8x1bqzPI2mUPHASoHaLb5Oc/aZSEupOux7WYU8hoMat2kYjilEkJRZaB3QoTuOEzKpXB6PjJNsXwp2hgrAqw1Z3FqtVV5A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=honor.com; spf=pass smtp.mailfrom=honor.com; dkim=pass (1024-bit key) header.d=honor.com header.i=@honor.com header.b=TwPizSSA; arc=none smtp.client-ip=81.70.192.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=honor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=honor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=honor.com header.i=@honor.com header.b="TwPizSSA" dkim-signature: v=1; a=rsa-sha256; d=honor.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=To:From; bh=XPQokzKIR4QEBWebfj0SvsNzvMWG4WPoP7HqHEXWzMQ=; b=TwPizSSAdOagw0bRh7x9IGiFjHeSd1U4f84NwrsYKyLjJr8Foe70PHW8i7BQj+zKPj5JA4FlL rcmmpD+aswtkoAFS+xBNWtXQaq7zLngNReFKlH1HKQbjgDVT/QLZGNfJZC+C45XonlFGKnZM/6e a2vPgM3n9JYPmTQVeJCSTrM= Received: from w001.hihonor.com (unknown [10.68.25.235]) by mta22.hihonor.com (SkyGuard) with ESMTPS id 4fMBHD6WPdzYl5nV; Thu, 26 Feb 2026 20:54:16 +0800 (CST) Received: from a015.hihonor.com (10.68.27.88) by w001.hihonor.com (10.68.25.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.27; Thu, 26 Feb 2026 20:57:42 +0800 Received: from w002.hihonor.com (10.68.28.120) by a015.hihonor.com (10.68.27.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.27; Thu, 26 Feb 2026 20:57:42 +0800 Received: from w002.hihonor.com ([fe80::ef6f:d9c5:cf75:d4d3]) by w002.hihonor.com ([fe80::ef6f:d9c5:cf75:d4d3%14]) with mapi id 15.02.2562.027; Thu, 26 Feb 2026 20:57:42 +0800 From: wangzicheng To: Barry Song <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "linux-mm@kvack.org" CC: "linux-kernel@vger.kernel.org" , Barry Song , Suren Baghdasaryan , Lei Liu , "Matthew Wilcox (Oracle)" , Axel Rasmussen , Yuanchu Xie , Wei Xu , Kairui Song , Tangquan Zheng , wangtao Subject: RE: [PATCH RFC] mm/mglru: lazily activate folios while folios are really mapped Thread-Topic: [PATCH RFC] mm/mglru: lazily activate folios while folios are really mapped Thread-Index: AQHcprbIkLI8koBjtkqDPEnVc1b3J7WU7U8w Date: Thu, 26 Feb 2026 12:57:42 +0000 Message-ID: <2558f7d82b9a482387960f45409e1b76@honor.com> References: <20260225223712.3685-1-21cnbao@gmail.com> In-Reply-To: <20260225223712.3685-1-21cnbao@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 > -----Original Message----- > From: Barry Song <21cnbao@gmail.com> > Sent: Thursday, February 26, 2026 6:37 AM > To: akpm@linux-foundation.org; linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org; Barry Song ; > wangzicheng ; Suren Baghdasaryan > ; Lei Liu ; Matthew Wilcox > (Oracle) ; Axel Rasmussen > ; Yuanchu Xie ; Wei > Xu ; Kairui Song ; Tangquan > Zheng > Subject: [PATCH RFC] mm/mglru: lazily activate folios while folios are re= ally > mapped >=20 > From: Barry Song >=20 > MGLRU activates folios when a new folio is added and > lru_gen_in_fault() returns true. The problem is that when a > page fault occurs at address N, readahead may bring in many > folios around N, and those folios are also activated even > though many of them may never be accessed. >=20 > A previous attempt by Lei Liu proposed introducing a separate > LRU for readahead[1], but that approach is likely over-designed. >=20 > This patch instead activates folios lazily, only when they are > actually mapped, so that unused folios do not occupy higher- > priority positions in the LRU and become harder to reclaim. >=20 > A similar optimization could also be applied to swapin readahead, > but this RFC limits the change to file-backed folios for now. >=20 > Based on Tangquan's observations, this can significantly reduce > file refaults on Android devices when using MGLRU. >=20 > BTW, it seems somewhat odd that all LRU APIs are defined in > swap.c and swap.h. >=20 > [1] https://lore.kernel.org/linux-mm/20250916072226.220426-1- > liulei.rjpt@vivo.com/ >=20 > Cc: wangzicheng > Cc: Suren Baghdasaryan > Cc: Lei Liu > Cc: Matthew Wilcox (Oracle) > Cc: Axel Rasmussen > Cc: Yuanchu Xie > Cc: Wei Xu > Cc: Kairui Song > Cc: Tangquan Zheng > Signed-off-by: Barry Song > --- > include/linux/swap.h | 1 + > mm/filemap.c | 2 ++ > mm/swap.c | 16 +++++++++++++++- > 3 files changed, 18 insertions(+), 1 deletion(-) >=20 > diff --git a/include/linux/swap.h b/include/linux/swap.h > index 62fc7499b408..ce88ec560527 100644 > --- a/include/linux/swap.h > +++ b/include/linux/swap.h > @@ -335,6 +335,7 @@ void folio_add_lru(struct folio *); > void folio_add_lru_vma(struct folio *, struct vm_area_struct *); > void mark_page_accessed(struct page *); > void folio_mark_accessed(struct folio *); > +void folio_activate_on_mapped(struct folio *folio); >=20 > static inline bool folio_may_be_lru_cached(struct folio *folio) > { > diff --git a/mm/filemap.c b/mm/filemap.c > index 6cd7974d4ada..0b8f383facdb 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -3567,6 +3567,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) > } > } >=20 > + folio_activate_on_mapped(folio); > if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin)) > goto out_retry; >=20 > @@ -3926,6 +3927,7 @@ vm_fault_t filemap_map_pages(struct vm_fault > *vmf, > nr_pages, &rss, &mmap_miss, > file_end); >=20 > folio_unlock(folio); > + folio_activate_on_mapped(folio); > } while ((folio =3D next_uptodate_folio(&xas, mapping, end_pgoff)) !=3D > NULL); > add_mm_counter(vma->vm_mm, folio_type, rss); > pte_unmap_unlock(vmf->pte, vmf->ptl); > diff --git a/mm/swap.c b/mm/swap.c > index bb19ccbece46..e50b1e794ef1 100644 > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -488,6 +488,19 @@ void folio_mark_accessed(struct folio *folio) > } > EXPORT_SYMBOL(folio_mark_accessed); >=20 > +void folio_activate_on_mapped(struct folio *folio) > +{ > + if (lru_gen_enabled() && lru_gen_in_fault() && > + !(current->flags & PF_MEMALLOC) && > + !folio_test_active(folio) && > + !folio_test_unevictable(folio)) { > + if (folio_test_lru(folio)) > + folio_activate(folio); > + else /* still in lru cache */ > + __lru_cache_activate_folio(folio); > + } > +} > + > /** > * folio_add_lru - Add a folio to an LRU list. > * @folio: The folio to be added to the LRU. > @@ -506,7 +519,8 @@ void folio_add_lru(struct folio *folio) > /* see the comment in lru_gen_folio_seq() */ > if (lru_gen_enabled() && !folio_test_unevictable(folio) && > lru_gen_in_fault() && !(current->flags & PF_MEMALLOC)) > - folio_set_active(folio); > + if (!folio_is_file_lru(folio)) > + folio_set_active(folio); >=20 > folio_batch_add_and_move(folio, lru_add); > } > -- > 2.39.3 (Apple Git-146) Hi Barry, Setting only non-filelru-folio in folio_add_lru looks reasonable and should help with over-protecting readahead pages that are never actually accessed. For our workloads that already suffer from file under-protection, we see tw= o sides here: on the positive side, keeping only actually-used readahead page= s in memory could improve performance; on the other hand, since we already see file under-protect issues, it's not clear whether this change might exacerbate that or even hurt performance. We'll test this when available and report back. We hope to have a chance to discuss this topic at LSF/MM/BPF. Thanks, Zicheng