Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers

From: Frédéric Weisbecker
Date: Thu Nov 13 2008 - 18:48:26 EST


2008/11/13 Ingo Molnar <mingo@xxxxxxx>:
>
> * Frédéric Weisbecker <fweisbec@xxxxxxxxx> wrote:
>
>> That's right, it's much more better for the eyes. I didn't want to
>> output such a disposition from the kernel because I thought that
>> would result in too much strings work from kernel-space. But
>> actually, as you suggest,
>> if I append a depth field in the trace that could be easy and not
>> so costly. I just have a last thought about post-processing parsing.
>> Would it make it harder for that?
>
> humans are the priority targets for tracer output - tools are a
> distant second target. Whatever is nice for humans is also usually
> easy to process via tools. A tool can set an option flag just fine.
>
> To help tooling, add a trace_options flag for more predictable/faster
> output. We already have the binary output format for example.
>
>> Why not a flag that could be set through iter_ctrl (which has
>> changed its name yesterday) and that could let the user to choose
>> its output? That's where I renew my proposition to make the tracers
>> able to propose custom flags for this file with a new callback such
>> as tracer_ctrl, or tracer_opt.
>
> yes, your proposal is fine.
>
>> But as you say, why not set it through a flag.
>
> yes - and make the defaults for flags favor human visual parsing.
>
>> > Easiest would be to add a depth field to the trace entry as well, to
>> > make sure we get the right depth in the end, even if we somehow mix up
>> > the trace entries.
>>
>> Yeah, that's good! I will just have to output "\t" * depth to have
>> the correct indentation.
>
> i'd suggest spaces for the function indentation, because we'll also
> have quite deep call stacks in practice.
>
> and i'd suggest you flip around the cost field to something like:
>
> [...]
> getnstimeofday() {
> set_normalized_timespec() {
> clocksource_read() {
> ( 1547 ns) acpi_pm_read()
> ( 1951 ns) } clocksource_read()
> ( 2200 ns) } set_normalized_timespec()
> ( 2354 ns) } getnstimeofday()
>
> that makes it fixed-width up to the inevitable variable-length field,
> the function name.
>
> Ingo
>

Ok, I will add all of these in my workqueue. Thanks :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/