Hi Chad, >> >> Only one of cpustat and DTrace may use the counter hardware at any one time. >> Ownership of the counters is given on a first-come, first-served basis. > > I'm curious, how does DTrace interact with DTrace in this situation? > Specifically, if two DTrace invocations (either separate D scripts or > even two clauses in the same D script) specify the same hardware > counter in a probe, will they both see (effectively) the same data, or > will the first invocation be the only one to see useful data?
The key thing to remember here is that a probename encodes everything needed to program the performance counter hardware up. Therefore, if you have two probes with the same event name but a different mode or event frequency then it is two different hardware configurations. If the hardware you're on can't tell which counter overflowed in the face of multiple active counters (like AMD or UltraSPARC) then I only allow a single enabling. For example, a script that attempts to enable 'cpc:::IC_miss-user-10000' and 'cpc:::IC_miss-kernel-10000' on an AMD box will succeed for the first enabling but fail the second and the consumer will exit: # dtrace -n 'cpc:::IC_miss-user-10000' -n 'cpc:::IC_miss-kernel-10000' dtrace: description 'cpc:::IC_miss-user-10000' matched 1 probe dtrace: failed to enable 'cpc:::IC_miss-kernel-10000': Failed to enable probe # If, however, two separate consumers attempted to enable different IC_miss incantations then the first one to execute would succeed and the second would be denied. However, if you were on a Niagara T2 based system then you could enable two cpc probes with different hardware configurations (the T2 only has two counters but it can tell you which one overflowed). I tried to communicate this in section "B3 - Probe Availability". Give it another read and let me know if it needs improving at all (or if the above wasn't an correct understanding of your question!). Jon. _______________________________________________ dtrace-discuss mailing list [email protected]
