dtrace discuss - Nov 2005 - How to get the minor page fault by the dtrace.

Hi,
 As we can get the major page fault report by the maj_fault. In the same what is
the prob to get the minor page fault.

Thanks,
Dummy
This message posted from opensolaris.org

Howdy,

Take a look at the following thread:

http://www.opensolaris.org/jive/thread.jspa?threadID=2295&tstart=45

This describes how to measure minor/major faults.

Thanks,
- Ryan

On Sun, 6 Nov 2005, Dummy wrote:
> Hi,
> As we can get the major page fault report by the maj_fault. In the same
what is the prob to get the minor page fault.
>
> Thanks,
> Dummy
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

Howdy,

I am adding numerous probes to an application (one I didn''t write), and
I
was curious if I could get some feedback from the folks on the list. Given 
the following outline:

int socket_send(const char *buf, char *len)
{

[ ... ]

rv = wait_for_io_or_timeout(NULL, sock, 0);
if (rv != SUCCESS) {
        *len = 0;

        #ifdef WITH_DTRACE
        DTRACE_PROBE3(ws, socket_send, rv, len, buf);
        #endif

        return rv;
}

[ ... ]

if (rv == -1) {
        *len = 0;

        #ifdef WITH_DTRACE
        DTRACE_PROBE3(ws, socket_send, rv, len, buf);
        #endif

        return errno;
}

[ ... ]

#ifdef WITH_DTRACE
DTRACE_PROBE3(ws, socket_send, rv, len, buf);
#endif

return SUCCESS;

}

Do the probe definitions seem resonable? Are there better ways to do this? 
And last but not least, do I need to name the probe definitions differently
(e.g., socket_send_error_V, socket_send_errorX, socket_send)? I read
Dragon''s
PDF, Alan''s presentation and the statically defined probe chapters
numerous
times, but still have some questions on the best locations to place 
probes. Since I am also very new to all of this, I thought I would solicite some
feedback from the smart folks on the list.

Thanks,
- Ryan

--
UNIX Administrator
http://daemons.net/~matty

> 
> Howdy,
> 
> I am adding numerous probes to an application (one I didn''t
write), and I
> was curious if I could get some feedback from the folks on the list. Given 
> the following outline:
> 
> int socket_send(const char *buf, char *len)
> {
> 
> [ ... ]
> 
> Do the probe definitions seem resonable? Are there better ways to do this? 
> And last but not least, do I need to name the probe definitions differently
> (e.g., socket_send_error_V, socket_send_errorX, socket_send)? I read
Dragon''s
> PDF, Alan''s presentation and the statically defined probe chapters
numerous
> times, but still have some questions on the best locations to place 
> probes. Since I am also very new to all of this, I thought I would solicite
some
> feedback from the smart folks on the list.
Ryan,

Your sample code seemed quite reasonable.  Here are a couple of general tips
for using the statically defined probe mechanism:

1. Remember that your users have the pid provider at their disposal, too:
   the reason to use statically defined probes is for offering well-defined
   probes with higher stability and well-defined semantics to your clients.
   If you''re just taking functions and instrumenting their entry and
return
   and your intended audience is developers, there''s really no need to
use
   statically defined probes, because they can just use the pid provider
   to instrument the same locations.

2. Avoid doing things in the instrumented program itself that you can do in D.
   For example, if you have struct foo *f and you want to enable someone to
   trace two of its members f->x and f->y, it is much more efficient to
do:

	DTRACE_PROBE1(myprovider, myprobe, f);

   than to do this:

        DTRACE_PROBE2(myprovider, myprobe, f->x, f->y);

   because f->x and f->y could be computed in D only when the program is
   instrumented, as opposed to making the compiler generate that code.

3. You can define as many instances of probes as you like.  So if it is
   important to semantically distinguish socket_send_error_V from
   socket_send_error_X, you can of course have those as separate probes.

   Alternately, you can have more than one call site for DTRACE_PROBE*
   that uses your provider name and the probe name "socket_send_error"
   and passes the error code as an argument or whatever.  If multiple
   locations are defined, then something like this:

	dtrace -n myprovider:::myprobe

   will enable all of the defined locations.

Let us know if you have any other questions,

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

On Sun, 6 Nov 2005, Michael Shapiro wrote:
> 1. Remember that your users have the pid provider at their disposal, too:
>   the reason to use statically defined probes is for offering well-defined
>   probes with higher stability and well-defined semantics to your clients.
>   If you''re just taking functions and instrumenting their entry
and return
>   and your intended audience is developers, there''s really no need
to use
>   statically defined probes, because they can just use the pid provider
>   to instrument the same locations.
Yikes! I guess I was unnecessarily adding problems! This makes tons of 
send. Thanks for the awesome suggestion!

> 2. Avoid doing things in the instrumented program itself that you can do in
D.
>   For example, if you have struct foo *f and you want to enable someone to
>   trace two of its members f->x and f->y, it is much more efficient
to do:
>
> 	DTRACE_PROBE1(myprovider, myprobe, f);
>
>   than to do this:
>
>        DTRACE_PROBE2(myprovider, myprobe, f->x, f->y);
>
>   because f->x and f->y could be computed in D only when the program
is
>   instrumented, as opposed to making the compiler generate that code.
So users who want to print members of struct f would be required to 
copyin() and cast or use copyinstr() if the member was a char*?

> 3. You can define as many instances of probes as you like.  So if it is
>   important to semantically distinguish socket_send_error_V from
>   socket_send_error_X, you can of course have those as separate probes.
>
>   Alternately, you can have more than one call site for DTRACE_PROBE*
>   that uses your provider name and the probe name
"socket_send_error"
>   and passes the error code as an argument or whatever.  If multiple
>   locations are defined, then something like this:
>
> 	dtrace -n myprovider:::myprobe
>
>   will enable all of the defined locations.
This is rad and super super super super helpful!
> Let us know if you have any other questions,
Thanks for taking the time to answer my questions!

- Ryan

--
UNIX Administrator
http://daemons.net/~matty

> ...
> > 2. Avoid doing things in the instrumented program itself that you can
do in D.
> >   For example, if you have struct foo *f and you want to enable
someone to
> >   trace two of its members f->x and f->y, it is much more
efficient to do:
> >
> > 	DTRACE_PROBE1(myprovider, myprobe, f);
> >
> >   than to do this:
> >
> >        DTRACE_PROBE2(myprovider, myprobe, f->x, f->y);
> >
> >   because f->x and f->y could be computed in D only when the
program is
> >   instrumented, as opposed to making the compiler generate that code.
> 
> So users who want to print members of struct f would be required to 
> copyin() and cast or use copyinstr() if the member was a char*?
For now, yes.  Longer-term I''m working on making the copyin happen
auto-magically as part of building user type and symbol awareness into D,
which will make writing these types of programs much easier.
> ... 
> Thanks for taking the time to answer my questions!
Thanks for DTracing!

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/