Re: [PATCH v1] trace-cmd: introduce --initital-delay for record command

[David Hildenbrand]

On 18.12.2017 16:41, Steven Rostedt wrote:
> On Mon, 18 Dec 2017 12:24:12 +0100
> David Hildenbrand <david@xxxxxxxxxx> wrote:
> 
>> If recording a big number of events to a big buffer, one might want to
>> minimize the trace-cmd activity for a certain period in time.
>> Especially, don't see any trace-cmd activity for some time. If there are
>> a lot of events, the loop might actually never sleep, resulting in the
>> "-s" option never becomming active.
>>
>> E.g. I am using scheduler events to trace thread activity per CPU. Esp.
>> sched:sched_wakeup and sched:sched_stat_runtime. Even when setting the
>> sleep time to something huge like 30 seconds, I can see constant activity
>> from the trace-cmd tasks.
> 
> Thanks for reporting this. Honestly, I believe this is fixing a symptom
> of a real problem. I'd like to investigate why trace-cmd is running
> with a sleep time of 30 seconds. I think that should be fixed.
> 

The problem seems to be that we only sleep if we haven't read something
in the last iteration (!read), hindering us to sleep if there are many
events. Especially on the first run.

If tracing e.g. the scheduler, after each iteration there will already
be new data to pick up in the buffer, resulting in the thread never
going to sleep.

What I need: Start tracing and flush all buffers when exiting. (e.g.
after 30 seconds). Never wakeup in between, so the real trace overhead
in that period of time is purely storing the tracepoints to the buffer
in the kernel. Of course we could implement something like that ("copy
from the buffer only when exiting") or try to see if we can fix the
existing "-s" flag in a way that allows it.

Thanks!

> -- Steve
> 


-- 

Thanks,

David / dhildenb