This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path


Frank Ch. Eigler wrote:
> Hi -
>
> On Mon, Jan 19, 2009 at 10:12:55AM +1100, Greg Banks wrote:
>   
>> [...]
>>     
>>> It would make more sense to me to turn dprintk's into trace_marks, 
>>>       
>> Umm, ok.  Sorry to be so ignorant but where would I find the doc that
>> tells me about adding trace marks ?
>>     
>
> Documentation/markers.txt
>   

Thanks.
>   
>> The control interface seems a little primitive.  It seems like you
>> can only activate and deactivate single printks ?
>>     
>
> Or single classes (identical names) per activate/deactivate call.
>
>   
The problem with this "classes" approach -- which sounds to my ignorant
ears like the "facilities" feature of nfs/sunrpc dprintks -- is
predicting which combination of classes to define so that they're useful
in the field years later with unknown bugs and unknown load patterns.  I
found that querying by function name was more useful in practice.
>
> [...]
> - it could generalize the handling of these dprintks, by not just
>   being tied to message printing, but becoming of possible use for
>   statistics/health monitoring
>   

That sounds potentially useful.  I was considering extending my dprintk
patch to add a flag to optionally bump a counter when the dprintk() line
is executed, but doing it via trace markers could be more useful if less
performant.

Let me do some reading on trace markers and get back to this.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]