Hi! A user reported a significant slowdown of an operation which used to work quite a bit faster. This time, however, the regression is not on the qemu side but on the guest OS side (debian bookworm to debian trixie), running in the same qemu-user. It is more, - it doesn't really matter which version of qemu-user to use (from a few recent versions).
For example, building a particular debian source package (in this case, bird3) in qemu-user-backed aarch64 debian chroot for current debian release (trixie) takes at least as twice time than the same operation on bookworm (previous debian release). I can confirm this slowdown, however, I see about 2x time difference, while the OP reports 10x slowdown. https://bugs.debian.org/1113951 has a few more details about this. I observe this difference (omitting the build logs): $ sbuild -d bookworm --arch arm64 bird3_3.1.0-1.dsc Build needed 00:14:45, 265340k disk space $ sbuild -d trixie --arch arm64 bird3_3.1.0-1.dsc Build needed 00:27:00, 267508k disk space One of the most notable contributors in this time difference seems to be tex setup procedure: Processing triggers for tex-common (6.19) ... Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. at this point it runs pdftex, luatex, luahbtex and a few other tex-related programs, which are visible in top(1) output for minutes when running in trixie chroot. Other programs are also running slower, but not that significant. I'll try to provide a minimal reproducer here. But overall, how to debug such situation, when it is not qemu which is at issue? Thanks, /mjt
