[LITMUS^RT] Query on Resource Reservation

[Björn Brandenburg]

> On 2. Aug 2017, at 21:01, Antonio Vaz <antonio.k.vaz at gmail.com> wrote:
> 
> > It’s just a polling server that’s activated sporadically
> By "activated sporadically", do you mean, it is activated when a task arrives?

Yes, exactly.

> > Not sure what you mean.
> To frame my question better, in polling periodic server, if the task misses the instance when the server becomes active, it will have to wait 1 full period until it can be scheduled. 

Yes, this is true for the periodic polling server. 

> In polling sporadic server, is the server invoked every time a task becomes ready in it's reservation?

Yes, if it was previously inactive. 

> What is the worst-case delay a task might experience?

Depends on the state of the reservation. If it is inactive, it immediately becomes active and the delay experienced by the task is determined just by its own execution time and higher-priority interference. 

If, however, the reservation was already active because of an arrival no more than P time units before (where P is the reservation period), then the task can incur extra delay up to P-B time units (where B the budget) if the reservation has already depleted its budget. 

In short, when a task arrives at time t1, and the last time that the reservation was activated is t0, then the task will be eligible for service no later than time max(t1, t0 + P).

> 
> > If the sporadic polling server was previously inactive, and if no higher-priority reservation exists, then, yes, the sporadic polling server will become active and schedule its newly arrived client.
> Does this mean that in a single period once a task is scheduled, the remaining budget is lost?

In the current implementation, the remaining budget is donated as slack. If another client of the reservation arrives before the slack has been (completely) consumed, then the leftover budget is taken back (“undonated”) and available to the newly arrived client. 

> 
> The parameter param.cpu = rid; assigns the task to the reservation.
> Is it possible to change the reservation of a task online? (while the task is in RT mode)

Not with the current plugins. There’s a callback in the LITMUS^RT framework for changing task parameters on the fly, but none of the default plugins implement it. You would have to contribute that support yourself.

Otherwise, just transition a task out of real-time mode, change the reservation, and then re-transition it back into real-time mode; this should always work for any plugin. 

> In the case of table driven scheduling, if there are no tasks ready, it yields the processor to background tasks. 

Yes, this is true in the current implementation.

> What if a task is ready just after that? Will the processor be given back to the table driven scheduler?

Yes. Just check how the plugins handle task arrivals and you will see that the scheduler is triggered in such a case, which will allow the table-driven reservation to dispatch its client.

Regards,
Björn