Hello,

On 06.11.2014 14:00, Christian Menard wrote:

this issue is related to my previous message. My goal is not only to run VBox+Android but also some other secure applications in parallel. Therefore I introduced a small server that multiplexes the Input and Framebuffer session so that it is possible to switch between Android and Nitpicker based on a key stroke. I attached a runscript to illustrate the setup.

Compared to your first setup you dropped in this run script the assignment of priorities to more critical servers. This is of no good for services which needs proper (softreal)-time execution, especially, timer, drivers, graphical server.

In my setup VBox+Android are executed on one CPU and everything else runs on another CPU. This SMP setup is necessary as otherwise Android stops booting up. Parallel load during startup of Android seems to have some influence and stops execution of the VM, but so far I could not identify the reason.

Please assign proper priority levels and see if the problem persists.

To the problem: Not only the performance of Android is very bad, but the whole system feels slow and unresponsive. Applications like liquid_framebuffer are significantly slowed down when VBox is running. This happens also when the VM is actually in a halted state. I find it very strange that VBox running on one CPU has such a strong impact on the performance of Apps running on another CPU. It leaves me wondering if there is something wrong with synchronization or the scheduler itself. Do you have any ideas or hints?

The core services and init are running on the boot CPU. By moving all critical servers to another CPU (as done in your run script) you get a lot of cross CPU switching overhead, whenever the services call init or core.

The better approach is to start VBox on another CPU instead, actually I doesn't know whether this is already works ...

Cheers,

Alex.

All best Christian

---

---

genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hi,

Thanks for the patch! I tried various configurations, but the system keeps behaving strangely.

I dropped the priority setting, because with priorities I ran into the problem I described before - the VM hangs during bootup without any error messages or a clear reason. However, I removed a few printfs (mostly "attempted to read/write to non-existing port") to get a cleaner log and discovered that it helps to avoid the issue.

When I setup a system that starts the Android-VM and Nitpicker in parallel on top of my Framebuffer-Multiplexer but does not start any nitpicker apps, everything works fine in single- and multi-processor case. However, as soon as I start a nitpicker app like liquid_fb, the system gets very slow while the android kernel is booting. The kernel boot takes more than 30 minutes (usually a few seconds) and everything else is very slow as well. In the case where virtualbox runs on a separate CPU it gets even worse. Once the kernel boot completed, the system runs fast again. In this state starting virtualbox on another CPU helps, the system in general responds faster and has better performance.

I wonder why an app running in parallel to virtualbox influences the performance of the whole system so drastically. First I thought it might be related to my Framebuffer multiplexer, but the problem remains when starting virtualbox in a liquid_fb. Do you have any suggestions?

Thanks Christian

On Monday 10 November 2014 11:26:44 Alexander Boettcher wrote:

Hello Christian,

On 09.11.2014 14:51, Alexander Boettcher wrote:

...

The core services and init are running on the boot CPU. By moving all critical servers to another CPU (as done in your run script) you get a lot of cross CPU switching overhead, whenever the services call init or core.

The better approach is to start VBox on another CPU instead, actually I doesn't know whether this is already works ...

please try following attached patch. With it VBox can be started also on another CPU then the boot CPU.

Does it work for you ?

Alex.

Hi,

Do you see during the slow down messages like "apply timer quirk" in the log output ?

These messages appear in the global log and not as a message by virtualbox, right? So far I did not have a serial interface (nor ethernet) available to read these messages. I have a new device with serial interface now, but currently we have hardware issues. I will keep you updated, as soon as I know something new.

Cheers Christian