Litmus (RTSS2006)

Component

  • Each processor contains an Advanced Programmable Interrupt Controller (APIC)
    • contains a local timer that generates local timer interrupts on each processor. (tick to make check and make system decision)
      • Quantum size: a multiple of the period between timer interrupts.
  • Plugin-based framework
    • Each scheduling algorithm is implemented as a plugin component.
      • A component is specified by a collection of function pointers, which reference the functions that define the behavior of the implemented algorithm
        • initialization, which installs the component into the scheduler at boot time;
        • tick handler, which is called every timer interrupt;
        • and decision, which scheduling decisions
  • Data Structure
    • A ready queue implemented as a linked list.
    • A release queue is a queue of queues, and these queues are ordered in the release queue by the release time of the tasks they contain (earliest to latest)
    • The Linux runqueue is a complex per-CPU Linux data structure that maintains all Linux tasks assigned to that CPU.

Steps:

  • align local timer interrupts: . Creating such an alignment would require that all local timers be started at the same time.

  • Initialization function. This function is called during system boot. A kernel boot option determines which scheduler to run, and therefore which initialization function to call. This function installs its component into the scheduler by changing several function pointers to reference the functions of the component.

For Litmus:

  • showsched: show the current scheduler.
  • setsched GSN-EDF: set the scheduler (but non-RT task still use linux CFS)
  • rt_launch: run an arbitrary binary as a real-time process.
  • rtspin 10 100 5: spin task with C=5ms, T=100ms and t=5s.

    • -v: print per job statistic
    • -p 1: on processor 1
    • -q priority number: For FP scheduling
    • -w: wait for synchronous release to occur before starting

      • Example of synchronous a task set `` Create two tasks: ~~rtspin -v -w -p 1 -q 1 5 50 5 & ~~rtspin -v -w -p 1 -q 2 10 100 5 & View information on waiting tasks ~~cat /proc/litmus/stats Release the two tasks. ~~ release_ts

        ``

  • st-trace-schedule: see scheduling sequence.

    • Example: ``

      $setsched GSN-EDF\ $st-trace-schedule my-trace: start recording\ $ rtspin -w 10 100 5 & $ rtspin -w 20 50 5 & $ rtspin -w 5 30 5 & $ rtspin -w 5 20 5 & Now release them with release_ts and wait for them to finish: $ release_ts Released 4 real-time tasks. $ wait

      ``

  • st-job-stats: allows to easily obtain job statistics from a scheduling trace. $ st-job-stats my-trace.bin | head

Process Overheads

ft-trace-overheads my-experiment

  1. Sort ft-sort-traces overheads_*.bin 2>&1 | tee -a overhead-processing.log

  2. Split ft-extract-samples overheads_*.bin 2>&1 | tee -a overhead-processing.log

  3. Combine ft-combine-samples --std overheads_*.float32 2>&1 | tee -a overhead-processing.log

  4. Count available samples ft-count-samples combined-overheads_*.float32 > counts.csv

  5. Shuffle & truncate ft-select-samples counts.csv combined-overheads_*.float32 2>&1 | tee -a overhead-processing.log

  6. Compute statistics ft-compute-stats combined-overheads_*.sf32 > stats.csv

Visualize

  • st-draw xxx.bin

dp

  1. Feather-Trace records most overheads in cycles. To convert to microseconds, one must provide the speed of the experimental platform, measured in the number of processor cycles per microsecond, with the --cycles-per-usec option. The speed can be inferred from the processor's spec sheet (e.g., a 2Ghz processor executes 2000 cycles per microsecond) or from /proc/cpuinfo (on x86 platforms).

  2. 2Ghz and Cortex™-A7 Octa core CPUs with Mali Mali-T628 MP6 GPU

  1. overhead trace old version http://www.cs.unc.edu/~anderson/litmus-rt/doc/tracing.html

https://wiki.litmus-rt.org/litmus/Tracing

  1. see task set status: cat /proc/litmus/stats

results matching ""

    No results matching ""