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

Filipe Manana
2021-12-09T10:25:17Z

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.