Repository navigation
memcg,writeback: flush foreign bdev mappings separately - #2654
Closed
vfsci-bot[bot] wants to merge 3 commits into
Closed
vfsci-bot[bot] wants to merge 3 commits into
vfsci-bot[bot] wants to merge 3 commits into
Conversation
added 3 commits
September 21, 2026 12:30
Add bdev_flush_by_dev() to submit page-cache writeback for a device identified by dev_t without requiring callers to hold a persistent device reference. A subsequent patch will use this helper to flush foreign bdev mappings. Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
Bdev inodes are routinely shared by multiple memcgs. Recording their owner wb as foreign can flush unrelated file data when a source memcg enters dirty throttling. Record bdev device numbers separately and queue work on memcg_bdev_frn_flusher to write only their mappings. Keep the existing foreign-wb mechanism for non-bdev inodes. Use fixed per-memcg slots. Tracking is best effort: record only dev_t without holding device or inode references. Records are updated under the mapping->i_pages lock with IRQs disabled, but dropping a bdev reference can sleep. Also, since foreign flushes are triggered by dirty throttling, a memcg that never throttles could retain an unused record and pin the device object indefinitely. Recording only dev_t avoids these lifetime constraints, but device removal and device-number reuse may race with lookup. Such races are expected under the best-effort semantics. Bdev writeback submission can block for a long time on congested devices, with up to four work items outstanding per memcg. Use a dedicated unbound workqueue to give these flushes a separate max_active budget, so they do not exhaust a shared workqueue's active slots and delay unrelated work. If allocation fails, retain the existing foreign-wb path. This primarily affects filesystems that keep metadata in the bdev page cache, such as ext4 and other buffer_head users, rather than the usual metadata writeback paths of XFS and Btrfs. The decision still does not account for how much of the memcg's dirty memory belongs to the bdev. Even a single dirty bitmap block can trigger writeback of the entire bdev mapping when the memcg enters dirty throttling. Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
Add dev to track_foreign_dirty and flush_foreign so traces can distinguish foreign-wb tracking from the bdev-only path. Append the field to each event and print it as major:minor; zero denotes the normal foreign-wb path. Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
Author
|
Superseded by series 1171329 (v8). Closing automatically. Automated by ml2pr |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Series: https://patchwork.kernel.org/project/linux-fsdevel/list/?series=1170341
Submitter: Julian Sun
Version: 7
Patches: 3/3
Message-ID:
<20260921120658.1627992-1-sunjunchao@bytedance.com>Base: vfs.base.ci
Lore: https://lore.kernel.org/linux-fsdevel/20260921120658.1627992-1-sunjunchao@bytedance.com
Automated by ml2pr