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

[Andrea Bastoni]

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.

Thanks,
- Andrea

>
> Thanks,
> Felipe
>
>
>>
>>
>> Best regards,
>> Youcef
>>
>>
>> >
>> >
>> > Best regards,
>> > Giovani
>> >
>> > On Thu, May 31, 2012 at 4:46 AM, Björn Brandenburg <bbb at mpi-sws.org>
>> > wrote:
>> >         On May 31, 2012, at 7:34 AM, Jonathan Herman wrote:
>> >
>> >         > We encountered this same issue with the mixed-criticality
>> >         > and EDF-HSB schedulers. Our poor implementation was to
>> >         remove the '&&
>> >         > !preempt' before job_completion in the _schedule method, and
>> >         > compensate by adding a check for is_queued(task) in the
>> >         _requeue
>> >         > method so that job_completion could be called after a
>> >         preemption
>> >         > without causing a BUG.
>> >         >
>> >         >> It seems to me the right thing to do is to not add unlinked
>> >         tasks to the ready queue if they have no budget remaining.
>> >         Then it is safe to process the job completion even if it
>> >         coincides with a preemption.
>> >         >
>> >         > This is a better solution.
>> >
>> >
>> >
>> >         I have pushed a proposed fix to prop/budget-bug-fix. It seems
>> >         to fix the issue for me. Everyone, please test & review.
>> >
>> >         Giovani, can you please confirm that this fixes the bug?
>> >
>> >         Thanks,
>> >         Björn