[LITMUS^RT] running a task as its execution time

[Björn Brandenburg]

On 15.06.2012, at 08:41, Andrea Bastoni <bastoni at cs.unc.edu> wrote:

> On Fri, Jun 15, 2012 at 4:32 AM, Felipe Cerqueira
> <felipeqcerqueira at gmail.com> wrote:
>> 
>> 
>> 2012/6/14 Youcef Amine Benabbas <s9yobena at stud.uni-saarland.de>
>>> 
>>> Hi Giovani,
>>> 
>>> On Thu, 2012-06-14 at 12:21 -0300, Giovani Gracioli wrote:
>>>> Hello everyone,
>>>> 
>>>> 
>>>> just recompiled the kernel with the modifications and the bug is
>>>> fixed. Thank you Björn.
>>>> 
>>>> 
>>>> I have two more questions. The current version of LITMUS is equivalent
>>>> of which version in the paper "On the implementation of Global
>>>> Real-Time schedulers"? I suppose it is, FE1, with fine-grained ready
>>>> queue, event-driven scheduling, and 1 cpu handling interrupts, Am I
>>>> right?
>>>> 
>>>> 
>>>> I would like to measure also the overhead to send an IPI. Are the
>>>> feather-trace SEND_RESCHED_START and SEND_RESCHED_END events used to
>>>> measure IPI overhead?
>>> 
>>> Yes, they are equivalent. I am working on measuring this overhead plus
>>> other overheads to implement overhead-aware schedulability tests.
>>> 
>>> By the way, I am trying to get a TS_SEND_RESCHED_(START/END) for
>>> real-time tasks, i.e. timstamps with task_type==TSK_RT. Unfortunately I
>>> could not get such timestamps.
>>> 
>>> I followed execution paths producing TS_SEND_RESCHED, but it seemed to
>>> me impossible to get them.
>>> 
>>> I would appreciate your advice regarding measuring IPI latency for
>>> real-time tasks.
>> 
>> 
>> Hi Youcef,
>> 
>> I had that problem before. According to Andrea and Björn, SEND_RESCHED
>> overhead must be collected with the best-effort option in ft2csv (-b).
>> I think it's because of the way the measurement is implemented.
> 
> Hi,
> 
> When you send an IPI from one CPU to another one, you have no simple
> way to know if the receiving CPU is running a real-time task or a
> non-RT task when it receives the IPI. Therefore, to detect the
> TS_SEND_RESCHED_END, you need to consider non-RT tasks as well.
> 

Exactly. Also, SEND_RESCHED measures IPI *latency* (i.e., how long is the IPI "in flight"), which does not delay unrelated tasks. In contrast, something like scheduling  and release overhead actually consumes cycles and delays whatever happened to be scheduled.

Therefore, something like scheduling overhead is only interesting when a real-time task is involved (when accounting for overheads, we don't care about what happens to best-effort tasks). 

IPI latency, however, is always relevant, regardless of which task happens to be scheduled, since  it delays a needed preemption.

- Björn