Re: [PATCH RFC 0/2] btrfs: remove the metadata readahead mechanism

[Filipe Manana <fdmanana@kernel.org>]

On Wed, Dec 08, 2021 at 03:04:11PM +0100, David Sterba wrote:
> On Tue, Dec 07, 2021 at 03:53:22PM +0000, Filipe Manana wrote:
> > > > I'm doing some tests, in a VM on a dedicated HDD.
> > >
> > > There's some measurable difference:
> > >
> > > With readahead:
> > >
> > > Duration:         0:00:20
> > > Total to scrub:   7.02GiB
> > > Rate:             236.92MiB/s
> > >
> > > Duration:         0:00:48
> > > Total to scrub:   12.02GiB
> > > Rate:             198.02MiB/s
> > >
> > > Without readahead:
> > >
> > > Duration:         0:00:22
> > > Total to scrub:   7.02GiB
> > > Rate:             215.10MiB/s
> > >
> > > Duration:         0:00:50
> > > Total to scrub:   12.02GiB
> > > Rate:             190.66MiB/s
> > >
> > > The setup is: data/single, metadata/dup, no-holes, free-space-tree,
> > > there are 8 backing devices but all reside on one HDD.
> > >
> > > Data generated by fio like
> > >
> > > fio --rw=randrw --randrepeat=1 --size=3000m \
> > >          --bsrange=512b-64k --bs_unaligned \
> > >          --ioengine=libaio --fsync=1024 \
> > >          --name=job0 --name=job1 \
> > >
> > > and scrub starts right away this. VM has 4G or memory and 4 CPUs.
> > 
> > How about using bare metal? And was it a debug kernel, or a default
> > kernel config from a distro?
> 
> It was the debug config I use for normal testing, I'll try to redo it on
> another physical box.
> 
> > Those details often make all the difference (either for the best or
> > for the worse).
> > 
> > I'm curious to see as well the results when:
> > 
> > 1) The reada.c code is changed to work with commit roots;
> > 
> > 2) The standard btree readahead (struct btrfs_path::reada) is used
> > instead of the reada.c code.
> > 
> > >
> > > The difference is 2 seconds, roughly 4% but the sample is not large
> > > enough to be conclusive.
> > 
> > A bit too small.
> 
> What's worse, I did a few more rounds and the results were too unstable,
> from 44 seconds to 25 seconds (all on the removed readahead branch), but
> the machine was not quiescent.

I get such huge variations too when using a debug kernel and virtualized
disks for any tests, even for single threaded tests.

That's why I use a default, non-debug, kernel config from a popular distro
and without any virtualization (or at least have qemu use a raw device, not
a file backed disk on top of another filesystem) when measuring performance.