linux-kernel - Re: [PATCH v2 2/2] mm: vmscan: simplify the logic for activating dirty file folios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3971f97e-399c-425b-979f-55334eacd925@linux.alibaba.com>
Date: Mon, 20 Oct 2025 15:34:59 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Michal Hocko <mhocko@...e.com>
Cc: akpm@...ux-foundation.org, hannes@...xchg.org, david@...hat.com,
 zhengqi.arch@...edance.com, shakeel.butt@...ux.dev,
 lorenzo.stoakes@...cle.com, hughd@...gle.com, willy@...radead.org,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mm: vmscan: simplify the logic for activating
 dirty file folios



On 2025/10/17 20:02, Michal Hocko wrote:
> On Fri 17-10-25 15:53:07, Baolin Wang wrote:
>> After commit 6b0dfabb3555 ("fs: Remove aops->writepage"), we no longer
>> attempt to write back filesystem folios through reclaim.
>>
>> However, in the shrink_folio_list() function, there still remains some
>> logic related to writeback control of dirty file folios. The original
>> logic was that, for direct reclaim, or when folio_test_reclaim() is false,
>> or the PGDAT_DIRTY flag is not set, the dirty file folios would be directly
>> activated to avoid being scanned again; otherwise, it will try to writeback
>> the dirty file folios. However, since we can no longer perform writeback on
>> dirty folios, the dirty file folios will still be activated.
>>
>> Additionally, under the original logic, if we continue to try writeback dirty
>> file folios, we will also check the references flag, sc->may_writepage, and
>> may_enter_fs(), which may result in dirty file folios being left in the inactive
>> list. This is unreasonable. Even if these dirty folios are scanned again, we
>> still cannot clean them.
>>
>> Therefore, the checks on these dirty file folios appear to be redundant and can
>> be removed. Dirty file folios should be directly moved to the active list to
>> avoid being scanned again. Since we set the PG_reclaim flag for the dirty folios,
>> once the writeback is completed, they will be moved back to the tail of the
>> inactive list to be retried for quick reclaim.
> 
> Is there any actual problem you are trying to address or is this a code
> clean up? How have you evaluated this change?

This patch is more of a cleanup patch, since dirty file folios are also 
activated in pageout(), so there are essentially no significant logical 
changes. Moreover, this patch set is a continuation of the previous 
cleanup work[1] for dirty file folios, and further cleanup and 
optimization work for file folios reclamation is still ongoing.

I conducted some evaluations (such as building the kernel in memcg to 
reclaim file folios and running thpcompact to reclaim file folios), and 
I did not observe any obvious changes in reclaim efficiency.

[1] 
https://lore.kernel.org/all/cover.1758166683.git.baolin.wang@linux.alibaba.com/T/#u