View previous topic :: View next topic |
Author |
Message |
costel78 Guru
Joined: 20 Apr 2007 Posts: 407
|
Posted: Tue Aug 06, 2019 10:57 am Post subject: QEMU/KVM questions |
|
|
I decided to buy a Raspberry Pi 4B and I want to run Gentoo on it and hope to be able to port some fpc/lazarus app on it.
Confusion come with all qemu/kvm/crossdev stuff, as I hope to compile almost everything on my desktop and use getbinpkg on Raspberry itself.
The plan is to have a qemu virtual machine using chroot and, also, use distcc to cross-compile using crossdev on the same machine (amd64, Intel 6700K CPU, 32GB RAM).
The issue is that qemu is about 8-10 time slower than normal CPU performance.
My question is: Are there *ANY* options to improve performance ? Neddy Seagoon said on this forum that QEMU/KVM performance is almost the performance of the real machine, but I have no ideea how to archive that.
Current setup:
1. app-emulation/qemu compiled with static-user useflag
2. qemu installed on chroot: ROOT=/mnt/linux/arm64 emerge --usepkgonly --oneshot --nodeps qemu
3. distcc setup both on server (my desktop) and client (qemu chroot)
4. crossdev is setup:
Code: | gcc-config -l
[1] aarch64-unknown-linux-gnu-9.1.0 *
[2] x86_64-pc-linux-gnu-9.1.0 * |
5. chroot via systemd-nspawn -D /mnt/linux/arm64/ --capability=all --bind=/var/tmp/ --bind=/tmp/ --bind=/var/db/repos/ --bind=/mnt/linux/distfiles/
6. distcc (and subsequently crossdev) is working:
Code: | journalctl -f --unit=distccd
-- Logs begin at Mon 2019-08-05 15:19:02 EEST. --
aug 06 07:43:56 gentoo distccd[3313157]: (dcc_job_summary) client: 127.0.0.1:46870 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:422ms aarch64-unknown-linux-gnu-g++ cc1plus-checksum.c
aug 06 07:44:54 gentoo distccd[3313464]: (dcc_job_summary) client: 127.0.0.1:46878 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:680ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/connection.cc
aug 06 07:44:55 gentoo distccd[3316964]: (dcc_job_summary) client: 127.0.0.1:46872 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:844ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/findcomp.cc
aug 06 07:44:55 gentoo distccd[3317495]: (dcc_job_summary) client: 127.0.0.1:46882 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:331ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/marshall.cc
aug 06 07:44:55 gentoo distccd[3314857]: (dcc_job_summary) client: 127.0.0.1:46874 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1457ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/libcc1.cc
aug 06 07:44:56 gentoo distccd[3306623]: (dcc_job_summary) client: 127.0.0.1:46884 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:266ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/callbacks.cc
aug 06 07:44:56 gentoo distccd[3315206]: (dcc_job_summary) client: 127.0.0.1:46880 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1532ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/libcp1.cc
aug 06 07:44:57 gentoo distccd[3313106]: (dcc_job_summary) client: 127.0.0.1:46888 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:135ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/names.cc
aug 06 07:44:57 gentoo distccd[3318711]: (dcc_job_summary) client: 127.0.0.1:46876 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:3513ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/libcp1plugin.cc
aug 06 07:44:58 gentoo distccd[3318337]: (dcc_job_summary) client: 127.0.0.1:46886 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:2083ms aarch64-unknown-linux-gnu-g++ /var/tmp/portage/sys-devel/gcc-9.1.0-r1/work/gcc-9.1.0/libcc1/libcc1plugin.cc |
Obviously I need just directions, links, anything to speed-up this qemu Aarch64 emulation.
Thank you in advance!
Later Edit:
My (*WRONG*) assumption was that QEMU uses KVM by default, since the ebuild ask for it to be enabled in the kernel. Using only chroot this does not happen, qemu emulate everything in user-space so it is horribly slow. It seems kvm is needed to emulate hardware and quemu to emulate aarch64 cpu and both of them working together, both kernel and user-space will give the desired speed.
I try to use app-emulation/virt-manager and come back. _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54799 Location: 56N 3W
|
Posted: Tue Aug 06, 2019 7:18 pm Post subject: |
|
|
costel78,
QEMU on a AMD Phenom(tm) II X6 1090T is about the same speed as a Pi3.
Once you move away from native compiling, success varies.
Pure cross compiling is fastest but not all build system support it. A few are even cross compile hostile. They attempt to execute build products during the course of the build.
Another option is cross distcc. You build on the Pi with the help of distcc. This is not 100%. A few packages build but produce broken code.
A few (like gcc) cannot use distcc.
It doesn't matter if you use QEMU in a chroot or as the basis of a KVM, the arm64 CPU is still emulated in software and its is horribly slow.
I suspect the KVM route is slowest as you will have an arm64 kernel too. In the chroot, the hosts native kernel and services are used.
Feel free to use my BINHOST to get a leg up. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 407
|
Posted: Wed Aug 07, 2019 10:07 am Post subject: |
|
|
Thank you for yours support!
@NeddySeagoon: unfortunately there are quite a few use-flags differences between your BINHOST and my setup, especially python-3.7 is required.
Can you, please, provide a list of packages which fail at runtime if they are compiled with distcc/crossdev ?
I manage to compile gcc on qemu but with --disable-bootstrap configure option and, at least until now, avoided successfully llvm, clang and rust.
Given proper cooling, how realistic is to compile entire gentoo on Raspberry Pi 4, with swap and PORTAGE_TMPDIR on external ssd, connected via USB ? _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54799 Location: 56N 3W
|
Posted: Wed Aug 07, 2019 6:53 pm Post subject: |
|
|
costel78,
Until the kernel is fixed the Pi4 in 64 bit mode can only use the bottom 1G RAM.
That rules out some of the bigger packages but it seems you don't want them anyway.
My Pi4 has the Power over Ethernet HAT, which incorporate a fan. There is no heatsink on the CPU.
It uses the 'On Demand' CPU governor and always runs at 1.5GHz.
The same effect should be achievable with a good passive heatsink or even on the Pi4
That's a cut down Socket5 heatsink (Pentium on AMD k6 series)
I built all of Gentoo except Rust and FIrefox on a Pi3, so it will be a bit faster on a Pi4.
I used cross distcc a lot too.
The list of things that don't work with distcc/crossdev is not fixed. You need to try it. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 407
|
Posted: Thu Aug 08, 2019 11:50 am Post subject: |
|
|
NeddySeagoon,
The PoE HAT available in my area use all GPIO pins so I will use a chipset heatsink from 486 era, about 15mm height and a noctua 40mm 5V fan. The radiator will also cover USB3 chip as I read it also get very warm.
I will try to match use-flags to be able to use your chromium and libreoffice binary packages.
Thank you for your support! _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54799 Location: 56N 3W
|
Posted: Thu Aug 08, 2019 7:21 pm Post subject: |
|
|
costel78,
The PoE hat covers the GPIO pins but only uses a few.
I have fitted extenders so I can still use the serial port. All the pins poke through that HAT.
If you don't have a PoE network switch, the PoE HAT is a very expensive fan.
I'm open to suggestions for USE flags. That does not mean I will follow suggestions but its always harmless to ask. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 407
|
Posted: Fri Aug 09, 2019 12:15 pm Post subject: |
|
|
Good news. After I disabled all Intel's kernel mitigation I have:
Code: | arm64:
Fri Aug 9 14:57:02 2019 >>> app-office/libreoffice-6.3.0.4
merge time: 2 hours, 55 minutes and 23 seconds.
amd64:
Fri Aug 9 09:09:19 2019 >>> app-office/libreoffice-6.3.0.4
merge time: 56 minutes and 53 seconds. |
which is more than acceptable.
NeddySeagoon,
Thank you very much for your offer, but I think it should be the other way around: if I use your binpkgs, I am the one who should accommodate (change) the use flags.
I found this information: https://andrei.gherzan.ro/linux/raspbian-rpi4-64/ - he claims that memory clamp is up to 3GB, from 1GB previously.
At the beginning of the next week Raspberry Pi4 should, finally, arrive and I will start to play with it.
Once again, thank you very much! _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54799 Location: 56N 3W
|
Posted: Fri Aug 09, 2019 4:16 pm Post subject: |
|
|
costel78,
I try to add the ~arm64 keyword to things. That means my USE flags are a bit of a mess, so I don't mind suggestions than would make things more user friendly.
I have USE=docs set globally, which is a bid odd but I need to build test documentation _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|