Performance issues with VBox+Android-x86

[Alexander Boettcher]

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 at ...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/hwaccm.cc#L83

> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>