Re: [PATCH 0/2] mm, iomap: account dirty at page granularity for per-block dirty folios

[Jan Kara]

On Tue 27-10-26 13:59:59, Pedro Falcato wrote:
> On Tue, Oct 27, 2026 at 11:27:00AM +0000, Salvatore Dipietro wrote:
> > Since iomap gained per-block dirty tracking, a large folio can be
> > partially dirty: struct iomap_folio_state records exactly which
> > blocks are dirty, and writeback only writes those ranges.  The mm
> > dirty accounting, however, still charges the whole folio even if a
> > single block is dirty (up to 512x over-accounting for a 2 MB folio
> > over 4 KB blocks).
> > 
> > balance_dirty_pages() then throttles writers against a number that
> > is unrelated to how much data actually needs writing back.  On
> > workloads that repeatedly dirty small ranges of large folios --
> > e.g. PostgreSQL, which writes mostly 8/16 KB pages -- dirty_thresh
> > is crossed and writers are throttled long before the real dirty data
> > justifies it.  On the benchmark below, run on v7.3-rc7, the
> > unpatched kernel charges ~159 TB of dirtied pages while writing
> > ~6 TB to the array, a factor of 27; with this series the dirtied
> > pages charged match the data actually written.
> > 
> > This series makes iomap charge and discharge the mm dirty counters
> > per dirty page for folios that carry per-block dirty state, so a
> > partially dirty large folio is accounted for the dirty part only:
> 
> Why? This looks wrong. Yes, you may only have dirtied e.g 4K out of a 2MB
> folio, but the whole 2MB folio is still effectively pinned by the VM, awaiting
> cleaning + writeback. And that's precisely what we want to measure and
> throttle in certain cases, so that e.g the VM system never finds itself
> short of clean pages it can reclaim, and no easy way to start writeback
> on them.

Fully agree on that. We have already discussed this with Joanne about one
year ago [1]. There are some aspects of dirty accounting that could be made
more finer grained but overall the whole folio is difficult to reclaim due
to dirtiness so accounting it all is the correct approach.

								Honza

[1] https://lore.kernel.org/all/20250829233942.3607248-1-joannelkoong@xxxxxxxxx

-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR