Add (possibly symbolic) event whenever blocking occurs due to excessive events
LTTNG_UST_BLOCKING_RETRY_TIMEOUT, it is desirable to know when blocking occured. This way an analyst will stay informed of periods in the trace where precision of events had to be traded for completeness.
This has been discussed informally in the IRC channel:
[09:08:06] rnsanchez such points could be of interest in my analysis :+) [09:59:35] Compudj rnsanchez: no [10:01:19] Compudj rnsanchez: but looking at event clusters in your trace will help [10:01:36] rnsanchez Compudj: what about throwing a single/occasional event for a corresponding tid/pid that was ungraced due to excessive events? [10:01:56] Compudj rnsanchez: with multi-session support, that would not be that easy [10:02:04] Compudj we'd have to know which buffers are affected [10:02:22] Compudj so we don't generate noise into other sessions [10:02:36] rnsanchez I see [10:02:37] rnsanchez sounds fair [10:03:35] Compudj rnsanchez: if we add such info eventually, I'd be tempted to add a packet header field for that [10:03:47] Compudj which could counts the "blocking" a buffer has had so far [10:04:11] Compudj so we don't rely on events to relay information that is transport-level [10:04:35] Compudj that would be doable (you may want to add a feature request on bugs.lttng.org) [10:05:26] rnsanchez well that kind of info could be "rendered" into tools such as Trace Compass. it would be informative enough for the analyst to take a convolute period with a grain/spoon of salt [10:05:57] rnsanchez Compudj: I can do that, sure [10:06:04] Compudj rnsanchez: yes, and having those counters in the packet header would nicely match the spots where the situation occurs [10:06:15] Compudj blocking always happen at sub-buffer (packet) boundary [10:09:06] rnsanchez so it would act (briefly) as a relaxed clock? i.e., "between events En and En+1, we blocked, take that into account" [10:09:24] rnsanchez (relaxed as in not actually probing clocks for a timestamp) [10:10:43] Compudj yes, if we detect that the blocking counter increased between two consecutive packets, we can put a marker between timestamp end of the first packet and timestamp begin of the second packet saying that the source has been blocked during that time [10:11:11] rnsanchez perfect [10:12:19] Compudj you may want to paste this conversation into the bug tracker feature request, it will make it easier to remember the details when/if we get to implement it [10:13:26] rnsanchez doing that as we speak
No data to display