From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (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 2D0701E2834 for ; Mon, 20 Jul 2026 01:41:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784511707; cv=none; b=Ec9DJTBtUCKHZz4gZD3ugze/cQTBqGyMmTsYnz7147LPlMG6GYbm5S1Sbh6Y+A5GVDB2IMxrmVZuTH0tCROdF70iLKti6Zc0nucIp2X3x6ZD8ClMhX0SMHiHjM5cX8K4P9/SanKKgiQ0fW1vBmtU3Cy5xDqk7QAjTe+UARyev+s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784511707; c=relaxed/simple; bh=9lnSNvhNjWuXoxSTuBXfGeCjxeev/bPM+lBHrebCf+c=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=qidCX5zrGnoVyAMPJuC7AK2GqiFEGh/LiFIdUwUyePOcD5zDLKxlcQpiT5dhAofz/zP+h9uSneG8fdEULOsUlLQfPTp7e/rZ42U8WHX+52SzIZeIM9sFiwqsC/nG4Oc81sdvfZTncHgjb3F9UlAD0z6ZUtk9pxbBvdyMlA35NMo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=iCMNUkUf; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="iCMNUkUf" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1784511695; h=Message-ID:Date:MIME-Version:Subject:From:To:Content-Type; bh=R+0AGqwHLeIrrds4xiDUsGuVUjee2WmZWQHT4y4URdc=; b=iCMNUkUfDAdqLC91M47a2QeZaAOf70XbcYtUfhB5J99NlEwdeF4coJaAM/TUw8lCgjIrvmYL9bZ9PDUxir67GVIvTLpjChuzzmYRgxI4IQjS9Uwk+7BgvMRmdWKVymcBjZqkQAbRBsDsF8EcNNYy97iQXXSerb2qWZjxXzES2SU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X7N2CD2_1784511691; Received: from 30.120.38.205(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X7N2CD2_1784511691 cluster:ay36) by smtp.aliyun-inc.com; Mon, 20 Jul 2026 09:41:33 +0800 Message-ID: Date: Mon, 20 Jul 2026 09:41:30 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] mm: mglru: promote mapped executable folios after first usage From: Baolin Wang To: Kairui Song Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, hannes@cmpxchg.org, riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, mhocko@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <7db4d1975cf04e3e48157f98bdf398565ee189a4.1784268206.git.baolin.wang@linux.alibaba.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/19/26 9:45 AM, Baolin Wang wrote: > > > On 7/19/26 3:23 AM, Kairui Song wrote: >> On Fri, Jul 17, 2026 at 6:06 PM Baolin Wang >> wrote: >>> >>> Classical LRU protects mapped executable file folios through commit >>> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class >>> citizen") and commit c909e99364c8 ("vmscan: activate executable pages >>> after first usage"), giving executable code a better chance to stay in >>> memory, avoiding IO thrashing and improving workload performance. >>> >>> However, MGLRU's protection of mapped executable file folios is less >>> reliable. Although shrink_folio_list() checks references, the access >>> flag >>> of mapped executable file folios may have already been checked and >>> cleared by lru_gen_look_around() or walk_mm(). Additionally, >>> folio_update_gen() or lru_gen_set_refs() only sets the 'PG_referenced' >>> flag for mapped executable file folios, which causes shrink_folio_list() >>> to ignore the first usage of these mapped executable file folios and >>> reclaim them easily. >>> >>> Follow the classical LRU's logic, promoting mapped executable file >>> folios >>> after their first usage in folio_update_gen() and lru_gen_set_refs(), >>> giving executable code a better chance to stay in memory. >>> >>> On my 32-core Arm machine, with the memcg limit set to 2G, running >>> 'make -j32' to build kernel showed some improvement in sys time. >>> >>> base                    patched >>> 9248.543s               7861.579s >>> >>> While we are at it, introduce a new helper to check mapped executable >>> file folios. >>> >>> Signed-off-by: Baolin Wang >>> --- >>>   mm/vmscan.c | 47 +++++++++++++++++++++++++++++++---------------- >>>   1 file changed, 31 insertions(+), 16 deletions(-) >> >> Hi Baolin, thanks for the update, looks good to me with two nit picks: >>> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>> index de62899c108d..1040bf9f96e8 100644 >>> --- a/mm/vmscan.c >>> +++ b/mm/vmscan.c >>> @@ -268,6 +268,12 @@ static int sc_swappiness(struct scan_control >>> *sc, struct mem_cgroup *memcg) >>>   } >>>   #endif >>> >>> +static inline bool is_exec_file_folio(const struct folio *folio, >>> +               const vma_flags_t *vma_flags) >>> +{ >>> +       return vma_flags_test(vma_flags, VMA_EXEC_BIT) && >>> folio_is_file_lru(folio); >>> +} >>> + >>>   static void set_task_reclaim_state(struct task_struct *task, >>>                                     struct reclaim_state *rs) >>>   { >>> @@ -835,11 +841,15 @@ enum folio_references { >>>    * with PG_active set. In contrast, the aging (page table walk) >>> path uses >>>    * folio_update_gen(). >>>    */ >>> -static bool lru_gen_set_refs(struct folio *folio) >>> +static bool lru_gen_set_refs(struct folio *folio, const vma_flags_t >>> *vma_flags) >>>   { >>>          /* see the comment on LRU_REFS_FLAGS */ >>>          if (!folio_test_referenced(folio) && ! >>> folio_test_workingset(folio)) { >>>                  set_mask_bits(&folio->flags.f, LRU_REFS_MASK, >>> BIT(PG_referenced)); >>> +               /* Activate file-backed executable folios after first >>> usage. */ >>> +               if (is_exec_file_folio(folio, vma_flags)) >>> +                       return true; >>> + [snip] > Additionally, I think Barry's earlier patch[2] also has an issue: when > lru_gen_set_refs() returns true to promote the folio, we should also > clear LRU_REFS_FLAGS, rather than calling folio_mark_accessed(). So in > my opinion, when we call folio_mark_accessed(), we should return false > and should not promote the folio, so the logic shoule be: > > static bool lru_gen_set_refs(struct folio *folio) > { >     /* see the comment on LRU_REFS_FLAGS */ >     if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) { >         set_mask_bits(&folio->flags.f, LRU_REFS_MASK, BIT(PG_referenced)); >         return false; >     } > >     /* Promote on second access */ >     if (folio_lru_refs(folio) > 1) { >         set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, > BIT(PG_workingset)); >         return true; >     } > >     folio_mark_accessed(folio); >     return false; > } > > What do you think? I'd like to send a fix first to correct the logic here. I tested this fix for Barry's patch and see some performance regression. I'll think more about how to fix it.