Re: [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Oct 4, 2010 at 6:10 PM, Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:
> Hi -
>
>> Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING  option in order
>> to provide backward compatibility with the user space tracing tools.
>
> This is clever:
>
>> +/* Map new events trace points calls to old ones */
>> +#define trace_processor_idle(state, cpu_id)                          \
>> +     do {                                                            \
>> +             if (state != 0)                                         \
>> +                     trace_power_start(POWER_CSTATE, state, cpu_id); \
>> +             else                                                    \
>> +                     trace_power_end(cpu_id);                        \
>> +     } while (0)
>
> but with this code, are the new tracepoints firing at all?  In other
> words, does this backward-compatibility config option effectively
> disable the newer ones?  If so, this is probably avoidable.
Yes the events are fired. In fact with the CONFIG option defined the
trace_processor_* trace points are not defined, only the macro remaps
them (at compile time) to the old ones.

> Instead of redirecting the new tracepoint calls to these macros, an
> alternative may intercept (un)registration for the old tracepoint
> names, and map them to (un)registration of the real tracepoints.  See
> how syscall tracepoints map to a special (un)registration callback in
> include/trace/events/syscalls.h (syscall_*regfunc).  Instead of
> setting a TIF flag, the new functions can call
> register_processor_idle() et al., and their respective callbacks can
> call the backward-compatibility tracepoints.
>
> The starting point would be to recast the power_start, power_end,
> power_frequency tracepoints via TRACE_EVENT_FN() instead of
> TRACE_EVENT().
That could be done but it is not easy to do. In fact the power.h is
included and parsed multiple times in order to generate the trace
points prototype function _and_ the trace generation code. Please
check 'include/trace/ftrace.h' which is really smart but rather
complicated.

I am aiming at simple to read and maintainable code. Furthermore the
code is going to be removed soon or later.

Thanks for the suggestion!

>
> - FChE
>
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux