From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (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 2256F32D7F8 for ; Tue, 25 Aug 2026 09:06:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787648814; cv=none; b=WPX3ZXbc0kTGIl3h2O0HeK6ZCXyJUPs4teFvM5sBYp02Ht2IiQjBIp5F9QG5A4IpadIF5OY8AXZCN8r5axKuYwGbpPDsKDAcnBR+ed3JtX2xzCSy2GddrRW8CoK5Ff261wr8ku3sot1uwh1r1P3m9m7ZZ4VcCHKCMbLQPNOruR4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787648814; c=relaxed/simple; bh=/t2QuBXahfWod3MSGijVimz3WXrAoHFrKjpL+CNuWD0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hqPJtmewQDb8pVTRP06WpQwxNSRmCSmZyXEkdbjn9eyfPChdKNIlHO1f444V+lGm0yO//xDOF9UmcrGvu89oHqbFlG9X4dAAb9admA+sfZ5xEzJEGlMidYvmmuvBUW23fZmAp7nxLdLfLN110DeTP3TXdtJiVzCdDdtY78N7wwQ= 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=q0bICao7; arc=none smtp.client-ip=115.124.30.119 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="q0bICao7" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787648799; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6GiVTcUoBcFpdAwmhaGD/yA7QuBQ8y/b4/H/dtTDhjQ=; b=q0bICao7cIUSDPn91uJ7oOZFr+YVIjinTKKKEhZkmsYQ0/D5vpSg1zRwx9w5LogzQY/lUQjWtqr2mU8EfmGkhDscPZN8QS3yPtf5NKE50NoYG2Xv94ZZO+gF3fu8BSjmbp6dqke24txXHxRFA/msRxuLvnnMi/UOoHiOrJrcSRc= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X9dMVJl_1787648796; Received: from 30.74.144.118(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X9dMVJl_1787648796 cluster:ay36) by smtp.aliyun-inc.com; Tue, 25 Aug 2026 17:06:37 +0800 Message-ID: <56b8e283-f849-4fd7-9c2a-64b604176a82@linux.alibaba.com> Date: Tue, 25 Aug 2026 17:06:36 +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 0/3] mm/mglru: clean up isolate_folios and scan_folios for readability and clarity To: Kairui Song Cc: "Barry Song (Xiaomi)" , akpm@linux-foundation.org, linux-mm@kvack.org, axelrasmussen@google.com, baoquan.he@linux.dev, chenridong@xiaomi.com, david@kernel.org, hannes@cmpxchg.org, lianux.mm@gmail.com, linux-kernel@vger.kernel.org, ljs@kernel.org, lyugaofei@xiaomi.com, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, stevensd@chromium.org, wangzicheng@honor.com, weixugc@google.com, yuanchu@google.com References: <20260820045603.68809-1-baohua@kernel.org> <7e897a4e-2075-485a-8cc5-5bb928fba437@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/24/26 7:05 PM, Kairui Song wrote: > On Mon, Aug 24, 2026 at 3:25 PM Baolin Wang > wrote: >> On 8/20/26 12:56 PM, Barry Song (Xiaomi) wrote: >>> This is a cleanup series split out from the MGLRU swappiness series [1], >>> with the cleanup changes separated to make them easier to review. >>> >>> Right now, isolate_folios() is quite difficult to follow: >>> >>> 1. It uses for_each_evictable_type(i, swappiness) to iterate over the >>> types, but i is not actually used as the type within the loop body. >>> >>> 2. It uses scanned == 0 to detect whether the current reclaim type is >>> exhausted, but this is not an accurate indication. >>> >>> 3. It has an internal retry when no folios can be isolated after scanning >>> some folios, but the retry is implemented in a way nobody can understand. >>> >>> This patchset makes these behaviors explicit and much easier to follow. >>> >>> Run kernel builds for several rounds in a 1 GB memcg and take the >>> average build time. The patchset shows almost no performance impact, >>> with a very small improvement that could simply be noise: >> >> Just FYI: >> >> I tested this patchset with a 3G memcg limit and a 10G zram device, >> running 'make -j32' to build kernel on my 32-core Arm machines, and got >> some performance improvement for ths sys time: >> w/o patch w/patch >> sys 1845s 1570s >> > > Hi Baoliln > > That's a very interesting result, can you share a bit more info about > it? e.g. vmstat? I'm curious how this happens. Sure. > I suspect patch 2 or 3 changes the swappiness / reclaim / aging type > selection behavior, or maybe it reduced the reclaim amount? I gathered the memcg stats as shown below. It looks like the direct reason for the performance improvement is an obvious reduction in anon refaults, which is what this patch aims to achieve I think. That is to say, we should respect the type chosen by the PID for reclaim, and try to exhaust that type before falling back to another. Before this series: workingset_refault_anon 59706846 workingset_refault_file 9229283 workingset_activate_anon 15108561 workingset_activate_file 365660 workingset_restore_anon 15108561 workingset_restore_file 1018493 workingset_nodereclaim 0 pgsteal_kswapd 0 pgsteal_direct 92589340 pgsteal_khugepaged 549 pgsteal_proactive 0 pgscan_kswapd 0 pgscan_direct 456629355 pgscan_khugepaged 549 After this series: workingset_refault_anon 41277086 workingset_refault_file 9131522 workingset_activate_anon 12924656 workingset_activate_file 345901 workingset_restore_anon 12924656 workingset_restore_file 1005959 workingset_nodereclaim 0 pgsteal_kswapd 0 pgsteal_direct 71723800 pgsteal_khugepaged 4013 pgsteal_proactive 0 pgscan_kswapd 0 pgscan_direct 342179445 pgscan_khugepaged 9311