From mboxrd@z Thu Jan 1 00:00:00 1970 From: jan.kiszka@web.de (Jan Kiszka) Date: Wed, 08 Oct 2008 17:56:04 +0200 Subject: [ltt-dev] LTTng specialized probes In-Reply-To: <20081008000727.GA22427@Krystal> References: <5df78e1d0809231814i4b9b98eeyfb9746e5dbb9eb72@mail.gmail.com> <20080924072503.GA15570@bolzano.suse.de> <532480950809240032t644448f7lc4fdc0dffca69b9@mail.gmail.com> <20081006141113.GE1808@Krystal> <5df78e1d0810061055q1f02a1f0uac1cf0981fba8f40@mail.gmail.com> <5df78e1d0810071116i2e9790cdx8d5854dbfa50cfaf@mail.gmail.com> <6cc912950810071428m459aff32tb5fad99e45648170@mail.gmail.com> <20081008000727.GA22427@Krystal> Message-ID: <48ECD814.4030705@web.de> Message-ID: <20081008155604.72AzlqMPBOT4utjCGz8e0ct1ufpuayXJqW0YbTN2ERs@z> 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: