I don't have any comments about the suggested implementation. However, what would be the downsides of integrating CPC collection into the kernel - so that CPC registers are a constant part of a LWP's state. So when a LWP starts running on a particular CPU core, the CPC counters are set to zero, and when it comes off it, the CPC registers are read and *added* to the LWP state - and possibly the process the LWP is part of, and separately the individual CPU core.
I'm far from an expert on this sort of thing (and my terminology usage might be wrong), so I may be making myself look like an idiot here. Not that I'm expecting such a change to be added casually either. However, I think it does open up some interesting possibilities as well - if each thread's time slice is based on the number of CPU cycles instead of wall-clock time, then it becomes easier to fairly schedule threads when you have multiple hardware threads per CPU core (like on Niagara/T1 and the Pentium IV with Hyperthreading). It would also make it easier to have a system with different CPU clock rates I think - since CPU cycles is independant of clock rate too, pretty much (depending exactly on how the CPU measures it). PS A big thank-you to however added extensive support for CPC in Solaris x86. I like using CPC for in-depth benchmark analysis and this helps me greately! PPS Any chance of a an approved (or at least community shared) Java wrapper to CPC? I wrote a rather basic one myself, though it's rather flakey. This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
