Hi Sébastien, [...]
>> I sometimes miss kernel events. Is there a point in using different >> channels for kernel and user space traces (besides giving them distinct >> sizes)? I suspect they're already effectively different even if they have >> the same name. Also, I have increased the subbuffer size a lot, but did not >> change the number of subbuffers. Would that help preventing missed events? Indeed, kernel and user-space traces are already in different channels. Enabling different channels for the same domain (kernel or ust) is especially useful when you have different level of interest for different events. For example, if you absolutely want all the sched_switch events, you could have a dedicated channel for these events, with the appropriate size and number of subbuffers, and then enable other channels for the other events you are interested in, that way you limit the risk of loosing your most important events. Regarding your question about the state system, I don't know how TMF handles that, but the contexts are a good way to ensure a consistent state without any state system. For example, you can attach a pid or procname context to all the events in a specific channel. Every time an event is recorded in this channel, the tracer will fetch the current procname/pid information. That way you are sure to have a consistent state even if you don't have all the scheduling and statedump events. The drawback, is that it increases slightly the operations done by the tracer on the fast path and the trace is bigger. Hope this helps, Julien _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
