Commit d78a95b6 authored by Marco Maida's avatar Marco Maida 🌱
Browse files

Added a draft of README

parent 1372ee7d
# rbf-trace
From process tracing to response-time analysis.
## Structure
The entire project is structured as a pipeline of "filters", in which each submodule yields to the next one a higher-level, refined
piece of information. The entire project is structured as a big stream, that processes one event at a time.
**TODO** make proper scheme, define dictionary?:
raw low-level events -> **EVENTS GENERATION** ---refined, high-level event--> **EVENTS PROCESSING** --- arrival of process --> **REAL-TIME**
### Events generation
This module performs the low-level tracing of the processes. Its goal is to offer a stream of events that can be consumed by
other modules.
Note that, by creating a new events generator module, you can synthesize any kind of trace starting from any low-level data.
The `EventsGenerator` trait is used to communicate with the other modules. The goal of this project is to use `ftrace` as
provider of events, but you can implement other generators for testing purposes.
The outputted event will have one of the following `TraceEventType`:
- `Activation`, when the process enters the ready queue
- `Deactivation`, when the process self-suspends for some reason
- `Preemption`, when the process is preempted
- `Restore`, when the process starts executing
- `Exit`, when the process finishes
### Events processing
This module's purpose is to build any kind of high-level information that starts from a trace. This is achieved by repeatedly
querying the events generator, which will yield a `Some(TraceEvent)` or `None` when the trace is finished.
Internally, the events processing module collects the information about each of the processes (identified via their PID). For each process,
the module checks the consistency of the sequence of the events using a finite-state machine. When a valid sequence from `Activation`
to `Deactivation` (or `Exit`) is detected, an `ActivationCycle` is completed, and an `Arrival` (a tuple `(arrival_time, cost)`) is computed.
### Real-time
This module contains structures and algorithms that belong to the real-time theory domain (arrival curves, computing RBF, ...).
At this level, the concept of trace event is no longer relevant, since the events processing module takes care of it. At this level,
we expect only a stream of `Arrival` structures.
## Profiling
You can draw a graph to find the most used or expensive functions.
### Dependecies
To use the profiler, you need `gperftools` and `graphviz`.
#### gperftools
There are instructions in their repository but it's roughly the following:
- Download package from [releases](https://github.com/gperftools/gperftools/releases).
- Run `./configure`
- Run `make install`
#### graphviz
Graphviz is needed to use `dot`.
With `apt`:
```
sudo apt install graphviz
```
### Using the profiler
You can run a profiler with
```
make rt-machine-profile
```
or
```
make rt-spin-profile
```
How to read, in short:
- Every box is a function
- Every line is a function call
- In the bottom right corner of each box, you can see the the cost of that function
- If you want more info, check out the [pperf documentation](https://github.com/google/pprof/blob/master/doc/README.md)
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment