[ltt-dev] LTTng specialized probes

[Mathieu Desnoyers]

* Jan Kiszka (jan.kiszka at web.de) wrote:
> Mathieu Desnoyers wrote:
> > Hi Michael,
> > 
> > * Michael Davidson (md at google.com) wrote:
> >> Hi, Mathieu!
> >>
> >> Jiaying forwarded this to me and I wanted to try to understand a
> >> little better exactly what direction you are headed in.
> >>
> >> Like Martin, I am (at least) a little confused and since I wasn't
> >> involved in the discussions in Portland please forgive me if I am
> >> going over old ground here.
> >>
> > 
> > No problem, I'll try to answer the best I can. Don't hesitate to ask for
> > clarifications if I am not clear enough.
> > 
> >> It seems to me that one of the key issues in getting good performance
> >> out of any kernel tracing system is that you have to record the data
> >> that you are trying to capture as quickly as possible. To me that
> >> means that during the initial recording of the data, to the maximum
> >> extent possible, you don't even look at it - you just slam it straight
> >> into your recording buffer and you are done (this should work well for
> >> the majority of cases where the data being captured are just scalar
> >> values - the more exotic the data the more processing it will need).
> >>
> > 
> > Yes, I agree that the best performance is achieved by having a probe
> > which already "knows" how much data to save and just "does it", and this
> > is what we want for high-throughput events.
> 
> I only loosely followed the thread and the latest format-string marker
> serialization code. So sorry in advance in case I contribute "cold
> coffee" now:
> 
> Has anyone thought of / tried out some caching mechanism for this task?
> I mean, scan the format string once (I don't think it will change during
> runtime... :->), save somewhere that it expects n bytes of
> to-be-serialized data on the caller's stack and then get away with only
> copying those over into the trace buffer on succeeding marker hits?
> 

A few reasons not to do this :
- The data won't always be on the stack in the same layout we want it in
  the trace. It is especially true for data smaller than the
  architecture pointer size which is aligned on the stack.
- Also, I fear that such caching mechanism will end up being much more
  complex, error prone and difficult to maintain than having a simple
  format string parser for the slow common-case and specialized code for
  the fast case. It's a bit like a JIT, but we use kernel hackers to
  generate the code. ;)

Mathieu

> Just a thought...
> 
> Jan
> 



-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20081008/fae80f7e/attachment-0003.pgp>