Re: [External] Re: [PATCH v2] writeback, memcg: skip foreign dirty tracking for bdev inodes

[Julian Sun <sunjunchao@bytedance.com>]

On 9/4/26 4:29 AM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Sep 03, 2026 at 04:33:03PM +0800, Julian Sun wrote:
>> Foreign dirty flushing handles cases where a dirtied folio's memcg and
>> the memcg owning its inode wb differ.
>>
>> wbc_detach_inode() notes that "concurrent write sharing of an inode is
>> expected to be very rare". This expectation does not hold for bdev inodes.
>> A bdev inode and mapping are shared by buffered users of the block device,
>> while the inode has a single wb owner. On ext4, buffer-cache folios used
>> by metadata and journal I/O can therefore be charged to different memcgs
>> while sharing the same mapping. Normal bdev activity can thus produce
>> frequent folio/wb ownership mismatches.
>>
>> This was reproduced on cgroup v2 with the memory and I/O controllers
>> enabled, using ext4 on a loop device. jbd2 repeatedly generated
>> track_foreign_dirty events for bdev folios charged to unrelated memcgs.
>> When one of those memcgs entered dirty throttling, the resulting record led
>> to a flush_foreign event and queued writeback with reason=foreign_flush for
>> the bdev inode's root wb.
> 
> Was this reproduced from an actual workload with adverse effects? If so, can
> you please explain the workload and effects with concrete details?

Yes, this can be reproduced on many production machines. On one 
production machine, we observed 102 wb works with 
WB_REASON_FOREIGN_FLUSH as their reason, 101 of which belonged to the 
same wb. This wb was the owner of the bdev inode, and dirty pages were 
continuously being generated for it.

The logic here is that, Once a memcg has recorded the owner wb of a bdev 
inode as foreign, any task in that memcg that reaches the throttling 
path in balance_dirty_pages() may queue one WB_REASON_FOREIGN_FLUSH work 
item for each recently recorded foreign wb, up to four in total, without 
checking whether those target wbs caused the current dirty throttling.

On this machine, the total nr_pages of the foreign-flush works was 
630,681,285, or about 2.4 TiB, while the machine had only 400 GiB of 
memory. Although nr_pages does not represent the number of dirty pages 
that will ultimately be written back, the actual number of pages written 
back may still be very large because the corresponding wb was 
continuously accumulating dirty pages.

> 
>> Skip foreign dirty tracking when the folio mapping's host inode is on the
>> blockdev pseudo superblock. This prevents bdev-originated records from
>> triggering later foreign flushes.
> 
> If you do this, tho, that means now cgroups that accumulated a lot of
> metadata writes on ext4 and crunched for memory don't have a way to relieve
> the pressure outside of periodic or other lucky flushes. ie. I have a hard
> time judging whether this is net plus or not without learning more about how
> this patch came to be.

How about this approach? Before queuing a WB_REASON_FOREIGN_FLUSH work 
item, check the target wb and avoid queuing another one if it already 
has an unfinished WB_REASON_FOREIGN_FLUSH work item.

This approach can eliminate a large number of duplicate foreign flushes, 
but one issue remains: a memcg may dirty only a small number of pages in 
a bdev inode, and when that memcg enters dirty throttling, the 
throttling may be completely unrelated to the wb that owns the bdev 
inode, yet a foreign flush is still queued to that wb. This problem 
becomes more pronounced when the wb has a large number of dirty pages. 
Perhaps we should track the number of foreign pages in the memcg and 
avoid issuing a foreign flush when the number is below a certain 
percentage?

> 
> Thanks.
> 

Thanks,
-- 
Julian Sun <sunjunchao@bytedance.com>