Re: Kernel traces

["Stephen R. van den Berg" <srb@cuci.nl>]

Chris Murphy wrote:
>I suggest reproducing the problem and issuing sysrq+w and then post
>the entire resulting output for a developer to evaluate. I find it's

I'll give that a try.

>I see this is btrfs-receive workload, so I wouldn't guess it's
>suvolume lock contention unless the contention is happening with a
>single shared parent subvolume into which all the receive subvolumes
>are going (e.g. subvol id 5). I'm not sure how to alleviate it.

Well, machine A has 32GB RAM and is running
multiple simultaneous btrfs-receive instances, but the machine rarely locks up
unless I increase the total reception rate beyond 5MB/s.

Machine B has 8GB RAM and is running at most a single btrfs-receive instance,
but it is much more susceptible to hangups.  The maximum reception rate
here is 3MB/s.

In both cases all received subvolumes are created inside the same master
parent (subvol id 5).  The only difference is that machine A receives multiple
subvolumes simultaneously, and machine B serialises reception (it basically
receives subvolumes from a single source (machine A)), but the subvolumes here
*are* created back to back (so maybe the previous btrfs-receive is still
late flushing buffers to disk when the new btrfs-receive already starts).
-- 
Stephen.