-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, Feb 09, 2025 at 12:04:20PM +0100, David Hobach wrote: > On 2/8/25 15:11, Marek Marczykowski-Górecki wrote: > > Hi, > > > > We've spent some time recently on improving qrexec performance, > > specifically lower the overhead on making a qrexec call. To have some > > visibility into effects, we started with adding simple performance > > tests: > > https://github.com/QubesOS/qubes-core-admin/pull/647 > > > > Here I'll focus on just one test that is making 500 calls and measure > > the total time in seconds - the lower the better. > > > > Here are the results: > > baseline (qrexec 4.3.1): fedora-41-xfce_exec 53.047245962000034[1] > > remove qubes-rpc-multiplexer[2] (qrexec 4.3.2): fedora-41-xfce_exec > > 21.449519581999994 [3] > > cache system info for policy[4]: fedora-41-xfce_exec 9.012277056000016[5] > > > > So, in total over 5x improvement :) > > That sounds great and I look forward to that change. Thanks a lot in advance! > :) > > However for an overall improvement in user experience not only the qrexec > speed is relevant, but also the time to get the qrexec service running inside > a newly started VM. > For example on my machine a qrexec call on a running VM takes ~530ms > (hopefully less in the future with the changes you mentioned) and one on a > small non-running VM 6s, out of which the qubes-qrexec-agent.service takes > 2,8s to start: > qubes-qrexec-agent.service +20ms > └─systemd-user-sessions.service @2.855s +18ms > └─network.target @2.852s > └─networking.service @2.750s +101ms > └─network-pre.target @2.732s > └─qubes-iptables.service @2.416s +315ms > └─qubes-antispoof.service @2.210s +205ms > └─basic.target @2.206s > └─sockets.target @2.206s > └─qubes-updates-proxy-forwarder.socket @2.206s > └─sysinit.target @2.187s > └─systemd-binfmt.service @1.860s +327ms > └─proc-sys-fs-binfmt_misc.mount @2.114s +69ms > └─systemd-journald.socket @1.015s > └─-.mount @984ms > └─-.slice @985ms > > So improving the speed at which any of these services in the > qubes-qrexec-agent.service critical chain start or possibly getting rid of > dependencies entirely should improve the overall Qubes OS performance. > For example these numbers looked smaller in 4.1 on the same machine and a > comparable VM [6]. > > [6] > https://github.com/3hhh/qubes-performance/blob/master/samples/4.1/t530_debian-11_01.txt#L32-L40
Ouch. 500sms to set up networking is way too slow, and it looks like setting up the root filesystem is also slow. dev-mapper-dmroot.device takes 1.310s to start up, which is nearly half of the 2.170s spent in userspace on the VM I used to write this message. I suspect this is largely a problem with the Xen toolstack, which is not optimized, to put it mildly. Replacing it with an optimized toolstack like the one Edera uses would make things much, much faster. > > And also, now it can do over 50 calls per second, I'd say it's way more than > > enough for its intended use. _Not_ fast enough for an internet-facing qrexec-call-per-request service, though, unless one checks authentication before the call to revent denial of service attacks. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmepTjoACgkQszaHOrMp 8lNCXg/6AjQ2iX3D7GTiueNm5/59PzxR/YPgeFHr6ehSReTDRvXIYfUp6KudTE8h Y5xjQY5tDkg6nogUshtdNdiHHNY3gniBG+XHTpNebpM9O4EVXUEadgxjBQErIhaM Ua+ORHLnAYY9d60a4aUdgocOiygOTd3NDU39r3HfVimDdlX7Q0RbEBUzaNlqH2U6 gJ+iQ58OqxuKtV6+3XlQep/5Ea+2NNqO8g9TwsfRQ4m026NTJDGJIyP+HceZvkUl hr+1quFjhDp+DJjzPpUsqX4EqsCrOKgDvlfF3cTmun9ydqvdM+kydInVHJT93jNN E2XNlmghNdLx+UggcP/e4wosrcbjvZpkzXl9u2dZe4zF0Iuk1SGqGtJ3iyKIZW0q IazvAEP3fySM8x0jQmJ654Sb0MyUTn+p74EL0VfgCa8jFg0nQVEuAtVfIqYoWr2b 93ATX7mCb2UKQnb3hUqW0pV1Wt2HWLf4ajEUwbp7keJZArvWg6zyIqCKE7Y9lyHz +49hdBClYrzzVpWVtRbh1iW+1YyddEjV4LICdCryFiPG9l5+hhdfS47isUjDZ8wE pdcBa4uBtXVxacgH/G6wFLYiltkViBeBYukeu5bx0O9xMy9i9X54zTUSQk/swsB3 gnql+EA6FT7YYKH1nF+iIImsXTjzQNuUHsg+DOVpPaRzyWNoeYY= =3Vli -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/Z6lOPziG5pJul2GB%40itl-email.
