Hi,
On 06.11.2014 13:59, Christian Menard wrote:
I'm still working on NOVA(64)+VBox+Android_x86 on the Panasonic Toughpad FZ-M1 with Intel Core i5-4302Y CPU (With VT-X). After all the basic stuff is working my problem is that overall performance of the system is very bad. This issue is related to Genode as Android runs fast and with smooth animations on top of Linux+VBox and Linux+Qemu (on the same hardware).
this is not unexpected. Currently we focusing on stability and features of VBox@...269... and the next step is to invest time in improving performance.
Do you have any ideas on what might be causing the performance issues or any hints on where to investigate?
Here is what I know so far:
I used VBox's built-in performance counters to investigate the issue. Based on these counters I found that a big portion of processing time is spend on 'other' tasks (most often more than 50%). This is described as "Time spent in the VMM or preempted recently."
I found that during boot-up a lot of time is spend in the Recompiler, or more specific: on executing recompiled code. Here is an example of the performance counter as found after Android booted to welcome screen:
/PROF/REM/Runcode 52808 ticks/call (112541953198 ticks, 2131148 times, max 9428119254, min 116)
What surprises me here is the max value. Several billion ticks (should correspond to several seconds of processing time) seems to be very much for instruction emulation. However, only a small amount of time is spend in Runcode once Android is booted up. So if this is an issue, it would only speed up the boot.
In the Genode port of VBox we force a VM to stay in recompiled mode if the virtual CPU is not in protected mode with paging enabled. This enforcement should not be necessary, but we didn't investigated the reason why this caused trouble in the early days of our porting efforts.
https://github.com/genodelabs/genode/blob/master/repos/ports/src/virtualbox/...
I also had a look at the graphics backend and found that a significant amount of time is spend on framebuffer updates. Here it might be possible to do some optimizations. However, tests showed that this is a not the major problem. The calculation done between two frames takes too long, in comparison the update of the frame itself is only a minor part.
Virtualbox has several variations of improved 2D and 3D video accelerations on Linux and Windows, non of them used by the Genode port.
The current state on Genode: The VGA framebuffer memory and text console buffer are initially not mapped to the VM. As soon as the VM touches the memory regions a VM exit happens and the handler of the registered memory regions are called (pointing effectively to the vga model). The VGA model tracks which pages are touched and are dirty and tells on the reply from the model our port, whether the memory can be mapped to the VM to avoid further VM exits. The VGA model regularly calls PGMHandlerPhysicalReset which causes to unmap the VGA framebuffer from the VM. This causes of course some overhead.
There are some options to tweak the VGA model in several directions, but as said we did not investigated notable time.
Recently there was a issue and a related commit added on github by Christian Prochaska. https://github.com/genodelabs/genode/issues/1284 I pulled this commit along with a chain of preceding changes. This significantly improved performance to a somewhat usable level but it is still way too slow. So far I did not test if this specific commit or some of the preceding commits are responsible for the increase in performance.
Another potential optimization point:
We track resources like ioport, iomem, guest memory, handler to these resources in simple plain lists. The original VBox code - implemented in the PGM component - uses a AVL tree to speed up lookups of such resources.
Cheers,
Alex.
All best Christian
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main