diff options
| author | Boris Burkov <boris@bur.io> | 2026-09-15 10:58:32 -0700 |
|---|---|---|
| committer | David Sterba <dsterba@suse.com> | 2026-10-12 19:16:21 +0200 |
| commit | e0c9d01770ef56792fbb2947128e5f43f7d49c61 (patch) | |
| tree | 22226676d08085b2bdc7d2dc46aeca36e46fd8da /tools/perf/scripts/python/stackcollapse.py | |
| parent | 220c44b1b90fbff746472cbb3dde778b02afbef9 (diff) | |
| download | linux-e0c9d01770ef56792fbb2947128e5f43f7d49c61.tar.gz linux-e0c9d01770ef56792fbb2947128e5f43f7d49c61.zip | |
btrfs: skip unlocked reflink source flush if the inode has writers
The optimistic unlocked flushing is counter-productive if there is an
active writer dirtying pages, as it results in doubly writing back any
pages that get dirtied again before the locked flush. Therefore,
pessimize it slightly and don't do the unlocked flushing if we have
outstanding writable file descriptors or memory mappings. Since the
inode isn't locked, this is only advisory, any new mapping or fd that
sneaks in after the check but before the locking can still cause extra
writeback. But it trivially helps quite a bit in simple cases with a
long open file descriptor or mapping.
I tested this with two similar workloads. One was keeping and fd open
and doing continuous writes into the src file while cloning it and doing
lseek on it and the other was slightly meaner, constantly opening and
closing the fd to try to race this check.
Workload 1 shows a huge regression in write amplification and writers
and readers who experience userspace wall time stalls of 100ms+ with
just the pre-flush, but recovers to normal with this check.
Workload 2 is a smaller regression which is mostly helped but not fully
resolved with this check. So we must weigh this regression against the
benefit of the unlocked flush in the allegedly more common simpler case.
Workload 1: fd kept open, 60s of clone/write/lseek looping.
kernel clones clone mean s device MiB/clone writer stalls reader stalls
for-next 564 0.095 119 10 10
pre-flush (p1) 179 0.338 405 94 93
skip (p1+p2) 540 0.100 116 9 9
Workload 2: same writer, but closing and reopening the fd around each
64 MiB write with some random sleeping to encourage racing.
kernel clones clone mean s device MiB/clone writer stalls reader stalls
for-next 740 0.070 83 9 9
pre-flush (p1) 255 0.224 246 27 26
skip (p1+p2) 518 0.107 121 11 11
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
