[lkml]   [2008]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Performance Counters for Linux, v2
Ingo Molnar writes:

> yeah, but it's still the fundamentally wrong thing to do.
> Being able to extract high-quality performance information from the
> system is the cornerstone of our design, and chosing the right sampling
> model permeates the whole issue of single-counter versus group-readout.

Thanks for taking the time to write all this down, and I will respond
in detail once I have thought about it some more.

The thing that stands out to me immediately, though, is that you are
concentrating entirely on _sampling_ as opposed to _counting_.
Perhaps this is the main reason we have been disagreeing.

Now of course sampling is interesting, but counting is also
interesting, whether over the whole execution of a program or over
short intervals during the execution of a program (based either on
time, or on the execution of certain functions).

It seems to me that a well-designed performance monitor infrastructure
should support both counting and sampling. And for counting, getting
high-quality data requires synchronized counters (ones that all start
counting and stop counting at the same times).

Looking back at the discussion so far, I can see that your arguments
make more sense if you are only wanting to do sampling. And I have
been arguing for what I believe we need to do counting properly (I
have focused more on counting because we already have infrastructure
for sampling, namely oprofile).

So, can we agree to discuss both sampling and counting, and design an
infrastructure that's good for both?


 \ /
  Last update: 2008-12-09 23:21    [W:0.127 / U:5.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site