Hey Chris,
Chris Rijk wrote:
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).
A group of us at Sun have been thinking and talking about this for years. It is
certainly an enticing idea - the more data the kernel can consider when making
critical choices, the more efficient it can be in parceling out resources.
Lately, a team here at Sun has been working on doing exactly that. I'm not sure
how much I can say about it publicly, but if more disclosure is warranted, I
will follow-up here.
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!
That was me - thanks for the feedback! It's great to hear things like this.
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.
What type of wrapper are you talking about? It can be hard to correlate system
activity to JVM behavior down to particular java code. Or are you talking about
measuring performance of the JVM, in general? We've been thinking about a CPC
provider for dtrace for a while now (and rumor has it that someone is actually
prototyping this, right now). Such a beast would, when used in conjunction with
the java dtrace provider, allow detailed, CPC data-driven analysis of java apps.
- Russ
-----------------------------------------------------
Russ Blaine | Solaris Kernel | [EMAIL PROTECTED]
_______________________________________________
perf-discuss mailing list
[email protected]
