Dschatz

2.21.12

determining some early configuration for io apic requires either mp tables or ACPI. Talked to Matt and he recommended MP tables.

decided to go with ACPI, its got features we may use later anyhow. Looking specifically at ACPICA.

2.22.12

ACPICA is kind of a mess. I am trying now to just take the components directory and it looks like I only have to modify: acenv.h to include acebbos.h which will configure stuff (I'll base this off of aclinux.h).

Then it should compile, to link will require all the OS dependent code. I'll base that off the unix_xf.c os specific layer. Stub it all out as best I can and see what happens.

4.23.12

Discussion about redoing events and multicore bringup.

• Event space is shared amongst all the cores
• Events can be allocated out of the global pool of events
• Some events (IRQ related as well as synchronous interrupts like faults and exceptions) are not allocatable and well defined by the platform.
• We can route IRQs (and therefore the associated event) to cores
• We can trigger an event on a core (using IPIs, this is a bit more complex on bluegene)
• The mapping between EBBId + EBBFuncNum and Event is global
• Synchronous interrupts are not handled in this case

Multicore bringup

• First core comes up to app
• additional cores can be added dynamically by the application, specify event to occur on that core (one call or two calls? Probably two, can initialize several cores (perhaps in parallel) then broadcast event)
• When core is initialized, lrt bringup occurs (mem, trans + non-lrt trans, eventmgr). Necessary EBBs should already be bound so reps will come up lazily when an event is fired.

Message Manager example

The message manager comes up on core 0 lets say. If you want to send a message to core 3 and it has brought up the low level init but no EBBs yet, we have an issue because the rep for core 3 is not there.

One solution: We allocate N events, one for each possible sending core and bind them each to N different functions (receiveMessageFromCoreN). To send a message, we send an IPI to the correct core with the event number corresponding to this sender. Additionally, we must create a queue on our sender rep for that receiver and enqueue the message.

The receiver message manager rep faults in. The receiver knows, by which function was invoked, who the sender was. It then finds the corresponding rep and finds the queue for this receiver (It can then cache that pointer locally). It can then read the queue and dispatch the method (faulting in the EBB as necessary).