From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752605AbbCXWXK (ORCPT ); Tue, 24 Mar 2015 18:23:10 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:52896 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752462AbbCXWXG (ORCPT ); Tue, 24 Mar 2015 18:23:06 -0400 Date: Tue, 24 Mar 2015 15:23:04 -0700 From: Stephen Boyd To: Badhri Jagan Sridharan Cc: Mike Turquette , linux-kernel@vger.kernel.org Subject: Re: [PATCH] clk: debugfs: Support frequency stats accounting Message-ID: <20150324222304.GA25574@codeaurora.org> References: <1426891459-12589-1-git-send-email-Badhri@google.com> <20150321072607.GA10998@codeaurora.org> <55108428.2010907@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55108428.2010907@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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