[LITMUS^RT] feather-trace events

[Glenn Elliott]

On Apr 22, 2014, at 6:07 PM, Namhoon Kim <namhoonk at cs.unc.edu> wrote:

> Hi,
> 
> I'm doing some real-time experiments using FMLP protocol. I want to measure the execution time of a task by using feather-trace-tools. Feather-trace record switch_to, switch_away, block, resume, and completion. I know switch_away means that a job stops executing, but the block event of the job is recorded after the switch_away event. The resume and switch_to events are similar to the block and switch_away. 
> What kind of codes is executing between switch_away and block events? Should I add the time between switch_away and block to a job's execution time? Or is it already included in locking overheads?
> 
> Thanks,
> Namhoon

Hi Namhoon,

As I understand it:

resume: Recorded when a task is woken up—when the task becomes ready to be scheduled, but it may not have the priority to be scheduled.  Such an event will be logged when a task blocked on an FMLP semaphore is acquires the semaphore.

block: Recorded whenever a task “voluntarily" relinquishes a processor—that is, when the task is unscheduled for reasons other than preemption or job completion.  These events will be recorded when a task blocks on an FMLP semaphore.  You’ll also see these recorded for any operation that may cause a task to sleep/block.  Examples: I/O, pthread synchronization, etc.

switch_to: Recorded when the CPU begins executing a new task.

switch_away: Recorded when a CPU stops executing a task.

I believe that switch_to and switch_away give you ground truth (at least as close as we can manage) as what is actually executed/scheduled at a given moment.  This may be different from the task _linked_ to a CPU by a Litmus plugin.  Plugins like G-EDF will first link a task to a CPU (the scheduling decision it wishes to make) and then trigger a preemption on the linked CPU (preempt_if_preemptable() -> litmus_reschedule()).  The triggered CPU will then act upon the prior scheduling decision.

Regarding the ordering of recorded events, you can chalk this up to how the code paths are taken.  I wouldn’t worry too much about ordering issues, as long as the ordering of events is consistent.  If you really want to get into the details, you’ll have to dig through litmus-rt/kernel/sched/core.c and litmus.c.  This is the code where Litmus plugins into the Linux scheduler, so the code can get complicated.  You should also be aware that events may sometimes appear out-of-order in sched_trace—you have to sort recorded events by timestamp to get the order in which the events occurred (not the order in which they were logged).

-Glenn