[lkml]   [2009]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: v2 of comments on Performance Counters for Linux (PCL)

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

- 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

 \ /
  Last update: 2009-06-22 13:51    [W:0.403 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site