---------------------------------------------------------------------- Date: Tue, 25 Nov 2014 14:04:04 -0500 From: David Goulet <[email protected]>
> 1) Having a way to use counters in the trace. > > So basically, lots of our measurements are based on timing things which > tracepoints are really useful for that but we also gather stuff like "How > many elements seen of an object in the past hour?". It's doable with > tracepoint but when the number goes up to millions quickly, it does not > really scale to have a million tp for one single counter. > > The rough idea is this: > > [...] > tracepoint_counter_inc(mycomponent, mycounter, n); > [...] > > where "n" is the amount to increment the counter designated by > mycomponent:mycounter. > > When the buffers are flushed or/and the tracing stop, this counter could > simply be updated in the trace and, for instance, babeltrace could print them > at the beginning of the output. The semantics of these "counters" has to be thought through carefully. A means of setting the counter's initial value should be available (i.e. tracepoint_counter_set(mycomponent, mycounter, n);), and maybe also a means of "flushing" the counter (i.e. tracepoint_counter_flush(mycomponent, mycounter, myevent);, where mycomponent:myevent has a single-argument signature of the same type as the counter) ---"flushing" in this case means forcing a tracepoint event to be issued with the current counter's value as its payload. Should counters be assigned to channels and enabled/disabled just like events? If a counter is assigned to multiple channels within a trace, the same value should transpire in each channel. On the other hand, if the counter is assigned in several separate traces, the values should be independent of each other. When a counter/channel/trace is disabled, should the counter ignore any tracepoint_counter_set/_inc/_flush commands? Finally, what happens when an application dynamically unloads the provider handling the counter and later loads it back in? Presumably the counter value resets to its default zero (here's another idea: maybe the counter's default creation value can be non-zero, and is set in the tracepoint template by the tracepoint-counter creation macros). Maybe counters can be handled in truly event-like fashion: when a counter is created, set, or destroyed, an implicit event occurs (described in the tracepoint template by the tracepoint-counter creation macros). Simply incrementing the counter does not trigger an event. The application API is then decoupled from the LTTng trace, and the lttng client does not need to be changed at all, being unaware of counters. Here's a strawman for discussion: In the instrumented apps, simply include tp.h as usual, and use any or all of the counter API methods: tracepoint_counter_set(component, counter, value), tracepoint_counter_inc(component, counter, value), tracepoint_counter_flush(component, counter). In the tracepoint header, the counter is defined like this: TRACEPOINT_COUNTER (<provider name>, <counter name>, TPC_INITIAL_VALUE(<type>, <value>), TPC_FIELD( ctf_<scalar>(<type>, <field name>, <counter name>) ) ) Whenever the counter is created by the instrumented app (by any one of the three methods), a <provider name>:<counter name>_created event occurs. Whenever the counter is destroyed (the instrumented app terminates or unloads the provider), a <provider name>:<counter name>_destroyed event occurs. Whenever the counter is flushed, a <provider name>:<counter name>_report event occurs. All events report the counter's value. The counter's events cannot be called directly from the instrumented app. On the lttng client side, one assigns the counter's three events to channels and enables/disables them as usual. 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) RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre 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/> _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
