Aw: Re: Aw: Re: Affinity Subspace Mapping

[Stephan Lex]

Hello Norman,


>* Do I need to use the argos-research/genode repository with the
> branch called 'checkpointRestore'?
>
>* Do I need to create a build directory for your customized version
>  of the base-foc platform, called 'focnados_pbxa9'?

My testcase is supposed to work with Genode 16.08, Fiasco.OC and pbx-A9 platform. You should be able to test it with vanilla Genode 16.08 in a build directory foc_pbxa9 with the original Genode 16.08 arm toolchain. Focnados and the rest of our Rtcr component is not used in this testcase.
Unfortunately we could not rebase the testcase for 17.05 as it is part of my final thesis, that is based on 16.08 and understanding the changes for 17.05 and changing it would exceed my timely scope.


>* Even though you instruct Qemu to emulate a 4-core machine, the
>  Platform::affinity_space method reports a physical affinity space of
>  2x1. Maybe the CPU detection is at fault? Or the kernel indeed
>  only sees 2 CPUs? Anyhow, the logical affinity space of 4x1 as defined
>  in your init configuration is ultimately mapped to a physical affinity
>  space of 2x1, which is certainly not your intention. 

In my case an inserted log reports the desired 4 cores from Platform::affinity_space. The log is located in <GENODE-DIR>/repos/base-foc/src/core/platform.cc inside Platform::affinity_space and outputs the variable 'cpus_online'
 
>* The member variable '_location' is designated for the location of a
>  thread within the physical affinity space but it is not used anywhere.
>  Instead, the value should somehow end up being specified to a kernel
>  operation during the thread creation. Hence, regardless of the
>  affinity arguments, they remain without effect.

This is a bit confusing for me. As i understand it following things should happen in my case:
At child creation i pass a capability for a cpus session as well as a Child:Initial_thread object that is seeded with the same cpu session. I create the cpu session by opening a connection to it and passing the desired affinity with it. Shouldn't this be enough to let the child use this affinity, or did i miss something there?

I also attached a little image for you that shows how i want the components to be bound repectively. 
First, is it possible to bind different components to fixed different cores like shown in the image?
Second, is it possible to dynamically spawn a child from within parents (in my example affinity_test_parent) code on another core?

If my approach of distributing the components to different cores is not correct, it would be very good for me, if you could tell me how such a partition has to look as the Genode framework intends it.


Thank you and kind regards,
Stephan Lex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: comment.png
Type: image/png
Size: 22997 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20170824/fd52b816/attachment.png>