All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: sched_switch event
@ 2014-02-06 20:18 Thibault, Daniel
  0 siblings, 0 replies; 2+ messages in thread
From: Thibault, Daniel @ 2014-02-06 20:18 UTC (permalink / raw)
  To: lttng-dev

-----Message d'origine-----
>   In linux-source-3.2.0/include/trace/events/sched.h, or
>   linux-headers-3.2.0-53/include/trace/events/sched.h, or
>   lttng-modules/instrumentation/events/mainline/sched.h,
>   we have in part:
>
>	TP_fast_assign(
>		memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
>		__entry->prev_pid	= prev->pid;
>		__entry->prev_prio	= prev->prio;
>		__entry->prev_state	= __trace_sched_switch_state(prev);
>		memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
>		__entry->next_pid	= next->pid;
>		__entry->next_prio	= next->prio;
>	),

   Scratch that, lttng-modules/instrumentation/events/lttng-module/sched.h has the same code, and I now realise the TP_fast_assign is not switching the prev_comm and next_comm fields (it is correctly mapping __entry->next_comm to next->comm), it's just that the copies are declared out of order.  TP_fast_assign is essentially a parallelised process.

   Sorry about the false alarm.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS) R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada <http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* sched_switch event
@ 2014-02-06 20:04 Thibault, Daniel
  0 siblings, 0 replies; 2+ messages in thread
From: Thibault, Daniel @ 2014-02-06 20:04 UTC (permalink / raw)
  To: lttng-dev

   In linux-source-3.2.0/include/trace/events/sched.h, or
   linux-headers-3.2.0-53/include/trace/events/sched.h, or
   lttng-modules/instrumentation/events/mainline/sched.h,
   we have in part:

TRACE_EVENT(sched_switch,

	TP_PROTO(struct task_struct *prev,
		 struct task_struct *next),

	TP_ARGS(prev, next),

	TP_STRUCT__entry(
		__array(	char,	prev_comm,	TASK_COMM_LEN	)
		__field(	pid_t,	prev_pid			)
		__field(	int,	prev_prio			)
		__field(	long,	prev_state			)
		__array(	char,	next_comm,	TASK_COMM_LEN	)
		__field(	pid_t,	next_pid			)
		__field(	int,	next_prio			)
	),

	TP_fast_assign(
		memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
		__entry->prev_pid	= prev->pid;
		__entry->prev_prio	= prev->prio;
		__entry->prev_state	= __trace_sched_switch_state(prev);
		memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
		__entry->next_pid	= next->pid;
		__entry->next_prio	= next->prio;
	),

	TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_prio=%d",
		__entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
		__entry->prev_state & (TASK_STATE_MAX-1) ?
		  __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
				{ 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
				{ 16, "Z" }, { 32, "X" }, { 64, "x" },
				{ 128, "W" }) : "R",
		__entry->prev_state & TASK_STATE_MAX ? "+" : "",
		__entry->next_comm, __entry->next_pid, __entry->next_prio)
);

   Note how the TP_fast_assign lines are switching __entry->next_comm and __entry->prev_comm, unlike the TP_printk lines.

   In lttng-modules/instrumentation/events/lttng-module/sched.h, we find:

	TP_STRUCT__entry(
		__array_text(	char,	prev_comm,	TASK_COMM_LEN	)
		__field(	pid_t,	prev_tid			)
		__field(	int,	prev_prio			)
		__field(	long,	prev_state			)
		__array_text(	char,	next_comm,	TASK_COMM_LEN	)
		__field(	pid_t,	next_tid			)
		__field(	int,	next_prio			)
	),

   Which is probably why nobody noticed this before, since LTTng traces correctly identify the previous and next processes in the sched_switch event.

   This is an upstream Linux kernel bug or what?

   Another question is: if the kernel tracepoint event definitions appearing in the source are ignored, why are they included at all?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-02-06 20:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-06 20:18 sched_switch event Thibault, Daniel
  -- strict thread matches above, loose matches on Subject: below --
2014-02-06 20:04 Thibault, Daniel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.