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
> 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.
> I don't see a way to e.g. activate every trace make in a particular
> function, or in a particular .c file. I thought both of these were
> useful things to do, so I implemented them. Below is an extract
> from the doc that accompanies the sgi-dprintk module. [...]
Very clever!
I am not an insider enough to carry much weight in this regard, but it
would make most sense to me if the sgi-dprintk widget were adapted so
that:
- it used trace_mark() as the low-level hook mechanism at the call sites
- it extended the trace_mark structures to track
__FILE__/__LINE__/__FUNCTION__ values
- it extended the marker activation API to be able to specify queries
based upon those __FILE__/etc. fields
- as an extension to the proposed marker->ftrace patch, extend the
option parser the same way as your /proc/dprintk does
The benefits might not be huge, but:
- it would reuse existing functionality (markers for the hooks, other
ftrace widgets for extra info to gather at each event - like the
stack traces)
- 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
- FChE
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.