Skip to content
Jim Cadden edited this page May 17, 2013 · 8 revisions

Weekly Discussion & Focus

Values of our application

Made in the U.S.A., Elastic, Fault Tolerant, Large scale, SMP parallel performance, HW/device exploitation (interconnects), General purpose , Reusability (not a single-purpose exploit), Incremental strategy, Legacy support, Customizability , Composability,

Application Demonstrations

Scale at 16k cores, Multiple datacenter scale systems, Long-standing application,

Applications

Medical, Game Server


Summary of the EbbRT Translation system (static root table)

The translation system is one of the few responsibilities of the low-level runtime (lrt) domain of EbbRT functionality. The job of translation is to convert an generic Ebb object (an ID) into the execution of a method of the local representative (rep) of that Ebb. The common path of translation involves a lookup in a local translation cache that contains references to the local ebb representative of a particular ebb id.

A translation cache miss will check a global translation table for needed reference. Upon a hit in the global table, the reference and id will be added to that cores local translation table. Depending on the Ebb type of the object being referenced, or the current state of the ebb, a new representation Ebb maybe allocated for during the miss process. Presumably, if the reference is not found in the node local view of the global address space, a global miss, the Ebb Manager ebb will handles a remote lookup for the nesessary information.

Local ebb allocations happen in a lazy fashion, following misses in the translation table lookups. This lazy initiation is allowed for all system ebbs, including those most primitive (Ebb Manager, Memory Manager, Event Manager, Network, etc.) to be created only when they are first needed. To bootstrap this process, we statically construct a number of Ebb roots on boot. An initial global translation table (aka. root table) is populated with the Ebb roots necessary to construct the most primitive of ebb objects. This will prevent a global miss before the system is fully initialized. The root table is fixed and will eventually need to be replaced by a more dynamic/distributed global translation functionality provided by the Ebb Manager.

Static ebbs are included as binary modules linked into our application images. Include is an application configure data containing the id, ordering and dependancies of that application. A temporary and fixed global table is populated with each ebbs ID and ref. This will prevent any globl misses of the primitive ebbs and the system begins to lazily initialize.