linux-kernel - Re: [PATCH] clk: debugfs: Support frequency stats accounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20150324222304.GA25574@codeaurora.org>
Date:	Tue, 24 Mar 2015 15:23:04 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Badhri Jagan Sridharan <badhri@...gle.com>
Cc:	Mike Turquette <mturquette@...aro.org>,
	linux-kernel@...r.kernel.org
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/