[LITMUS^RT] release overhead

[Meng Xu]

There are many reasons that may lead to the variance of the execution time
of a software component (such as the overhead value you measured).
One reason is that different runs simply execute different instructions
because the input is slightly different. Another reason is that all types
of interference caused by other workloads (e.g., interrupts) in the systems
can delay the execution of the software component you want to measure. If
you search for research related to "Worst-Case Execution Time" in real-time
systems, you will get more sophisticated answers.

Without knowing what you have done to figure out the question and what you
want to achieve, it is hard to provide insightful answers.

BTW, Dr. Brandenburg discusses the design, implementation, and theory of
LITMUS^RT in detail in his awesome dissertation (
https://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf).
It is a very helpful and insightful material if you are working on
LITMUS^RT.

Meng

On Mon, Jan 6, 2020 at 12:50 AM sasna ms <sasnams.mec at gmail.com> wrote:

> Hi,
>   I am trying to plot graph of release overhead v/s release overhead of
> GSN-EDF scheduler . I had created real time tasks using the command "
> ./mktasks.py -m 8 -t 4 -u 0.5 " and the resulting overhead was traced using
> feature-trace tool. The result was
>            SCHED2                       0
>            RELEASE                 7546
>            CXS                            0
>            SCHED                        0
>            RELEASE LATENCY  23996
>            SEND-RESCHED        62376
> Each time when i run this i am getting a different value. What is the
> reason for that? Should that value remain constant for a particular
> scheduler?
> _______________________________________________
> 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/20200106/22a8e482/attachment.html>