> On Nov 9, 2015, at 1:18 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Mon, 9 Nov 2015 17:04:05 +0000
> "Kornievskaia, Olga" <Olga.Kornievskaia@xxxxxxxxxx> wrote:
>
>> Hi,
>>
>> Can somebody tell me if logging of tracepoints is lossy (meaning that due to too much output it won’t be present while reading from /sys/kernel/debug/tracing/trace_pipe)?
>>
>
> Because tracepoint writes do not stop the flow of execution (and try
> very hard not to even disturb the flow), and there is an finite
> internal buffer size to store the ring buffer data, then we have no
> choice but to have tracepoints be lossy if the reader can't keep up.
>
> But if you do lose events, the trace_pipe file should let you know.
> You'll see a message like:
>
> CPU:1 [LOST 6200 EVENTS]
>
> At that point, 6200 events were lost due to the reader not being able
> to catch up.
Hi Steve,
Thank you very much for the explanation. I didn’t know about the “lost events” ability.
Is this the same mailing list that offers help with using “perf” (and tracepoints)? If this is not, can somebody suggest where to ask?
I’d like to know if perf can do “timing-of-operation” type of measurement? By that I mean, say there are two tracepoints “foobar_enter” and “foobar_exit”. Each tracepoint logs a timestamp. I’d like to be able to say that on average it takes that many time-units between “enter” and “exit” tracepoints. I haven’t been able to find something like that with “perf”.
Thank you.��.n��������+%������w��{.n�����{���q��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
|