Re: [RFC] The New and Improved Logdev (now with kprobes!)

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

Hi Steven,

The dynamic abilities of your logdev are very interesting! If I may emit some
ideas :

It would be great to have this logging information recorded into a standardized
buffer format so it could be analyzed with data gathered by other
instrumentation. Instead of using Tom's relay mechanism directly, you might
want to have a look at LTTng (http://ltt.polymtl.ca) : it would be a simple
matter of describing your own facility (group of event), the data types they
record, run genevent (serialization code generator) and call those
serialization functions when you want to record to the buffers from logdev.

One thing logdev seems to have that LTTng does't currently is the integration
with a mechanism that dumps the output upon a crash (LKCD integration). It's no
rocket science, but I just did not have time to do it.

I think it would be great to integrate those infrastructures together so we can
easily merge information coming from various sources (markers, logdev, systemTAP
scripts, LKET).

* Steven Rostedt (rostedt@goodmis.org) wrote:
> 1. break point and a watch address
> 
> This simply allows you to set a break point at some address (or pass in
> a function name if it exists in kallsyms).
> 
> logprobe -f hrtimer_start  -v jiffies_64
> 
Does it automatically get the data type, or is there any way to specify it ?

> 
> 2. break point and watch from current
> 
> This allows a user to see something on the current task_struct. You need
> to know the offset exactly. In the below example, I know that 20 (dec)
> is the offset in the task_struct to lock_depth.
> 
> example:
> 
> logprobe -f schedule -c 20 "lock_depth"
> 
> produces:
> 
>   [ 8757.854029] cpu:1 sawfish:3862 func: schedule (0xc02f8320) lock_depth index:20 = 0xffffffff
> 

Could we think of a quick hack that would involve using gcc on stdin and return
an "offsetof", all in user-space ?

> 
> 3. break point and watch fixed type
> 
> This is a catch all for me. I currently only implement preempt_count.
> 
> 
>  logprobe -t pc -f _spin_lock
> 
> produces:
> 
>    [ 9442.215693] cpu:0 logread:6398 func: _spin_lock (0xc02fab9d)  preempt_count:0x0
> 
Ouch, I can imagine the performance impact of this breakpoint though :) This is
a case where marking the code helps a lot.


Regards,

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68