* [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree
@ 2019-03-01 2:45 Qu Wenruo
0 siblings, 0 replies; 4+ messages in thread
From: Qu Wenruo @ 2019-03-01 2:45 UTC (permalink / raw)
To: linux-btrfs
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/ftrace_extent_io_tree
Which is based on v5.0-rc7 tag.
Btrfs uses (almost abuse) extent_io_tree for a lot of operations, e.g:
- Tree block locking
BTRFS_I(btree_inode)->io_tree
- Page status tracing
BTRFS_I(file_inode)->io_tree and BTRFS_I(file_inode)->io_failure_tree
transaction->dirty_pages
- Pinned down extents tracing
fs_info->freed_extents[2]
...
However we don't have any trace events for us to understand how btrfs
works.
This patchset will introduce trace events for
set/clear/convert_extent_bit().
Despite that, there are some other small modifications required:
- Introduce extent_io_tree::fs_info
For trace events to output fsid to distinguish different fs.
This increase the size of extent_io_tree by 8 bytes.
- Allow NULL fs_info for TP_fast_assign_fsid()
There is extent bits operation in selftest which is too deep to pass
fs_info. And since it's in selftest, it shouldn't trigger trace
events.
But to be safe, we still need to check fs_indo in
TP_fast_assign_fsid(), for NULL fs_info, just keep fsid filled with
zero.
- New extent_io_tree::owner
To distinguish different extent io trees. It uses the unpopulated bits
of original trace_uptodate, so it doesn't increase the size of
extent_io_tree.
The output examples and extra notes are: (copied from the 3rd patch)
btrfs_set_extent_bit: <FDID>: io_tree=IO_TREE ino=1 root=1 start=22036480 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22040576 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22044672 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22048768 len=4096 set_bits=LOCKED
btrfs_clear_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22036480 len=16384 clear_bits=LOCKED
^^^ Extent buffer 22036480 read from disc, the locking progress
btrfs_set_extent_bit: <FSID>: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30425088 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30441472 len=16384 set_bits=DIRTY
^^^ 2 new tree blocks allocated in one transaction
btrfs_set_extent_bit: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30523392 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30556160 len=16384 set_bits=DIRTY
^^^ 2 old tree blocks get pinned down
There is one point which need extra attention:
1) Those trace events are pretty heavy
The following workload would generate over 400 trace events.
mkfs.btrfs -f $dev
start_trace
mount $dev $mnt -o enospc_debug
sync
touch $mnt/file1
touch $mnt/file2
touch $mnt/file3
xfs_io -f -c "pwrite 0 16k" $mnt/file4
umount $mnt
end_trace
It's not recommended to use them in real world environment.
Qu Wenruo (3):
btrfs: Introduce fs_info for extent_io_tree
btrfs: Introduce extent_io_tree::owner to distinguish different
io_trees
btrfs: trace: Add trace events for extent_io_tree
fs/btrfs/disk-io.c | 12 ++-
fs/btrfs/extent_io.c | 9 +-
fs/btrfs/extent_io.h | 22 ++++-
fs/btrfs/inode.c | 6 +-
fs/btrfs/relocation.c | 9 +-
fs/btrfs/tests/btrfs-tests.c | 6 +-
fs/btrfs/tests/extent-io-tests.c | 2 +-
fs/btrfs/transaction.c | 4 +-
include/trace/events/btrfs.h | 159 ++++++++++++++++++++++++++++++-
9 files changed, 210 insertions(+), 19 deletions(-)
--
2.21.0
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree
@ 2019-03-01 2:47 Qu Wenruo
2019-03-07 16:32 ` David Sterba
0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2019-03-01 2:47 UTC (permalink / raw)
To: linux-btrfs
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/ftrace_extent_io_tree
Which is based on v5.0-rc7 tag.
Btrfs uses (almost abuse) extent_io_tree for a lot of operations, e.g:
- Tree block locking
BTRFS_I(btree_inode)->io_tree
- Page status tracing
BTRFS_I(file_inode)->io_tree and BTRFS_I(file_inode)->io_failure_tree
transaction->dirty_pages
- Pinned down extents tracing
fs_info->freed_extents[2]
...
However we don't have any trace events for us to understand how btrfs
works.
This patchset will introduce trace events for
set/clear/convert_extent_bit().
Despite that, there are some other small modifications required:
- Introduce extent_io_tree::fs_info
For trace events to output fsid to distinguish different fs.
This increase the size of extent_io_tree by 8 bytes.
- Allow NULL fs_info for TP_fast_assign_fsid()
There is extent bits operation in selftest which is too deep to pass
fs_info. And since it's in selftest, it shouldn't trigger trace
events.
But to be safe, we still need to check fs_indo in
TP_fast_assign_fsid(), for NULL fs_info, just keep fsid filled with
zero.
- New extent_io_tree::owner
To distinguish different extent io trees. It uses the unpopulated bits
of original trace_uptodate, so it doesn't increase the size of
extent_io_tree.
The output examples and extra notes are: (copied from the 3rd patch)
btrfs_set_extent_bit: <FDID>: io_tree=IO_TREE ino=1 root=1 start=22036480 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22040576 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22044672 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22048768 len=4096 set_bits=LOCKED
btrfs_clear_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22036480 len=16384 clear_bits=LOCKED
^^^ Extent buffer 22036480 read from disc, the locking progress
btrfs_set_extent_bit: <FSID>: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30425088 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30441472 len=16384 set_bits=DIRTY
^^^ 2 new tree blocks allocated in one transaction
btrfs_set_extent_bit: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30523392 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30556160 len=16384 set_bits=DIRTY
^^^ 2 old tree blocks get pinned down
There is one point which need extra attention:
1) Those trace events are pretty heavy
The following workload would generate over 400 trace events.
mkfs.btrfs -f $dev
start_trace
mount $dev $mnt -o enospc_debug
sync
touch $mnt/file1
touch $mnt/file2
touch $mnt/file3
xfs_io -f -c "pwrite 0 16k" $mnt/file4
umount $mnt
end_trace
It's not recommended to use them in real world environment.
Changelog:
v2:
- Introduce fs_info to distinguish different btrfs filesystems
- Code style change to make trace code more elegant
- Minor IO_TREE_* naming change.
- Use btrfs_ino() to replace raw inode number.
- Change extent_io_tree::owner declaration to avoid affecting spinlock.
Qu Wenruo (3):
btrfs: Introduce fs_info for extent_io_tree
btrfs: Introduce extent_io_tree::owner to distinguish different
io_trees
btrfs: trace: Add trace events for extent_io_tree
fs/btrfs/disk-io.c | 12 ++-
fs/btrfs/extent_io.c | 9 +-
fs/btrfs/extent_io.h | 22 ++++-
fs/btrfs/inode.c | 6 +-
fs/btrfs/relocation.c | 9 +-
fs/btrfs/tests/btrfs-tests.c | 6 +-
fs/btrfs/tests/extent-io-tests.c | 2 +-
fs/btrfs/transaction.c | 4 +-
include/trace/events/btrfs.h | 159 ++++++++++++++++++++++++++++++-
9 files changed, 210 insertions(+), 19 deletions(-)
--
2.21.0
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree
2019-03-01 2:47 Qu Wenruo
@ 2019-03-07 16:32 ` David Sterba
2019-03-08 0:41 ` Qu Wenruo
0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2019-03-07 16:32 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
On Fri, Mar 01, 2019 at 10:47:57AM +0800, Qu Wenruo wrote:
> - Allow NULL fs_info for TP_fast_assign_fsid()
> There is extent bits operation in selftest which is too deep to pass
> fs_info. And since it's in selftest, it shouldn't trigger trace
> events.
> But to be safe, we still need to check fs_indo in
> TP_fast_assign_fsid(), for NULL fs_info, just keep fsid filled with
> zero.
Ok, better be safe here. I'd still like to remove the conditional, as
the tests typically access only a single filesystem we could export the
fs_info globally, avoiding the need to pass it around.
> There is one point which need extra attention:
> 1) Those trace events are pretty heavy
> The following workload would generate over 400 trace events.
I'm not sure if 400 is considered a lot, I'd say 400.000 would be a lot
for the steps below.
> mkfs.btrfs -f $dev
> start_trace
> mount $dev $mnt -o enospc_debug
> sync
> touch $mnt/file1
> touch $mnt/file2
> touch $mnt/file3
> xfs_io -f -c "pwrite 0 16k" $mnt/file4
> umount $mnt
> end_trace
> It's not recommended to use them in real world environment.
>
> Changelog:
> v2:
> - Introduce fs_info to distinguish different btrfs filesystems
> - Code style change to make trace code more elegant
> - Minor IO_TREE_* naming change.
> - Use btrfs_ino() to replace raw inode number.
> - Change extent_io_tree::owner declaration to avoid affecting spinlock.
v2 looks good to me, thanks. I'll add it to the 5.2 queue.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree
2019-03-07 16:32 ` David Sterba
@ 2019-03-08 0:41 ` Qu Wenruo
0 siblings, 0 replies; 4+ messages in thread
From: Qu Wenruo @ 2019-03-08 0:41 UTC (permalink / raw)
To: dsterba, Qu Wenruo, linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 2072 bytes --]
On 2019/3/8 上午12:32, David Sterba wrote:
> On Fri, Mar 01, 2019 at 10:47:57AM +0800, Qu Wenruo wrote:
>> - Allow NULL fs_info for TP_fast_assign_fsid()
>> There is extent bits operation in selftest which is too deep to pass
>> fs_info. And since it's in selftest, it shouldn't trigger trace
>> events.
>> But to be safe, we still need to check fs_indo in
>> TP_fast_assign_fsid(), for NULL fs_info, just keep fsid filled with
>> zero.
>
> Ok, better be safe here. I'd still like to remove the conditional, as
> the tests typically access only a single filesystem we could export the
> fs_info globally, avoiding the need to pass it around.
In fact, it's purely to be safe here.
Since the selftest is only executed at module load time, it's pretty
hard to enable trace event at that small time windows.
And if btrfs is complied into kernel, it's definitely impossible.
>
>> There is one point which need extra attention:
>> 1) Those trace events are pretty heavy
>> The following workload would generate over 400 trace events.
>
> I'm not sure if 400 is considered a lot, I'd say 400.000 would be a lot
> for the steps below.
Considering other btrfs events are hardly to hit 40 for that small
workload, among btrfs specific events, it looks a little heavy.
>
>> mkfs.btrfs -f $dev
>> start_trace
>> mount $dev $mnt -o enospc_debug
>> sync
>> touch $mnt/file1
>> touch $mnt/file2
>> touch $mnt/file3
>> xfs_io -f -c "pwrite 0 16k" $mnt/file4
>> umount $mnt
>> end_trace
>> It's not recommended to use them in real world environment.
>>
>> Changelog:
>> v2:
>> - Introduce fs_info to distinguish different btrfs filesystems
>> - Code style change to make trace code more elegant
>> - Minor IO_TREE_* naming change.
>> - Use btrfs_ino() to replace raw inode number.
>> - Change extent_io_tree::owner declaration to avoid affecting spinlock.
>
> v2 looks good to me, thanks. I'll add it to the 5.2 queue.
>
Thanks for merging and update it for the renaming.
Thanks,
Qu
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-08 0:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-01 2:45 [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2019-03-01 2:47 Qu Wenruo
2019-03-07 16:32 ` David Sterba
2019-03-08 0:41 ` Qu Wenruo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).