Looking at dtrace.c (in the function dtrace_speculation_commit) it looks as if the speculated action printfs are actually formatted at probe time. It seems apparent to me that if the compiler tagged each action printf with a format id, then saved only the printf args during probe time and subsequently applied the printf formatting at commit; that there would be a significantly reduced probe effect in the non-error case (i.e. the case in which the speculation buffer is ultimately discarded). Thoughts and/or comments? Thanks, Rennie, Rennie Allen, Systems Engineer, GoAhead Software Inc. Mobile: (951)704-2447 Email: rallen at goahead.com Web: http://www.goahead.com Linked-in: http://www.linkedin.com/in/rennieallen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090504/20ff611b/attachment.html>
On Mon, May 04, 2009 at 03:15:15PM -0700, Rennie Glen Allen wrote:> Looking at dtrace.c (in the function dtrace_speculation_commit) it > looks as if the speculated action printfs are actually formatted at > probe time.Where, exactly, are you getting this from? All dtrace_speculation_commit() does is copy a bunch of data from the speculation buffer to the main buffer.> It seems apparent to me that if the compiler tagged > each action printf with a format id, then saved only the printf args > during probe time and subsequently applied the printf formatting at > commit; that there would be a significantly reduced probe effect in > the non-error case (i.e. the case in which the speculation buffer is > ultimately discarded).I''m not sure what you mean; any printf() action goes from: printf("%d %d %d", a, b, c); to a data buffer that looks like (assuming a, b, c are ints): offset 0 epid 4 a 8 b c c where formatid is an index into the array of formats for this dtrace consumer. The epid allows the consumer to get metadata (dtrace_eprobedesc_t) about the format of this block, which includes an array of "dtrace_recdesc_t"s, describing the records. The records will be: PRINTF (format 1), offset 4, size 4 (a) PRINTF (format 2), offset 8, size 4 (b) PRINTF (format 3), offset c, size 4 (c) Formats 1, 2, and 3 will all reference the string "%d %d %d", and libdtrace will only be grab the descriptor of this epid from the kernel once. It doesn''t matter if it''s speculative or not; no "formatting" is done until the data reaches userland; there''s no code in the kernel to even think about doing so. Cheers, - jonathan
Jonathan, Thanks! please see in-line... Rennie Allen, Systems Engineer, GoAhead Software Inc. Mobile: (951)704-2447 Email: rallen at goahead.com Web: http://www.goahead.com Linked-in: http://www.linkedin.com/in/rennieallen ----- Original Message ----- From: Jonathan Adams Sent: Mon, 5/4/2009 4:17pm To: renallen at cisco.com Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] speculative tracing On Mon, May 04, 2009 at 03:15:15PM -0700, Rennie Glen Allen wrote:> Where, exactly, are you getting this from? All dtrace_speculation_commit() > does is copy a bunch of data from the speculation buffer to the main buffer.Yup. I agree, that''s all it does.> I''m not sure what you mean; any printf() action goes from:> printf("%d %d %d", a, b, c); > > to a data buffer that looks like (assuming a, b, c are ints):> offset > 0 epid > 4 a > 8 b > c c> where formatid is an index into the array of formats for this dtrace consumer. > The epid allows the consumer to get metadata (dtrace_eprobedesc_t) about the > format of this block, which includes an array of "dtrace_recdesc_t"s, describing > the records.> The records will be:> PRINTF (format 1), offset 4, size 4 (a) > PRINTF (format 2), offset 8, size 4 (b) > PRINTF (format 3), offset c, size 4 (c)> Formats 1, 2, and 3 will all reference the string "%d %d %d", and libdtrace > will only be grab the descriptor of this epid from the kernel once.Fantastic! That''s exactly the way I though it should work (but I wasn''t able to find where this mechanism was coded), in my (too) short investigation.> It doesn''t matter if it''s speculative or not; no "formatting" is done until > the data reaches userland; there''s no code in the kernel to even think about > doing so.Yes, I didn''t think there was a difference between speculative and non-speculative. I just wasn''t able to find the mechanism above in a cursory glance at the source. Thanks for taking the time to explain it to me. Rennie