Phil, On Mon, Mar 26, 2007 at 10:28:50AM +0200, Philip Mucci wrote: > > I've been thinking about the per-counter stuff. Most of the counters > have features that occur in groups. Consider SiCortex 2 CPU counters > and 256 off-core counters, or SGI's CrayLink counters... These groups > have common features that we should be able to exploit for > performance. For instance all through the code I have stuff like (if > (test_bit(counter,&used_pmcs)), due to the length of the bit vector, > this can add 5-10 instructions for what is a very sparse vector,
There is no loop in test_bit(), it is just about shifting and masking. > which usually has a VERY similar pattern. Handling groups would allow > us efficiently to define counters with properties like overflow bits > in different places, different lengths, different characteristics/ > flags. Certainly the current implementation is most flexible, but > there is a price for complete flexibility. > If I follow you, you are suggesting that we tag each PMD or PMC with a group id. Each group would have common properties, e.g., width, enable bit position. Then we would do lookups in the group "descriptor" to find the info we need. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
