On Wed, Dec 3, 2008 at 2:43 AM, Dan Terpstra <[EMAIL PROTECTED]> wrote: >> Counting requires interrupt to virtualize the counters to 64-bit. They are >> 48 >> bits if I recall. >> > Yes, they're 48-bit, but why do you need interrupt to virtualize? With a > multi-tasking OS, you just do it at context switch. I still think it will be > important to count in both domains at once...
There is no context switch in system-wide mode. You program the counters and you let them run. Also the perfmon API export all counters as 64-bit wide. This is very useful for tools, especially when sampling. > - d > >> -----Original Message----- >> From: stephane eranian [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, December 02, 2008 12:54 PM >> To: Dan Terpstra >> Cc: perfmon2-devel >> Subject: Re: [perfmon2] Intel Core i7 specs available. >> >> Dan, >> >> On Tue, Dec 2, 2008 at 5:10 PM, Dan Terpstra <[EMAIL PROTECTED]> >> wrote: >> > >> > Are you referring to the Uncore Address/Opcode Match stuff (18.17.2.3)? >> I >> > saw that, but wasn't quite sure how to use it. I didn't see anything in >> the >> > PEBS stuff that looked like Data EAR. Or is this part of the Load >> Latency >> > stuff that's described in (18.17.1.2)? Looks like part of the latency >> stuff >> > includes a Data Address. >> >> >> >> No, I was indeed referring to offcore (which is different from uncore). >> Yes, that's the load latency PEBS I was talking about. I does give >> you the cache miss information similar to Itanium D-EAR, you get >> instr and data addresses, latency, source of the data in addition >> to the machine state which is quite nice. >> >> >> You missed one thing, however, the offcore_response feature. That one >> >> is tricky because >> >> it uses a register that is shared per core (if I recall). >> >> Perfmon handles offcore_response similaryl to what is going on with >> >> AMD northbridge event. >> >> It enforces some form of mutual exclusion. >> >> >> > Yes, the off-core response stuff can be coded into any of the generic >> > registers on any core, but it shares a single common configuration >> register. >> > Exclusion logic for this guy could be fun. It looks like this takes the >> > place of the SELF/ANY modifiers used in earlier Core architectures for >> > events that probed shared cache? >> >> >> Well, yes this is tricky. The current code does the following: >> - only one system-wide session per physical core (each physical >> core has 2 threads) >> - only one per-thread session across the entire system (otherwise >> you have problems >> in case of migration). >> >> > Who owns the system-wide session? First-come first-served? Can it be any >> > thread or must it be a specific core? And if you restrict access to >> counting >> > (calipers), couldn't you do per-thread access without worrying about >> > overflow? >> >> >> For uncore, the first system-wide session which asks for it, gets it. >> It can be coming from any core/threads on the socket. >> >> >> > I'm not sure that uncore counters should be restricted to system-wide >> >> > counting only; I think it could be quite useful, as Phil described >> for >> >> > SiCortex, to measure "what's happening to this shared resource while >> I'm >> >> > active". That's not unlike Component PAPI measuring network activity >> on >> >> a >> >> >> Counting requires interrupt to virtualize the counters to 64-bit. They are >> 48 >> bits if I recall. >> >> >> >> No, this is not yet supported. I think on x86, this is not that far >> off. >> >> >> > Could you do first-person monitoring in a parent thread and spawn a >> daughter >> > thread to measure uncore stuff? Or maybe even fork a new process? >> >> >> No, this is currently restricted to system-wide sessions only. > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
