Aw: Re: Affinity Subspace Mapping

Norman Feske norman.feske at ...1...
Tue Aug 8 18:25:49 CEST 2017

Hello Stefan,

On 03.08.2017 12:27, Stephan Lex wrote:
> I created a testcase in our repository for you, that shows the
> functionality we would like to achieve.
> ...

thanks for the test case. I just gave your branch a try. But please
allow me the remark that I feel quite uneasy about debugging problems on
a fork of an old Genode version. Aside the inconvenience of switching to
an old tool chain, I was left uncertain about the following assumptions:

* 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'?

To lower the bar for people to assist you, it would be of great help if
you rebase a test scenario to the most current version of Genode. So it
becomes much easier to reproduce and we don't run into the risk of
debugging problems that are already solved in a later version of Genode
(not presuming that this is the case for the issue at hand).

> What we were trying to achieve is running init as well as the three
> components on different cores in the system.
> Unfortunately the documentation for the affinity subspacing was a bit
> confusing for us, so it would be great, if you can tell us whether this
> is the right approach or what logic we are still missing.

I have not completely investigated your scenario but made the following
interesting observations while tinkering with it:

* 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.

* 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.

* Unfortunately, the Fiasco.OC kernel debugger is quite incomplete when
  using the pbxa9 platform. I suggest to first debug the problem on a
  more common platform such as x86_32 where the kernel debugger is able
  to show the CPU number of each thread (via the 'lp' command). A quick
  test, however, shows that the 'focnados' base platform is apparently
  tied to ARM. (I get compile errors with ARM register names on x86_32).
  But maybe the base platform can be easily revived for x86_32?

I hope this little input brings you a bit further.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list