Nemesis

Notes by Paul Coleman and Ben Cichy

The goal of Nemesis is to allow a general purpose processor to provide the functions one would find in specialized DSP peripheral while providing the same control across virtual processors as can be achieved with specialized hardware. The flexibility of the virtual processor system allows resources to be used more efficiently than in a dedicated-peripheral approach.  In order to maximize resource utilization, Nemesis attempts to multiplex the system resources at the lowest level- an approach similar to the micro-kernal philosophy of operating system design.

Nemesis implements Quality of Service (QoS) through a feedback path from the user to the QoS Controller.  The QoS Controller passes the requests onto the QoS Manager which allocates the resources specified by the Controllers request (or the best approximation thereof).  Note that the design of QoS for Nemesis values consistency more than efficiency or speed of execution.  Application QoS depends on the contention of services between clients.  In order to avoid QoS crosstalk, servers must export virtual resources to allow fine-grained scheduling between competing clients.

To minimize crosstalk, servers implement only the minimum required services for the client, and allow sharing for application level processing.  In order to support this view, Nemesis implements a model where all text and data occupy a single virtual address space (although with distinct protection domains).

Nemesis provides low level multiplexing of processor resources through the Virtual Processor Interface - a runtime interface between a domain and the kernel.  The interface uses a shared data structure, the Domain Control Block, to synchronize domain activations. Following a context switch the VPI upcalls to the activated Domain.   This upcall allows the domain to consider scheduling options instead of being forced to resume where last interrupted.

Nemesis' concept of scheduling requires that each application shuld be allocated a share of the processor.  These shares are allocated by the QoS Manager based on the input from the QoS Controller from the user.  The QoS Manager assures that less than 100% of the processor is contracted out while still adhearing to the policies stated by the QoS controller.  The three main purposes for specifiying CPU time QoS are as follows

  1. It must allow applications, users, or user agents to specify an application's desired CPU time
  2. Enable the QoS manager to ensure the processor resource is not over allocated
  3. Enable the scheduler to allocate processor time efficiently

Discussion Points