From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 BC92F184 for ; Thu, 23 Jul 2026 02:27:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784773623; cv=none; b=uK4+hVetJJ6ourgwq05kQBgl6MIgWkU7BRnPMqH5Zjc5KKb9GeeCWAKLucAqzPqumNqC6Aehu1oy4XnmOBMEC4atldyLQRvWlD8+ZkJyjlWofp6pKKTBh09MGVHwM55V3Jbq+p3Xgth9WoHc4DTht2rDy8Xd5pO5MPb9Web/WaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784773623; c=relaxed/simple; bh=kI4v0Gc/+68miQejFWjw8ZXCsAG43dX5i9CvEhELo58=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DELk64+V9JKNk13MY7ielRtLFJWwIGnbp1F341iisA04Syk2672o1D8o54SXGhaZuWXI66Ycoi8vKv2WkoX/g/LXlZ5GufnpJ4++07Zo8oKgIFbxNc86r4bgRm2uhGfFm3iZtmZPbkgweuowSPSb2IwktzebqqcpRSeImDk4b+4= 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=W+yfMqsu; arc=none smtp.client-ip=115.124.30.133 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="W+yfMqsu" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1784773612; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=jLbZtzCxthaNWVF5N0W4ct6DQK9Fm8OY2JCZO3GLGxo=; b=W+yfMqsuVrYlmKbMoN/9ks9NS8loSTnpP815XKJHRWV2w7hTJWuAsMu65iVkARgahR3Drx8zw814cI+FH4T8kwqcH2cYgHm9qWDnwVMQcZzV7cGlr1E/I1p8LDbydtnLM3h4Szs8+7DqOI6e7QZzvxc1e876+S26uEfX/2NTrko= 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-contentspam033032089153;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X7eY5qR_1784773606; Received: from 30.15.245.94(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X7eY5qR_1784773606 cluster:ay36) by smtp.aliyun-inc.com; Thu, 23 Jul 2026 10:26:50 +0800 Message-ID: Date: Thu, 23 Jul 2026 10:26:38 +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 v4 3/3] mm: mglru: promote mapped executable folios after first usage To: Barry 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, kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, mhocko@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/26 4:31 PM, Barry Song wrote: > On Mon, Jul 20, 2026 at 7:12 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 >> >> Signed-off-by: Baolin Wang >> Acked-by: Johannes Weiner >> Reviewed-by: Axel Rasmussen >> --- >> mm/vmscan.c | 43 +++++++++++++++++++++++++++---------------- >> 1 file changed, 27 insertions(+), 16 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 8f0c31a4848e..b1ec65fb8947 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -841,10 +841,16 @@ 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)) { >> + /* Activate file-backed executable folios after first usage. */ >> + if (is_exec_file_folio(folio, vma_flags)) { >> + set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, BIT(PG_workingset)); >> + return true; >> + } >> + > > Hi Baolin, > > Do you see any performance difference if you change the code to > something like the following? > > -static bool lru_gen_set_refs(struct folio *folio) > +static bool lru_gen_set_refs(struct folio *folio, const vma_flags_t *vma_flags) > { > + /* Activate file-backed executable folios after first usage. */ > + if (is_exec_file_folio(folio, vma_flags)) { > + set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, > BIT(PG_workingset)); > + return true; > + } I tried that, and there was no obvious difference. I think the original logic also promotes the exec folio when it is accessed again, so I prefer to keep the same logic as folio_update_gen(). As I mentioned earlier[1], lru_gen_set_refs() needs some rework, and I'll think about how to optimize this function later. [1] https://lore.kernel.org/all/eb395442-0aad-428a-a5ac-9072d2d89060@linux.alibaba.com/