[LITMUS^RT] Reservation synchronization

[Björn Brandenburg]

> On 26. Feb 2020, at 08:39, Cristina STANGACIU <cristina.stangaciu at cs.upt.ro> wrote:
> 
> 1. Is it possible to synchronize reservations, when using P-RES? How else could I obtain a perfectly periodical (jitterless) execution for a given thread (considering job execution start times)?

To my knowledge, enforcing a schedule without scheduling or response-time jitter is not something that LITMUS^RT has been used for before. We typically care about bounding maximum response times / ensuring schedulability, which means any interval of execution before a job’s deadline is ok. In this sense, LITMUS^RT implements support for periodic (and sporadic) tasks, where the maximum scheduling jitter is implicitly dependent on a task’s relative deadline. The only exception to this is table-driven reservations, where you get to choose arbitrary tables. 

> I have tried to use polling-periodic reservations:
> 
> […]
> The result (...08-48-17.png) is attached to this email but it doesn't seem to be a jitterless execution. 

Polling reservations by definition do not ensure inter-allocation jitter better than 2×PERIOD-BUDGET.

> I have also tried to use table-driven reservations:

Correct; that’s the right way to ensure allocations at specific points in time. 

> 
> setsched Linux
> root at dLitmus:/sandbox/my-demo# setsched P-RES
> root at dLitmus:/sandbox/my-demo# showsched
> P-RES
> root at dLitmus:/sandbox/my-demo# resctl -n 1001 -t table-driven -c 1 -m 10 '[0,5)'
> 
> root at dLitmus:/sandbox/my-demo# resctl -n 1002 -t table-driven -c 1 -m 10 '[5,7)' 
> root at dLitmus:/sandbox/my-demo# rtspin -w -p 1 -r 1001 3 10 5&
> [1] 3775
> root at dLitmus:/sandbox/my-demo# rtspin -w -p 1 -r 1002 1 10 5&
> [2] 3776
> root at dLitmus:/sandbox/my-demo# release_ts
> Synchronous release at time 3381000.00ms.
> Released 2 real-time tasks.
> root at dLitmus:/sandbox/my-demo# wait
> [1]-  Done                    rtspin -w -p 1 -r 1001 3 10 5
> [2]+  Done                    rtspin -w -p 1 -r 1002 1 10 5

This looks reasonable to me. That should work as intended. 

> 
> The result (...08-56-20.png) is attached to this email, but as one can see between 50ms and 60ms there is an execution of the second rtspin outside the space that should have been allocated to reservation 1002 (namely 55-57ms). 

Looking at the schedule, it appears to be heavily affected by release jitter. Are you running this in a virtual machine by any chance? If so, all timing is off. 

> 2. When I attach some processes (rtspin for example) to reservations, I am not able to visualize all the processes in kernelshark (https://kernelshark.org/). Could somebody tell me: why is this so? 

I have never used kernel shark and don’t know how it works. We’re not intentionally breaking it, but  then I also don’t know what it depends on. Patches are welcome if figure this out. 

- Björn