base-hw: Virtualbox thread priorities

[Adrian-Ken Rueegsegger]

Hello Martin,

Thank you for your insightful comments.

On 07/02/2015 04:48 PM, Martin Stein wrote:
> Hi Adrian,

[...]

> * Configure the vbox component to receive some quota from init (add
> <resource name="CPU" quantum="${PERCENTAGE}"/> as subnode to the vbox
> start node)
> 
> * Set the reference account of every new CPU connection in vbox to the
> env session by doing
> my_cpu_connection.ref_account(Genode::env()->cpu_session()). This
> enables you to transfer quota from the reference account to your CPU
> connection.
> 
> * Let env()->cpu_session() transfer its quota to the new CPU
> connections. This is a bit tricky. When transferring, you state the
> percentage of the source-session quota scaled up to
> Cpu_session::QUOTA_LIMIT. So, if you state (Cpu_session::QUOTA_LIMIT /
> 2), this means 50% of the source-session quota while
> (Cpu_session::QUOTA_LIMIT / 3) means 33% and so on. Furthermore, the
> value refers to the quota that is left at the source session not its
> initial quota. Thus, if you want to distribute quota evenly to 3 other
> sessions A, B, C, start with transferring 33% to A, then transfer 50% to
> B, and then transfer 100% to C". For an example see
> Init::Child::Resources::transfer_cpu_quota in os/include/init/child.h.
> It takes the percentages that refer to the initial env quota from the
> init config and translates them to percentages that refer to the latest
> env quota.

I have implemented the above mentioned steps, see [1], and the boot time
of a custom Linux (buildroot) from the bootloader menu to the prompt has
been halved from ~1 min 03 seconds down to ~33 seconds. However it seems
that tweaking/playing around with the quota values [2] has no further
effect on the execution time.
Changing the base-hw super period to 100ms and the timeslice to 1ms in
[3] reduces the boot time to ~19 seconds. I am not quite sure about the
exact reason for the speedup but I presume it is due to the fact that
the super period is much shorter and thus the quota of each thread is
refilled more frequently.

[...]

> Be aware that there might be a problem with CPU quotas on hw_x86_64
> currently. The test os/cpu_quota.run doesn't succeed on hw_x86_64 (it
> states that it is successful but that is a bug because err in
> check_counter in cpu_quota.run is 1 and not 0.01). There might be a
> problem with the timer or the quota calculation (64 bit). I'll have a
> look at this ASAP. However, the test finishes and shows a correct
> CPU-utilization stat over all counter threads. The sourcecode might also
> serve as show case for how CPU quotas (should) work.

I gave the cpu_quota scenario including your changes regarding #1616 [4]
a try on hw_x86_64 but it seems that it does not complete. Should the
test pass successfully with your latest changes?

As this execution time is still a lot slower than e.g. NOVA/Virtualbox,
which boots the same system in about ~7 seconds, there still seems to be
lingering issue(s) with regards to the base-hw scheduling. I would be
glad if you could investigate this problem.

Thanks and regards,
Adrian

[1] -
https://github.com/codelabs-ch/genode/blob/hw_x86_64_muen-vbox/repos/ports/src/virtualbox/thread.cc#L32

[2] -
https://github.com/codelabs-ch/genode/commit/1ffa792da3fdf9850ebf4252f34a4dc19803b6fd
[3] -
https://github.com/codelabs-ch/genode/blob/hw_x86_64_muen-vbox/repos/base-hw/src/core/include/kernel/configuration.h
[4] -
https://github.com/m-stein/genode/commits/1616_cpu_quota_run_some_issues