[LITMUS^RT] running rtspin and calculate deadline miss ratio? -- Sisu

[Björn Brandenburg]

On Apr 20, 2013, at 7:41 AM, Sisu Xi <xisisu at gmail.com> wrote:

> Hi, Björn:
> 
> Could you please provide some readme file or Makefile in this tools? That would help us understand the code better.
> 
> Thanks very much!
> 
> Sisu
> 
> 
> On Thu, Apr 18, 2013 at 12:41 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> On Apr 17, 2013, at 7:55 PM, Jonathan Herman <hermanjl at cs.unc.edu> wrote:
> 
> > A python example of this process can be found here: https://github.com/hermanjl/experiment-scripts/blob/master/parse/sched.py. That script does not maintain a heap to parse out of order records; it just ignores them.
> >
> >
> > On Wed, Apr 17, 2013 at 1:45 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> > Just for clarification about out-of-order records: records are in a partially sorted order.  You only need a sorted lookahead buffer of a few hundred records to be reasonably sure that your records are in order.
> >
> >
> > On Apr 17, 2013, at 1:43 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> >
> >> Hi Sisu,
> >>
> >> I believe you should compute deadline misses by analyzing shech_trace logs.  /dev/litmus/sched_trace# has a character device for each CPU.  See "Recording Scheduling Traces" here: https://wiki.litmus-rt.org/litmus/Tracing
> >>
> >> You will have to write your own tool to combine the binary recordings for each CPU (each is timestamped).  The easiest way to do this is:
> >> 1) mmap() each sched_trace file into your analysis application.
> >> 2) Treat each mmap()'ed file as a giant C-array of "struct st_event_record".  You may want to #include sched_trace.h from litmus-rt/include/litmus to get the struct definitions.
> >> 3) Records can appear out of order, so for each stream, take the first 50-or-so records and put them into a single timestamp-ordered minheap.
> >> 4) Process each record one at a time by popping the first record on the min-heap.  Keep the min-heap full by moving more records from the arrays.
> >>
> >> (An alternative approach is to qsort() each array (or just the first X-elements of the array), and process the record with the smallest timestamp at the heads of the record streams.)
> >>
> >> Detecting deadline misses is then pretty straight forward once you've got this set up.  A job can be uniquely identified by its TID, and Job Number.  Every job has one release record, which includes a deadline.  Correlate this release record (by matching <TID, Job#>) to a unique completion record.  A deadline miss has occurred if the completion time is later than the deadline.
> >>
> >> Some tips:
> >> (1) The user processes' notion of a job can differ from the kernel's notion of a job if you use budget enforcement.  Accounting for this requires more complex processing of the sched_trace data.  I have some patches in the works that makes this correlation easier to do, but it's not ready for prime-time.
> >> (2) If your system is severely overutilized, that the regular tasks that read the sched_trace buffers and write them to disk can be starved.  This can cause the sched_trace ring buffers to overflow, resulting in the loss of tracing data.  You can control the size of the sched_trace buffers at Litmus compilation time (see CONFIG_SCHED_TASK_TRACE_SHIFT).  However, the kernel may refuse to compile if CONFIG_SCHED_TASK_TRACE_SHIFT and NR_CPUS lead to too much sched_trace buffer space---the binary kernel image becomes too big.  You have to hack other aspects of the kernel to get larger buffers, but it is tricky.  Let me know if you run into this problem.
> >> (3) (This holds for ft_tracing as well.)  I find it easier to dump logs to shared memory (RAM disk) during tracing because this causes fewer overheads.  I then copy the trace data out of RAM and write it to disk after experimentation is over.  Ubuntu has a RAM disk already set up for you at /dev/shm.  Just dump data to /dev/shm and read back the files later.  Of course, your system has to have sufficient RAM to make this work.
> 
> 
> Just to add my version of the same: I've pushed a repository to https://github.com/brandenburg/sched-trace-tools. There's a tool called st_job_stats that will convert sched_trace data into a CSV table with the following columns:
> 
>         - Task ID (PID)
>         - Job ID
>         - Period
>         - Response time
>         - Did the job miss its deadline?
>         - Lateness = finish time - absolute deadline
>         - Tardiness = max(0, Lateness)
> 
> There are multiple filtering options for st_job_stats. Import the resulting table(s) into any spreadsheet app to compute the deadline miss ratios, statistics concerning response times, etc.  Hope this helps.


Sorry, this is unsupported code. I don't have time to offer much assistance. It's relatively clean code, though, so it should be straightforward to read.

- Björn




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130420/fb783d64/attachment.html>