Rodrigo Arias Mallo
815633221d
The nOS-V events are modified in two ways: 1) to create a parallel task the new VTC event must be used and 2) all task events for both normal (VTc) and parallel (VTC) tasks require an extra argument in the payload to indicate the body id. As a consequence, the nOS-V model version is now increased to 2.0.0. Additionally, all the channel PRV flags are set to PRV_SKIPDUPNULL, so duplicates are only emitted if they are not null. It solves the problem when a task switches to another task with the same body id. A new Paraver configuration is added for the body id.
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# nOS-V model
|
|
|
|
The [nOS-V library][nosv] implements a user space runtime that can schedule
|
|
tasks to run in multiple CPUs. The nOS-V library is instrumented to
|
|
track the internal state of the runtime as well as emit information
|
|
about the tasks that are running.
|
|
|
|
[nosv]: https://github.com/bsc-pm/nos-v
|
|
|
|
## Task model
|
|
|
|
The nOS-V runtime is composed of tasks that can be scheduled to run in
|
|
threads. Tasks can be paused and resumed, leaving the CPUs free to
|
|
execute other tasks.
|
|
|
|
In nOS-V, parallel tasks can also be scheduled multiple times and the
|
|
same task may run concurrently in several CPUs. To model this scenario,
|
|
we introduce the concept of *body*, which maps to each execution of the
|
|
same task, with a unique body id.
|
|
|
|
|
|
|
|
A normal task only has one body, while a parallel task (created with
|
|
`TASK_FLAG_PARALLEL`) can have more than one body. Each body holds the
|
|
execution state, and can transition to different execution states
|
|
following this state diagram:
|
|
|
|
|
|
|
|
Bodies begin in the Created state and transition to Running when they
|
|
begin the execution. Bodies that can be paused (created with the flag
|
|
`BODY_FLAG_PAUSE` can transition to the Paused state.
|
|
|
|
Additionally, bodies can run multiple times if they are created with the
|
|
`BODY_FLAG_RESURRECT`, and transition from Dead to Running. This
|
|
transition is required to model the tasks that implement the taskiter in
|
|
NODES, which will be submitted multiple times for execution reusing the
|
|
same task id and body id. Every time a body runs again, the iteration
|
|
number is increased.
|
|
|
|
## Task type colors
|
|
|
|
In the Paraver timeline, the color assigned to each nOS-V task type is
|
|
computed from the task type label using a hash function; the task type
|
|
id doesn't affect in any way how the color gets assigned. This method
|
|
provides two desirable properties:
|
|
|
|
- Invariant type colors over time: the order in which task types are
|
|
created doesn't affect their color.
|
|
|
|
- Deterministic colors among threads: task types with the same label end
|
|
up mapped to the same color, even if they are from different threads
|
|
located in different nodes.
|
|
|
|
For more details, see [this MR][1].
|
|
|
|
[1]: https://pm.bsc.es/gitlab/rarias/ovni/-/merge_requests/27
|
|
|
|
## Subsystem view
|
|
|
|
The subsystem view provides a simplified view on what is the nOS-V
|
|
runtime doing over time. The view follows the same rules described in
|
|
the [subsystem view of Nanos6](../nanos6/#subsystem_view).
|