[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-dtrace-discuss
Subject:    Re: [dtrace-discuss] CPC provider - input welcome
From:       Jon Haslam <Jonathan.Haslam () Sun ! COM>
Date:       2008-07-23 18:34:46
Message-ID: 488779C6.9040307 () sun ! com
[Download RAW message or body]

Hi Peter,

> 1) Section 2 talks about args[0] and args[1], yet the examples use 
> arg0 and arg1.   This may be just cosmetic, but it might be worth 
> being consistent.   Also, should the description be specific about 
> what data type is given for args[0] and args[1], or is that implicit 
> by saying they are program counter values?

Oops. I shouldn't refer to the typed argument array here as the
arguments are not presented through it. That should be arg0
and arg1. Thanks.

> 2)  Example 3 (and hence 4) sounds unclear to me given the discussion 
> last week.   It still leaves open the interpretation that all the L2 
> cache misses that are being counted are all caused by the executable 
> "brendan".   Given the discussion last week, it would be more clear to 
> describe it being a sampling of what the brendan executable was doing 
> each time the L2 cache miss counter hit the target.  It might be 
> useful to add a second clause to the example 3 script to count events 
> that happened when some other executable was executing.   This makes 
> the "brendan" counts a more effective drill-down into the total set of 
> L2 cache miss events.  Did I understand last week's discussion correctly?
> cpc:::BU_fill_req_missed_L2-all-0x7-10000
> /execname == "brendan"/
> {
> 	@[ufunc(arg1)] = count();
> cpc:::BU_fill_req_missed_L2-all-0x7-10000
> /execname != "brendan"/
> {
> 	@["OtherExecutable"] = count();
> }
> }

I didn't alter these examples because I added a paragraph in section
"B1 - Probe Format" which contains an example to cover this off.
I explicitly mention the fact that the events may not be all generated
by the executable.  Also bear in mind that this document is for
architecture review and it's a different thing to the user guide where
I'll be a lot more verbose.

> 3) It might also be helpful to have an example that keeps a running 
> total of some performance counter, and then periodically samples that 
> counter during some other event of interest.  I.e. we could use the 
> dtrace tools to keep a running count of L2 cache misses, and then wake 
> up each several msec and sample both who is running and what the 
> current counts are.  (In such an application, we would just be using 
> dtrace as a quick way of enabling and disabling the specific counters 
> we want to track.)

The user guide chapter will have more and different examples. I'll
have a play around with that idea but I'm not sure how useful it is
to correlate values that we've been counting with a piece of data such
as the current onproc thread. Still, you never know till you've tried it.

Thanks.

Jon.

>
> Peter
>
> Jon Haslam wrote:
>>> Tracing Fans,
>>>
>>> I know it's been a long time in coming but the CPU Performance
>>> Counter (CPC) provider is almost here! The code is currently in
>>> for review and a proposed architecture document is attached here
>>> for review.
>>
>> Many thanks to all those that gave me feedback on this proposal.
>> A revised version is attached which we'll hopefully submit shortly.
>> The additions I've done to the original are really just to try and
>> be a bit more verbose about the behaviour of the provider. For
>> those that are interested additions were made to Section
>> "B1 - Probe Format" and "B3 - Probe Availability". Also the
>> default minimum overflow rate has been lowered from 10000 to
>> 5000.
>>
>> If any of the changes make you violently ill, please let me know.
>>
>> Jon.
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss@opensolaris.org

_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]