On Wed, Oct 30, 2019 at 12:23:01PM +0000, fdmanana@xxxxxxxxxx wrote: > From: Filipe Manana <fdmanana@xxxxxxxx> > > Backreference walking, which is used by send to figure if it can issue > clone operations instead of write operations, can be very slow and use too > much memory when extents have many references. This change simply skips > backreference walking when an extent has more than 64 references, in which > case we fallback to a write operation instead of a clone operation. This > limit is conservative and in practice I observed no signicant slowdown > with up to 100 references and still low memory usage up to that limit. So this could lead to larger stream due to writes instead of clones, and thus fewer cloned ranges on the receive side. This is observable and could potentially raise questions why is this happening. Limiting the nmuber makes sense, based on the report, though I'm curious if we can make it higher, eg. 128, or 100 that you have measured. I'll tag the patch for stable as it can be considered usability bug fix, so I'm interested in the possible fallouts. > This is a temporary workaround until there are speedups in the backref > walking code, and as such it does not attempt to add extra interfaces or > knobs to tweak the threshold. > > Reported-by: Atemu <atemu.main@xxxxxxxxx> > Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3SGdoinVo=C9eQ@xxxxxxxxxxxxxx/T/#me55dc0987f9cc2acaa54372ce0492c65782be3fa > Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx> Added to misc-next, thanks. The above is up to discussion and the number can be tuned later.
