[LITMUS^RT] Reservation synchronization

[Cristina STANGACIU]

Dear Björn,

My name is Cristina Stângaciu. I am currently working at a research 
project which may include an implementation of a table-driven 
(time-triggered) scheduling algorithm. I would like to choose LITMUS as 
a support for my proof of concept, but, I have some questions.

If it is not too much trouble, I would kindly request a little help:

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)?

I have tried to use polling-periodic reservations:

/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 polling-periodic -c 1 
-b 5 -p 10//
//root at dLitmus:/sandbox/my-demo# resctl -n 1002 -t polling-periodic -c 1 
-b 2 -p 10//
//root at dLitmus:/sandbox/my-demo# rtspin -w -p 1 -r 1001 3 10 5&//
//[1] 3493//
//root at dLitmus:/sandbox/my-demo# rtspin -w -p 1 -r 1002 1 10 5&//
//[2] 3494//
//root at dLitmus:/sandbox/my-demo# release_ts//
//Synchronous release at time 2901000.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/

The result (...08-48-17.png) is attached to this email but it doesn't 
seem to be a jitterless execution.

I have also tried to use table-driven reservations:

/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/

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).

So, can I synchronize task execution or at least synchronize the 
reservations, using P-RES?

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 am able to visualize the rtspin execution with kernelshark if I use 
another type of scheduling, but I have problems when using P-RES.

I have attached a screenshot. The "release_ts" command is given from the 
kernelshark.  In the attached file only one process (rtspin) appears, 
but the use case is the same as above (2 table driven reservations, each 
reservation has one task). Moreover, in this case only one execution 
(only one job) can be seen when visualizing the execution of rtspin with 
kernelshark.

Thank you.

Yours sincerely,

Cristina Stangaciu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20200226/37e8090c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-02-26 08-48-17.png
Type: image/png
Size: 10368 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20200226/37e8090c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-02-26 08-56-20.png
Type: image/png
Size: 15929 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20200226/37e8090c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-02-26 09-12-11.png
Type: image/png
Size: 676475 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20200226/37e8090c/attachment-0005.png>