[LITMUS^RT] RT-litmus behaviour under real-workloads

[Björn Brandenburg]

> On 15. Feb 2018, at 10:50, Ashraf E. Suyyagh <mrsuyyagh at gmail.com> wrote:
> 
> I would write a parser for the old st-trace tool if only I knew where to begin. There is no sufficient documentation of how the data is stored in the bin files, that is what is the formatting and order. Any clues/hints? Thanks

Use the source. Specifically, look at the code that generates the trace. A per-CPU trace file is just a sequence of simple C structs that are self-explanatory. 

	https://github.com/LITMUS-RT/litmus-rt/blob/linux-4.9-litmus/include/litmus/sched_trace.h

Specifically, each event is a struct of type st_event_record, which consists of a header and a union of event-specific fields.

	https://github.com/LITMUS-RT/litmus-rt/blob/linux-4.9-litmus/include/litmus/sched_trace.h#L99

Here’s how the existing tools load the data: just mmap the file and use it as a giant array of st_event_record structs.

	https://github.com/LITMUS-RT/feather-trace-tools/blob/0a9701c7be2ef0256bb434d01a9261d9b345bdc6/src/load.c#L51-L62

However, the format is so trivial, it’s also easy to load it with Python or some other language of your choice. For instance, see here:

	https://github.com/LITMUS-RT/feather-trace-tools/blob/master/sched_trace/format.py

HOWEVER, note that the linked code works for the *current* trace format; you’ll have to do something equivalent for your old version.

By the way, the git history of the feather-trace-tools repo is continuous, so you can easily see what changed between the versions going back all the way to the very beginning.

	https://github.com/LITMUS-RT/feather-trace-tools/releases

Back-porting the current tools to an older trace format should be pretty easy, actually. 

- Björn