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

[Baolin Wang]

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@xxxxxxxxxxxxxxxxx/T/#u