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

[Felipe Cerqueira]

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.

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
> >
> >
> >
> > _______________________________________________
> > litmus-dev mailing list
> > litmus-dev at lists.litmus-rt.org
> > https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20120614/d064ef82/attachment.html>