42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
# Emulation overview
|
|
|
|
The emulator `ovniemu` reads the events stored during runtime and
|
|
reconstructs the execution, restoring the state of each thread and CPU
|
|
as time evolves. During the emulation process, a detailed trace is
|
|
generated with the state of the execution in the Paraver PRV format.
|
|
|
|
The emulator has an execution model to represent the real execution that
|
|
happened on the hardware. It consists of CPUs which can execute multiple threads
|
|
at the same time.
|
|
|
|
The emulator uses several models to identify how the resources are being
|
|
used. The following diagram despicts the resource, process and task
|
|
model.
|
|
|
|
|
|
|
|
The resource model directly maps to the available hardware on the
|
|
machine. It consists of clusters which contains nodes, where each node
|
|
contains a set of CPUs that can execute instructions.
|
|
|
|
The process model tracks the state of processes and threads. Processes
|
|
that use the same CPUs in a single node are grouped into looms.
|
|
|
|
The task model includes the information of MPI and tasks of the
|
|
programming model (OmpSs-2).
|
|
|
|
## Design considerations
|
|
|
|
The emulator tries to perform every posible check to detect if there is
|
|
any inconsistency in the received events from the runtime trace. When a
|
|
problem is found, the emulation is aborted, forcing the user to report
|
|
the problem. No effort is made to let the emulator recover from an
|
|
inconsistency.
|
|
|
|
The emulator critical path is kept as simple as possible, so the
|
|
processing of events can keep the disk writting as the bottleneck.
|
|
|
|
The linter mode enables more tests which are disabled from the default
|
|
mode to prevent costly operations running in the emulator by default.
|
|
The linter tests are enabled when running the ovni testsuite.
|