I’m assuming you have been using the standard launch script (from /usr/share/acrn/samples/nuc/launch_zephyr.sh) to test your Zephyr app. If so, can you try to use this script
instead to see if it makes any difference?
I have not tried it yet with your app but it’s able to launch the Zephyr “Hello World! Acrn” app.
I have tried with the new script, and I think it helps a bit, although it
does not remove completely the increment in time when something is running
in the SOS. But it is a bit difficult to say tbh.
From: VanCutsem, Geoffroy
Sent: Tuesday, January 21, 2020 4:18 PM
Subject: RE: [acrn-users] Zephyr as UOS slows down when SOS is busy
My best guess as to what’s happening is that there is some contention between the Service VM and the Zephyr VM to use the cache, Zephyr would typically stay in cache but now
that there is some heavy load in the Service VM, it may get evicted at times. This is where Cache Allocation Technology (CAT) can help further isolate the VMs, especially against so-called “noisy neighbours. Unfortunately, Kaby Lake does not support CAT. Here
is more about CAT and how to use it with ACRN:
I have been playing with using Zephyr as UOS on top of Ubuntu as SOS, using the Industry scenario and launching the UOS with launch_zephyr.sh.
Although the problem runs and I get output from the serial port, I found two problems:
1. gettimeofday is not returning good times, the elapsed time is ~20 times more than the real one. I see the same problem when using k_uptime_get and k_uptime_delta. It looks related to handling of the HW clock, but the pre-defined frequency
(100) seems correct.
2. More importantly, I see that the time spent in the calculation varies when I do something CPU intensive on the SOS. For instance, if I run the same calculation on the SOS, I see that Zephyr is expending 5% more time in the calculation,
which should not happen and defeats the purpose of this set-up.
HV version 1.4-unstable-2020-01-09 09:45:06-bcefd673 DBG (daily tag: acrn-2019w47.1-140000p) build by ubuntu
API version 1.0
Any ideas on what might be going on?
I forgot to mention that I am testing on a NUC7i7DNH.