[ltt-dev] LTTng specialized probes

[jan.kiszka@web.de (Jan Kiszka)]

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?

Just a thought...

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20081008/c2cf412d/attachment.pgp>