[LITMUS^RT] Schedulability checking
Felipe Cerqueira
felipeqcerqueira at gmail.com
Fri Feb 17 18:28:48 CET 2012
Hmm... The overhead costs obtained from ft_tools are not 100% exact because
of the unpredictabilities of the system, but at least the approach doesn't
depend on scheduling decisions, right? What I was trying to do is much less
reliable.
Andrea recommended me to read these papers, because I don't know yet how to
use ft_tools information.
U. Devi. Soft Real-Time Scheduling on Multiprocessors. PhD thesis,
University of North Carolina, Chapel Hill, North Carolina, 2006.
B. Brandenburg, H. Leontyev, and J. Anderson. Accounting for in-
terrupts in multiprocessor real-time systems. In Proc. of the 15th
IEEE Int’l Conf. on Embedded and Real-Time Computing Sys. and
Apps., pp. 273–283, 2009.
If I have questions, I'll ask here.
Thanks!
Felipe
2012/2/17 Björn Brandenburg <bbb at mpi-sws.org>
> On Feb 17, 2012, at 6:03 PM, Felipe Cerqueira wrote:
> >
> > Litmus-RT papers usually include schedulability comparisons that use
> schedulability tests and tasks inflated with overhead costs.
> > Is it possible to check schedulability by actually running the tasks?
> >
> > I've been trying to modify rtspin to do that, but I'm facing some
> problems.
> >
> > […]
> > Has anyone already done schedulability checking inside the application?
> I thought it would be easier to do than embedding overhead costs within the
> tasks.
> > In case it is a bad approach, I can try the usual way.
>
>
> I think your approach fundamentally doesn't work. Schedulability is an
> analytical property. A task set is schedulable if it can be shown that it
> won't miss a deadline (in the hard real-time case) for *any* legal arrival
> sequence. Observing whether deadlines are missed in the task can only
> establish that it is *not* schedulable, but not the inverse.
>
> By the way, rtpsin spins for approximately 90% of its configured WCET
> because the delay loop isn't exact. It may overshoot a little; hence
> setting the delay to 100% leads to the problems that you've described.
>
> - Björn
>
>
> _______________________________________________
> 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/20120217/c35970b9/attachment.html>
More information about the litmus-dev
mailing list