lkml.org 
[lkml]   [2008]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Performance Counters for Linux, v2

* Paul Mackerras <paulus@samba.org> wrote:

> > Things like: "kerneltop would not be as accurate with: ..., to the
> > level of adding 5% of extra noise.". Would that work for you?
>
> OK, here's an example. I have an application whose execution has
> several different phases, and I want to measure the L1 Icache hit rate
> and the L1 Dcache hit rate as a function of time and make a graph. So
> I need counters for L1 Icache accesses, L1 Icache misses, L1 Dcache
> accesses, and L1 Dcache misses. I want to sample at 1ms intervals. The
> CPU I'm running on has two counters.
>
> With your current proposal, I don't see any way to make sure that the
> counter scheduler counts L1 Dcache accesses and L1 Dcache misses at the
> same time, then schedules L1 Icache accesses and L1 Icache misses. I
> could end up with L1 Dcache accesses and L1 Icache accesses, then L1
> Dcache misses and L1 Icache misses - and get a nonsensical situation
> like the misses being greater than the accesses.

yes, agreed, this is a valid special case of simple counter readout -
we'll add support to couple counters like that.

Note that this issue does not impact use of multiple counters in
profilers. (i.e. anything that is not a pure readout of the counter,
along linear time, as your example above suggests).

Once we start sampling the context, grouping of counters becomes
irrelevant (and a hindrance) and static frequency sampling becomes an
inferior method of sampling.

( The highest quality statistical approach is the kind of multi-counter
sampling model you can see implemented in KernelTop for example, where
the counters are independently sampled. Can go on in great detail about
this if you are interested - this is the far more interesting usecase
in practice. )

Ingo


\
 
 \ /
  Last update: 2008-12-09 14:03    [W:0.080 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site