Messages in this thread | | | Date | Tue, 24 Mar 2015 15:23:04 -0700 | From | Stephen Boyd <> | Subject | Re: [PATCH] clk: debugfs: Support frequency stats accounting |
| |
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
| |