Message ID | 20200722112901.15626-1-fdmanana@kernel.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [1/3] btrfs: fix race between page release and a fast fsync | expand |
On Wed, Jul 22, 2020 at 12:29:01PM +0100, fdmanana@kernel.org wrote: > Before patchset: > > WRITE: bw=98.8MiB/s (104MB/s), 98.8MiB/s-98.8MiB/s (104MB/s-104MB/s), io=64.0GiB (68.7GB), run=663126-663126msec > > After patchset: > > WRITE: bw=294MiB/s (308MB/s), 294MiB/s-294MiB/s (308MB/s-308MB/s), io=64.0GiB (68.7GB), run=222940-222940msec > (+197.6% throughput, -66.4% run time) That's really great, thank you very much!
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 5eab129e6eb0..f6837a6fe464 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -4530,8 +4530,14 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) if (em->generation >= cur_gen) goto next; remove_em: - set_bit(BTRFS_INODE_NEEDS_FULL_SYNC, - &btrfs_inode->runtime_flags); + /* + * We only remove extent maps that are not in the list of + * modified extents or that are in the list but with a + * generation lower then the current generation, so there + * is no need to set the full fsync flag on the inode (it + * hurts the fsync performance for workloads with a data + * size that exceeds or is close to the system's memory). + */ remove_extent_mapping(map, em); /* once for the rb tree */ free_extent_map(em);