Re: [RFC PATCH -tip ] tracing: make a snapshot feature available from userspace.

[Rob Landley <rob@landley.net>]

On 07/04/2012 05:47 AM, Hiraku Toyooka wrote:
> Hello, Steven,
> 
> I've sent below RFC patch, but still have no responses. This patch can
> be applied to current tip tree.
> 
> If you have time, could you give any comment about this patch?

My familiarity with ftrace is "I saw a presentation on it at a
conference a couple years ago", so I'm not the guy to comment on the
advisability of the patch itself.

As for the documentation: seems reasonable, could use some english
polishing.

>> +Snapshot
>> +--------
>> +If CONFIG_TRACER_MAX_TRACE is set, the (generic) snapshot
>> +feature is available in all tracers except for the special
>> +tracers which use a snapshot inside themselves(such as "irqsoff"
>> +or "wakeup").

This is confusing, I'm guessing irqsoff and wakeup already have
persistent buffers without CONFIG_TRACER_MAX_TRACE? (So there is a
generic snapshot feature, but some tracers have their own internal
buffer and don't use the generic one?)

Is the fact that some tracers don't use this feature an important part
of the description of the feature? Is making them use common code a todo
item, or just a comment?

How about:

CONFIG_TRACER_MAX_TRACE makes a generic snapshot feature available to
all tracers. (Some tracers, such as "irqsoff" or "wakeup", use their own
internal snapshot implementation.)

>> +This enables to preserve trace buffer at a particular point in
>> +time without stopping tracing. When a snapshot is taken, ftrace
>> +swaps the current buffer with a spare buffer which is prepared
>> +in advance. This means that the tracing itself continues on the
>> +spare buffer.

Snapshots preserve a trace buffer at a particular point in time without
stopping tracing; ftrace swaps the current buffer with a spare buffer,
and tracking continues in the spare buffer.

>> +Following debugfs files in "tracing" directory are related with
>> +this feature.

The following debugfs files in "tracing" are related to this feature:

>> +  snapshot_enabled:
>> +
>> +    This is used to set or display whether the snapshot is
>> +    enabled. Echo 1 into this file to prepare a spare buffer
>> +    or 0 to shrink it. So, the memory for the spare buffer
>> +    will be consumed only when this knob is set.

Write 1 to this file to allocate a snapshot buffer, 0 to free it.

(Query: do you have to free the buffer after taking a snapshot below?)

>> +  snapshot_pipe:
>> +
>> +    This is used to take a snapshot and to read the output
>> +    of the snapshot. Echo 1 into this file to take a
>> +    snapshot. Reads from this file is the same as the
>> +    "trace_pipe" file (described above "The File System"
>> +    section), so that both reads from the snapshot and
>> +    tracing are executable in parallel.

Echo 1 into this file to take a snapshot, then read the snapshot from
the file in the same format as "trace_pipe" (described above in the
section "The File System").

Design questions left for the reader: why are allocating a snapshot
buffer and taking a snapshot separate actions? Why is there only _one_
snapshot buffer?

>> +Here is an example of using the snapshot feature.
>> +
>> + # echo nop > current_tracer
>> + # echo 1 > snapshot_enabled
>> + # echo 1 > events/sched/enable
>> + [...]
>> + # echo 1 > snapshot_pipe

Is the order significant here? Do you have to set up a snapshot buffer
before you start tracing? When you switch buffers, does the new buffer
start empty, or with a copy of the previous trace data?

I'm guessing the reason buffer switching was described above is to
explain that taking a snapshot blanks the current trace history since
you switch to an empty buffer?

>> + # cat snapshot_pipe
>> +            bash-3352  [001] dN.. 18440.883932: sched_wakeup:
>> comm=migration/6 pid=28 prio=0 success=1 target_cpu=006
>> +            bash-3352  [001] dN.. 18440.883933: sched_wakeup:
>> comm=migration/7 pid=32 prio=0 success=1 target_cpu=007
>> +            bash-3352  [001] d... 18440.883935: sched_switch:
>> prev_comm=bash prev_pid=3352 prev_prio=120 prev_state=R ==>
>> next_comm=migration/1 next_pid=8 next_prio=0
>> +[...]

How big is one of these buffers, anyway?  I take it the reason opening
snapshot_pipe doesn't just allocate a snapshot buffer and take the
snapshot then (to persist for the duration of the filehandle) is to
avoid pinning too much kernel memory?

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.