dtrace discuss - Jul 2006 - DTRACE_PROBE5 for kernel builds

In the <sys/sdt.h> file, there is a DTRACE_PROBE5 provided for non-kernel
compiles only.

Is there any reason why we shouldn''t add a DTRACE_PROBE5 for kernel
builds?

Is there a significant performance bump here such as it forcing the compiler to
make the dtrace call using the stack for parameters on sparc rather than just
registers?

Darren
 
 
This message posted from opensolaris.org

>In the <sys/sdt.h> file, there is a DTRACE_PROBE5 provided for
non-kernel compiles only.
>
>Is there any reason why we shouldn''t add a DTRACE_PROBE5 for kernel
builds?
>
>Is there a significant performance bump here such as it forcing the compiler
to make the dtrace ca
ll using the stack for parameters on sparc rather than just
registers?
>

There are 6 registers used for function calls (%o0 - %o6) so I would
think not.

Casper

On Thu, Jul 27, 2006 at 01:51:17PM +0200, Casper.Dik at Sun.COM
wrote:
> 
> >In the <sys/sdt.h> file, there is a DTRACE_PROBE5 provided for
non-kernel compiles only.
> >
> >Is there any reason why we shouldn''t add a DTRACE_PROBE5 for
kernel builds?
> >
> >Is there a significant performance bump here such as it forcing the
compiler to make the dtrace ca
> ll using the stack for parameters on sparc rather than just registers?
> >
We should add DTRACE_PROBE5() when we add an SDT provider that uses it.
> There are 6 registers used for function calls (%o0 - %o6) so I would
> think not.
On SPARC there are 6 registers used for arguments (%o0 - %o5), but %o6 is a
special argument we like to call the ''stack pointer''.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

>On Thu, Jul 27, 2006 at 01:51:17PM +0200, Casper.Dik at Sun.COM wrote:
>> 
>> >In the <sys/sdt.h> file, there is a DTRACE_PROBE5 provided
for non-kernel compiles only.
>> >
>> >Is there any reason why we shouldn''t add a DTRACE_PROBE5
for kernel builds?
>> >
>> >Is there a significant performance bump here such as it forcing the
compiler to make the dtrace
 ca
>> ll using the stack for parameters on sparc rather than just registers?
>> >
>
>We should add DTRACE_PROBE5() when we add an SDT provider that uses it.
>
>> There are 6 registers used for function calls (%o0 - %o6) so I would
>> think not.
>
>On SPARC there are 6 registers used for arguments (%o0 - %o5), but %o6 is a
>special argument we like to call the ''stack pointer''.
Typo: %o0 - %o6 are *seven* registers; I meant %o0 - %o5; those are
six registers.

Casper

Hi Darren,

Probes exported by the SDT provider are considered private interfaces not
intended for external use (at least, not with any sort of guarantees).
They''re
really intended to be used by the subsystem developers and as such I''d
argue
that useability isn''t of the utmost importance. What is probably
relevant is
that passing more arguments, and dereferencing a bunch of pointers to derive
those arguments as you''re doing in the code you sent can cause
observable
performance degradations. I suggest you pass as few arguments as possible
and do the pointer chasing in D. You can make this a bit easier by making
the arguments typed (see usr/src/uts/common/dtrace/sdt_subr.c) and using the
args[N] array in your D program.

Adam

On Mon, Jul 31, 2006 at 04:33:45PM +0800, Darren Reed
wrote:
> Adam Leventhal wrote:
> 
> >On Thu, Jul 27, 2006 at 01:51:17PM +0200, Casper.Dik at Sun.COM wrote:
> >
> >>>In the <sys/sdt.h> file, there is a DTRACE_PROBE5
provided for
> >>>non-kernel compiles only.
> >>>
> >>>Is there any reason why we shouldn''t add a
DTRACE_PROBE5 for kernel
> >>>builds?
> >>>
> >>>Is there a significant performance bump here such as it forcing
the
> >>>compiler to make the dtrace ca
> >>>
> >>ll using the stack for parameters on sparc rather than just
registers?
> >>
> >
> >We should add DTRACE_PROBE5() when we add an SDT provider that uses it.
> >
> 
> Ok.
> 
> In pfhooks, we''re looking at adding some dtrace SDT probes that
will
> enable people to easily look at what the hooks are doing.
> 
> To make it easy to specify a dtrace probe that matches a particular
> hook, we''ve pulled out some of the strings inside structures being
> passed through to dtrace.
> 
> To extract the probes as they are now, they look like:
> 
>        DTRACE_PROBE3(hook__run__start,
>            char *, hei->hei_event->he_name,
>            hook_data_t, info,
>            hook_event_token_t, token);
> 
>                DTRACE_PROBE5(hook__func__start,
>                    char *, hei->hei_event->he_name,
>                    hook_data_t, info,
>                    hook_event_token_t, token,
>                    char *, hi->hi_hook.h_name,
>                    hook_t *, &hi->hi_hook);
> 
>                DTRACE_PROBE5(hook__func__end,
>                    char *, hei->hei_event->he_name,
>                    hook_data_t, info,
>                    hook_event_token_t, token,
>                    char *, hi->hi_hook.h_name,
>                    hook_t *, &hi->hi_hook);
> 
>        DTRACE_PROBE3(hook__run__end,
>            char *, hei->hei_event->he_name,
>            hook_data_t, info,
>            hook_event_token_t, token);
> 
> The goal here is to make it easy to specify a single
> probe that gets you a single hook - e.g.
> 
> sdt:hook:hook_run:hook-func-start/arg0 == "PHYSICAL_IN"
&& arg3 ==
> "ipfilter"/{ something }
> 
> In this case, ''hei'' is actually the same as
''token'',
> but ''hei'' is not a structure that''s meant to be
exterinally
> visible.
> 
> Would it be expected that in the PROBE5''s, we''d just pass
> &hi->hi_hook and let the user specify h_name if they wanted
> that themselves?  Just changing that one would transform
> the above probe into the following:
> 
> sdt:hook:hook_run:hook-func-start/arg0 == "PHYSICAL_IN"
&& ((hook_t
> *)arg3)->h_name == "ipfilter"/{ something }
> 
> Personally, I find the former much easier to read/write but
> I can see the point in keeping everything to fit the latter.
> 
> Darren
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl