On Wed, Aug 10, 2022 at 12:35:34PM -0400, Chris Murphy wrote: > CPU: Intel E5-2680 v3 > RAM: 128 G > 02:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] [1000:005d] (rev 02), using megaraid_sas driver > 8 Disks: TOSHIBA AL13SEB600 > > > The problem exhibits as increasing load, increasing IO pressure (PSI), and actual IO goes to zero. It never happens on kernel 5.11 series, and always happens after 5.12-rc1 and persists through 5.18.0. There's a new mix of behaviors with 5.19, I suspect the mm improvements in this series might be masking the problem. > > The workload involves openqa, which spins up 30 qemu-kvm instances, and does a bunch of tests, generating quite a lot of writes: qcow2 files, and video in the form of many screenshots, and various log files, for each VM. These VMs are each in their own cgroup. As the problem begins, I see increasing IO pressure, and decreasing IO, for each qemu instance's cgroup, and the cgroups for httpd, journald, auditd, and postgresql. IO pressure goes to nearly ~99% and IO is literally 0. > > The problem left unattended to progress will eventually result in a completely unresponsive system, with no kernel messages. It reproduces in the following configurations, the first two I provide links to full dmesg with sysrq+w: > > btrfs raid10 (native) on plain partitions [1] > btrfs single/dup on dmcrypt on mdadm raid 10 and parity raid [2] > XFS on dmcrypt on mdadm raid10 or parity raid > > I've started a bisect, but for some reason I haven't figured out I've started getting compiled kernels that don't boot the hardware. The failure is very early on such that the UUID for the root file system isn't found, but not much to go on as to why.[3] I have tested the first and last skipped commits in the bisect log below, they successfully boot a VM but not the hardware. > > Anyway, I'm kinda stuck at this point trying to narrow it down further. Any suggestions? Thanks. > I looked at the traces, btrfs is stuck waiting on IO and blk tags, which means we've got a lot of outstanding requests and are waiting for them to finish so we can allocate more requests. Additionally I'm seeing a bunch of the blkg async submit things, which are used when we have the block cgroup stuff turned on and compression enabled, so we punt any compressed bios to a per-cgroup async thread to submit the IO's in the appropriate block cgroup context. This could mean we're just being overly mean and generating too many IO's, but since the IO goes to 0 I'm more inclined to believe there's a screw up in whatever IO cgroup controller you're using. To help narrow this down can you disable any IO controller you've got enabled and see if you can reproduce? If you can sysrq+w is super helpful as it'll point us in the next direction to look. Thanks, Josef
