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 _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
