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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Dec 2017 17:23:24 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Trace Devel <linux-trace-devel@...r.kernel.org>
Subject: Re: [PATCH v1] trace-cmd: introduce --initital-delay for record
 command

On 18.12.2017 16:41, Steven Rostedt wrote:
> On Mon, 18 Dec 2017 12:24:12 +0100
> David Hildenbrand <david@...hat.com> 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