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? Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
