On Mon, Nov 22, 2010 at 4:23 AM, Florian Mickler <florian@mickler.org> wrote:
quoted text
> On Mon, 22 Nov 2010 11:43:59 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>> On Mon, 2010-11-22 at 06:51 +0100, Florian Mickler wrote:
>> > On Sat, 20 Nov 2010 11:48:24 +0100
>> > Peter Zijlstra <peterz@infradead.org> wrote:
>> >
>> > > On Fri, 2010-11-19 at 18:08 -0800, John Stultz wrote:
>> > > > From: Mike Chan <mike@android.com>
>> > > >
>> > > > Introduce new platform callback hooks for cpuacct for tracking CPU frequencies
>> > > >
>> > > > Not all platforms / architectures have a set CPU_FREQ_TABLE defined
>> > > > for CPU transition speeds. In order to track time spent in at various
>> > > > CPU frequencies, we enable platform callbacks from cpuacct for this accounting.
>> > > >
>> > > > Architectures that support overclock boosting, or don't have pre-defined
>> > > > frequency tables can implement their own bucketing system that makes sense
>> > > > given their cpufreq scaling abilities.
>> > > >
>> > > > New file:
>> > > > cpuacct.cpufreq reports the CPU time (in nanoseconds) spent at each CPU
>> > > > frequency.
>> > >
>> > > I utterly detest all such accounting crap.. it adds ABI constraints it
>> > > add runtime overhead. etc..
>> > >
>> > > Can't you get the same information by using the various perf bits? If
>> > > you trace the cpufreq changes you can compute the time spend in each
>> > > power state, if you additionally trace the sched_switch you can compute
>> > > it for each task.
>> > >
>> > >
>> > This is probably used for "on-site" debugging of production systems.
>>
>> Dude, its from the _android_ tree... its cpufreq crud.. it must be some
>> crack induced power management scheme.
>>
>>
>
> :)
>
> what I wanted to get at, was that they probably need these stats
> aggregated somewhere neat and tidy and can not compute them on the fly
> recording massive amounts of data...
>
> I wonder why they didn't put this in the
> idle-driver.  I don't know.
>

This is useful for tracking cpu power per c-group. We split each
android application into its own c-group and track what cpu speeds and
how long the cpu spent for each one. Peter we've actually discussed
this before:
http://lkml.org/lkml/2010/5/6/301

These patches were discussed with Paul Menage and Balbir Singh back in
April, as well as on lmkl and the cpufreq mailing lists. These may or
may not be useful for mainline, I assume anyone wanting to track power
specific for c-groups would be interested. I'm open for different
implementations that can help achieve cpu power tracking per-cgroup if
this particular implementation is controversial, or if you just want
to help make Android's kernel better.

-- Mike

quoted text
> Regards,
> Flo
>
>
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/