Hi Phil,
> Looks good!
Thanks!
> I guess the thing which most people are going to pick up on is the
> sampling granularity. I just wonder whether you should always have to
> specify this, or whether you should pick up some sensible (safe)
> default; I guess there are pros and cons, the downside being that the
> default might change underneath you.
I prefer a user to always have to specify an event frequency without
having a default. I'm a big believer (in the tracing world anyway) of
people getting what they ask for and having to ask for it to get it!
I just like a consumer having to be explicit with the parameters they
are requesting and I shy away from hidden defaults as I think it can
lead to confusion in what is quite a confusing area anyway.
Do you think it really hurts to *have* to specify an event frequency?
> Also your third example; maybe I'm nitpicking but does this really do
> what it says:
No, you are correct. It's possibly misleading wording. See below.
> 3. L2 cache misses, by function, generated by any running executables
> called 'brendan' on an AMD platform.
>
> cpc:::BU_fill_req_missed_L2-all-0x7-10000
> /execname == "brendan"/
> {
> @[ufunc(arg1)] = count();
> }
>
> The filter's applied in the D, after the probe has fired, so surely the
> probe firing indicates there have been 10000 global L2 cache misses, and
> it just so happens this time the probe has fired whilst "brendan" is on
> CPU? It doesn't necessarily mean there have been 10000 firings whilst
> "brendan" was on CPU.
Absolutely correct. We are just sampling and the thread belonging to
process "brendan" just happened to generate the 10000th L2 cache miss.
How many of the previous 9999 overflow events of this type were caused
by "brendan" is anyones guess.
The wording isn't incorrect but just misleading. The overflow is generated
by the executable "brendan" - it may not have generated all of the events
that lead to that overflow though. The sampling technique used here is
fundamental to the operation of the 'cpc' provider and has to be borne
in mind when it's used. As with any sampling technique, the more samples
the better. I probably need to change the wording on that example or,
at least, be more verbose.
> I could have misunderstood, it could be nitpicking, and I know it's a
> subtlety, but AIUI this is different to how cputrack (say) would work.
It's a completely valid point and, yes, it's different to how cputrack
works.
Thanks.
Jon.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
