summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorQu Wenruo <wqu@suse.com>2024-09-16 08:03:00 +0930
committerDavid Sterba <dsterba@suse.com>2024-11-11 14:34:12 +0100
commit2bca8eb0774d271b1077b72f1be135073e0a898f (patch)
treed81ab72525725c517aafdcd936d55ce840497eda /tools/perf/scripts/python/export-to-postgresql.py
parent928b4de66ed3b0d9a6f201ce41ab2eed6ea2e7ef (diff)
btrfs: move the delalloc range bitmap search into extent_io.c
Currently for subpage (sector size < page size) cases, we reuse subpage locked bitmap to find out all delalloc ranges we have locked, and run all those found ranges. However such reuse is not perfect, e.g.: 0 32K 64K 96K 128K | |////////||///////| |////| 120K For above range, writepage_delalloc() for page 0 will handle the range [32K, 96k), note delalloc range can be beyond the page boundary. But writepage_delalloc() for page 64K will only handle range [120K, 128K), as the previous run on page 0 has already handled range [64K, 96K). Meanwhile for the writeback we should expect range [64K, 96K) to also be locked, this leads to the mismatch from locked bitmap and delalloc range. This is not causing problems yet, but it's still an inconsistent behavior. So instead of relying on the subpage locked bitmap, move the delalloc range search using local @delalloc_bitmap, so that we can remove the existing btrfs_folio_find_writer_locked(). Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions