On 24/07/2019 11:04, Ravindra Kumar Meena wrote:
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.
You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment above. In these two record events all you need for the sched_switch event is contained.
-- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
