Re: [PATCH] clk: debugfs: Support frequency stats accounting

[Stephen Boyd <sboyd@codeaurora.org>]

On 03/23, Badhri Jagan Sridharan wrote:
> >Some initial  questions:
> >
> > 1. Have you seen the pending tracepoint patches to add
> > tracepoints to the framework[1]?
> >
> > 2. Have you considered using tracepoints and the ability to
> > register callbacks on tracepoints and/or register_stat_tracer()
> > to implement the functionality in this patch?
> >
> > 3. If we had tracepoints would it be possible to do
> > everything that's done here entirely in userspace with some
> > userspace tool that monitors clock trace events?
> 
> Thanks Stephen... Following is one major factor that blocks
> me from using trace points... Trace points are unaware of the history of
> events that already happened before the start of monitoring of events.
> Consider that I start monitoring for clock_events at time instant X,
> we might
> not get to know the state of the clocks that were enabled and left running
> before the time instant X.

It seems easy enough to enable the tracepoints that matter from
the kernel command line so that we have all the history. If we
have a stat tracer we could do something similar by enabling the
tracer on boot and not require any userspace post processing on
the trace output.

> 
> clk_summary table already has a very intuitive/impressive layout of
> conveying the
> the states and relationship between different clocks in the system.
> That's why
> I thought adding the frequency_stats info here might make it more
> comprehensive.
> Are there any potential risks of doing so ?
> 

The only risk I see is bloating the kernel and putting debug
hooks in places where we already have tracepoints. Less code is
easier to maintain.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project