Re: v2 of comments on Performance Counters for Linux (PCL)

[Ingo Molnar <mingo@elte.hu>]

hi Stephane,

Thanks for the extensive feedback! Your numerous comments cover 
twenty sub-topics, so we've tabulated the summary of Peter's and my 
replies, to give a quick overview:

-------------------------------------------------------------------------
     Topic/question you raised               # Our (current) reply
-------------------------------------------------------------------------
  I/ General API comments
......
  1/ System calls - ioctl                    # agree, willfix
  2/ Grouping                                # agree, questions asked
  3/ Multiplexing and system-wide            # agree, disagree on severity
  4/ Controlling group multiplexing          # agree, disagree on relevance
  5/ Mmaped count                            # disagree
  6/ Group scheduling                        # agree, disagree on severity
  7/ Group validity checking                 # questions answered
  8/ Generalized cache events                # disagree
  9/ Group reading                           # already possible - extend on need
 10/ Event buffer minimal useful size        # questions answered
 11/ Missing definitions for generic events  # reply question asked

 II/ X86 comments
......
  1/ Fixed counters on Intel                 # agree, willfix
  2/ Event knowledge missing                 # disagree

III/ Requests
......
  1/ Sampling period randomization           # support possible, outlined

 IV/ Open questions
......
  1/ Support for model-specific uncore PMU   # support possible, outlined
  2/ Features impacting all counters         # support possible, outlined
  3/ AMD IBS                                 # support possible, outlined
  4/ Intel PEBS                              # support possible, outlined
  5/ Intel Last Branch Record (LBR)          # support possible, outlined
-------------------------------------------------------------------------

( We'll send the individual replies in separate mails to keep mail
  size manageable. )

At the outset, it appears that there's two major themes to your 
questions (with a few other topics as well which i dont mention 
here):

 - Expressing/handling constraints with certain PMU features
 - Supporting various non-counter PMU features

In general we'd like to observe that our primary design goal is to 
offer a coherent, comprehensive and still simple to use performance 
measurement and profiling framework for Linux. We also provide an 
integrated tool in tools/perf/ to give a complete solution.

Many of the perfcounters features use no PMU at all, and in fact 
it's entirely possible to use most 'perf' features and get a 
meaningful analysis/profile of the system without any PMU.

In other words, we consider the PMU to be the means as to enhance 
perfcounters, not the end goal. A PMU will make a good difference to 
quality and precision, but we do not let the sanity of our 
interfaces be dictated by PMU feature quirkiness.

We cherry-pick the PMU features that look most useful, and expose 
them via rich performance measurement abstractions. It does not mean 
that we strive for immediately exposing _all_ PMU features and drown 
users in lots of conflicting hw facilities (different on each 
platform) as quickly as possible.

Having said that, we do think that pretty much any sane PMU feature
_can_ be supported via perfcounters (and most insane ones as well)
and that the limit is 'do we want to', not 'can we'.

Even heavily constrained PMUs can be supported: PowerPC, which is a
CPU family with heavily constrained PMU variants is widely supported
by perfcounters here and today.

	Ingo, Peter