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
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
