From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (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 3C87F26ED59 for ; Thu, 16 Jul 2026 02:30:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784169035; cv=none; b=aohfrVEtLmJuhbiQJKQ3R7Wuf+cmegTXp75O14N1pw1dtP3TTI8uoEdUzRapx1PVFPxy91FP5ncfwgkBnXwFDJFAq07sRc5/4gbVx2gm3SVsEPJg4lq9J3V0uxxuEQGf9tCd/XS3ic1qe04ihKjSVQVMoGVGTYCC4phEJL836s4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784169035; c=relaxed/simple; bh=2utVMrqOTbvhtP3QKRqswVnfB66uglIHrl6FbgRct+c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YQyJy1gS0P8IqDd/eORBs+aW5Qx2sETY4BpgD1p7O8MEilJpTpVbKtV52671gBc01uQ6GQ5QAd58a7VnxfXU0dPFswv4MuA8XE5ivOYUwY2UDKKUgtZZ3iW4DBv8cSo/fncBQkEPUzlEa2qIySi7Xg164jF+ZfBA0yG4HXvBjnM= 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=e8F2dygo; arc=none smtp.client-ip=115.124.30.98 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="e8F2dygo" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1784169029; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=LNqDS6Sst+3PphAHyUf5zrIect6KbXwTAMVNSLXGdEo=; b=e8F2dygo6BebbS888qb2MuEfB1wwtHyK4YNXfpZkvt0jteBPLo0HfjJKhy+8cmrBVZQrjiQSVEa2oBTG/UATYZnD/rm7FqPYnKTsNB7OCbghTYxfVtkJjoM7h0RKvpV24XZkQFJnHXkIO3HB0Z5hmsparmkU8c8k/kLfSdH/IfU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R521e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0X7B-Pz1_1784169028; Received: from 30.74.144.123(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X7B-Pz1_1784169028 cluster:ay36) by smtp.aliyun-inc.com; Thu, 16 Jul 2026 10:30:28 +0800 Message-ID: <4067606d-2b39-4b17-a3c6-be8f09c6bf96@linux.alibaba.com> Date: Thu, 16 Jul 2026 10:30:27 +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] mm: mglru: promote mapped executable folios after first usage To: Kairui Song Cc: akpm@linux-foundation.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, david@kernel.org, mhocko@kernel.org, ljs@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <4b921ed528c483e13c9e22d1ae44ba58b4a15b0b.1784096432.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/16/26 12:50 AM, Kairui Song wrote: > On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang > wrote: > > Hi Baolin, >> >> 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. > > That's really a long history for those two commits :) >> >> 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() 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. >> >> Follow the classical LRU's logic, promoting mapped executable file folios >> after their first usage in folio_update_gen(), giving executable code a >> better chance to stay in memory. > > Yeah I think that's mostly an ideology issue, recently upstream tends > to treat all folios fairly if there is no particular reason. > Personally I also agree that some folios are more special compared to > other though. OK. >> 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 >> --- >> mm/vmscan.c | 25 +++++++++++++++---------- >> 1 file changed, 15 insertions(+), 10 deletions(-) > > MGLRU used to favor and put all map faulted memory at head, so could > this be related to a recent change in any way? > https://lore.kernel.org/linux-mm/20260526130938.66253-1-baohua@kernel.org/ I haven't tested Barry's patch yet. Personally, I don't think this is closely related to Barry's patch. Though we put the faulted folios into the secound youngest gen before, after aging, the mapped exec folios are still not protected like in Classical LRU, and can be easily reclaimed. >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 986dde8e7429..429857852bdb 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -3188,7 +3188,7 @@ static bool positive_ctrl_err(struct ctrl_pos *sp, struct ctrl_pos *pv) >> ******************************************************************************/ >> >> /* promote pages accessed through page tables */ >> -static int folio_update_gen(struct folio *folio, int gen) >> +static int folio_update_gen(struct vm_area_struct *vma, struct folio *folio, int gen) >> { >> unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f); >> >> @@ -3196,10 +3196,15 @@ static int folio_update_gen(struct folio *folio, int gen) >> >> /* 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 (vma_test(vma, VMA_EXEC_BIT) && folio_is_file_lru(folio)) >> + goto promote; >> + > > Do you think it's a good idea to extract this into a helper e.g. > folio_is_executable_file? Good point. Will do. Thanks.