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/s...
[2] - https://github.com/codelabs-ch/genode/commit/1ffa792da3fdf9850ebf4252f34a4dc... [3] - https://github.com/codelabs-ch/genode/blob/hw_x86_64_muen-vbox/repos/base-hw... [4] - https://github.com/m-stein/genode/commits/1616_cpu_quota_run_some_issues