[Multi-arch SIG] success to run full tempest tests on Arm64 env. What's next?
Dear all, I'm glad to tell everyone that we finally succeeded to build Devstack and run full tempest tests on it [1]. As the test build result shows [2], the job is stable enough to run. For earlier 13+ job results. (will do more recheck later) One Timeout, and two failure cases (Which are targeted by increase `BUILD_TIMEOUT` to 900 secs). The job `devstack-platform-arm64` runs around 2.22 hrs to 3.04 hrs, which is near two times slower than on x86 environment. It's not a solid number as the performance might change a lot with different cloud environments and different hardware. But I think this is a great chance for us to make more improvements. At least now we have a test job ready (Not merged yet) for you to do experiments with. And we should also add suggestions to Multi-arch SIG documentation so once we make improvements, other architecture can share the efforts too. *So please join us if you are also interested in help tuning the performance :)* *Also, we need to discuss what kind of way we should run this job, should we separate it into small jobs? Should we run it as a periodic job? voting?* *On the other hand, I would hope to collect more ideas on how we should move forward.* *Please provide your idea for this on our Xena PTG etherpad* *https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig <https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig>* Our PTG is scheduled around 4/20 Tuesday from 07:00-08:00 and 15:00-16:00 (UTC time) If you plan to join our PTG, feel free to update our PTG etherpad to suggest other topics. And our Meeting time is scheduled biweekly on Tuesday (host on demand) Please join our IRC #openstack-multi-arch [1] https://review.opendev.org/c/openstack/devstack/+/708317 [2] https://zuul.openstack.org/builds?job_name=devstack-platform-arm64+ *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Tue, Apr 06, 2021 at 03:43:29PM +0800, Rico Lin wrote:
The job `devstack-platform-arm64` runs around 2.22 hrs to 3.04 hrs, which is near two times slower than on x86 environment. It's not a solid number as the performance might change a lot with different cloud environments and different hardware.
I guess right now we only have one ARM64 cloud so it won't vary that much :) But we're working on it ... I'd like to use this for nodepool / diskimage-builder end-to-end testing, where we bring up a devstack cloud, build images with dib, upload them to the devstack cloud with nodepool and boot them. But I found that there was no nested virtualisation and the binary translation mode was impractically slow; like I walked away for almost an hour and the serial console was putting out a letter every few seconds like a teletype from 1977 :) $ qemu-system-aarch64 -M virt -m 2048 -drive if=none,file=./test.qcow2,media=disk,id=hd0 -device virtio-blk-device,drive=hd0 -net none -pflash flash0.img -pflash flash1.img Maybe I have something wrong there? I couldn't find a lot of info on how to boot. I expected slow, but not that slow. Is binary translation practical? Is booting cirros images, etc. big part of this much longer runtime? -i
HI Ian, On Fri, Apr 9, 2021 at 12:07 PM Ian Wienand <iwienand@redhat.com> wrote:
On Tue, Apr 06, 2021 at 03:43:29PM +0800, Rico Lin wrote:
The job `devstack-platform-arm64` runs around 2.22 hrs to 3.04 hrs, which is near two times slower than on x86 environment. It's not a solid number as the performance might change a lot with different cloud environments and different hardware.
I guess right now we only have one ARM64 cloud so it won't vary that much :) But we're working on it ...
I'd like to use this for nodepool / diskimage-builder end-to-end testing, where we bring up a devstack cloud, build images with dib, upload them to the devstack cloud with nodepool and boot them.
But I found that there was no nested virtualisation and the binary translation mode was impractically slow; like I walked away for almost an hour and the serial console was putting out a letter every few seconds like a teletype from 1977 :)
$ qemu-system-aarch64 -M virt -m 2048 -drive if=none,file=./test.qcow2,media=disk,id=hd0 -device virtio-blk-device,drive=hd0 -net none -pflash flash0.img -pflash flash1.img
Maybe I have something wrong there? I couldn't find a lot of info on how to boot. I expected slow, but not that slow.
Yes No nested virtualization now on Arm64 server.
Is binary translation practical? Is booting cirros images, etc. big part of this much longer runtime?
Suggest boot cirros as the test VM, other distro boot use qemu without kvm support is slow
-i
participants (3)
-
Ian Wienand
-
kevinz
-
Rico Lin