This is not a new problem, it happens since I can recall in a default
virt-manager qemu-kvm VM using qxl video. It's easy to reproduce in VM
as well as baremetal.
See screenshot here:
https://drive.google.com/open?id=1TK-QnaBDzbcu7hxVEN40x2DlA4NyDMB2
The questions are: is it expected these processes take up this much
CPU? is there low hanging fruit here? Even cutting it in half would be
huge. How to profile and file a bug against these likely separate
problems?
Maybe it's worth in the next cycle trying zstd for squashfs.img
compression in lieu of xz. That might be related to loop1 taking such
a big hit, but I don't know for sure that loop1 rather than loop0 is
really the process taking the xz decompression hit.
--
Chris Murphy