GSoC Project | Basic Support for Trace Compass

Ravindra Kumar Meena rmeena840 at gmail.com
Wed Jul 24 09:04:22 UTC 2019


>
> This approach makes no sense to me.
>
> Per CPU you receive three record events in succession:
>
> [19:32:26.679099590] (+0.000046608) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" : container =
> 216 ), data = 167837707 }
> [19:32:26.679099590] (+0.000000000) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
> container = 209 ), data = 32320 }
> [19:32:26.679099590] (+0.000000000) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
> 215 ), data = 151060501 }
>
> They have all the same timestamp.
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
> timestamp (per CPU) and the data (per-CPU, this is the thread ID).
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
> timestamp matches, you use the values of the current event and the
> values stored before to output an LTTNG sched_switch event.
>

I am trying this approach but I think there is one problem with it. When
RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to
receive it's next_* values.

e.g.

ab //RTEMS_RECORD_THREAD_SWITCH_OUT
bc //RTEMS_RECORD_THREAD_STACK_CURRENT
cd //RTEMS_RECORD_THREAD_SWITCH_IN

Think this example as output in babeltrace where first character is of
prev_comm value and second character is of next_comm value. Since we will
be writing just after receiving c(third row) we can't get d values.

For this, we should have d value so that we can write it in
RTEMS_RECORD_THREAD_SWITCH_IN event with next_comm value.




-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190724/87b5f2d3/attachment-0002.html>


More information about the devel mailing list