Sannjaya Srivastava
2006-Oct-05 22:53 UTC
[dtrace-discuss] newbie dtace filename for writes and count help
Hi, I need to watch and see which files are writtent by httpd process and how long it takes to complete the write operation. (between open and close. Also need to count total numbers of files written with the filenames. Please help me out in doing it. Thanks ...Sanjaya I have a little variation of /usr/demo/dtrace/w.d, but unable to get all info. This message posted from opensolaris.org
Dan Mick
2006-Oct-05 22:58 UTC
[dtrace-discuss] newbie dtace filename for writes and count help
Sannjaya Srivastava wrote:> Hi, > I need to watch and see which files are writtent by httpd process and how long it takes to complete the write operation. (between open and close. > > Also need to count total numbers of files written with the filenames. > > Please help me out in doing it. > > Thanks > > ...Sanjaya > > I have a little variation of /usr/demo/dtrace/w.d, but unable to get all info.Rather than having someone else write your program from scratch, why not post what you have, why you did what you did, and what''s working and what''s not?
Sannjaya Srivastava
2006-Oct-06 00:47 UTC
[dtrace-discuss] Re: newbie dtace filename for writes and count help
here is what I have so far.
I am struggling with the count, time .
#!/usr/sbin/dtrace -s
#pragma D option quiet
syscall::close:entry
/execname == "httpd" /
{
/*
* starting with a file descriptior, dig out useful info
* from the corresponding file_t and vnode_t.
*/
this->filistp = curthread->t_procp->p_user.u_finfo.fi_list;
this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp +
(uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t));
this->filep = this->ufentryp->uf_file;
self->offset = this->filep->f_offset;
this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0;
self->vpath = this->vnodep ? (this->vnodep->v_path != 0 ?
cleanpath(this->vnodep->v_path) : "<unknown>")
: "<unknown>";
printf("tid: %d, pid: %d execname: %s %s\n", tid, pid,
execname, self->vpath );
}
This message posted from opensolaris.org
Chip Bennett
2006-Oct-06 02:58 UTC
[dtrace-discuss] Re: newbie dtace filename for writes and count help
DTrace has probes for just about every event, so the best way to do this
(IMHO) is to gather information when the event, that has it readily
available, fires. To that end, see if this will work for you (I''m not
entirely sure I''ve captured what you wanted for the file count):
#pragma D option quiet
BEGIN
{
total = 0;
}
syscall::open:entry
/ execname == "httpd" /
{
self->fnp = arg0;
}
syscall::open:return
/ self->fnp && arg0 != -1 /
{
fn[pid,arg0] = cleanpath(copyinstr(self->fnp));
self->fnp = 0;
ot[pid,arg0] = timestamp;
}
syscall::close:entry
/ fn[pid,arg0] != 0 /
{
printf("tid: %d, pid: %d Time open: %d execname: %s %s\n",
tid, pid, timestamp-ot[pid,arg0], execname, fn[pid,arg0]);
@[fn[pid,arg0]] = count();
fn[pid,arg0] = 0;
total++;
}
END
{
printf ("Grand total # files open and closed: %d\n", total);
}
If any of this doesn''t make sense to you, feel free to reply to the
discussion list, and I (or whoever is around) will be glad to explain it.
Regards,
Chip
Sannjaya Srivastava wrote:> here is what I have so far.
>
> I am struggling with the count, time .
>
>
> #!/usr/sbin/dtrace -s
> #pragma D option quiet
>
> syscall::close:entry
> /execname == "httpd" /
> {
> /*
> * starting with a file descriptior, dig out useful info
> * from the corresponding file_t and vnode_t.
> */
>
>
> this->filistp =
curthread->t_procp->p_user.u_finfo.fi_list;
> this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp +
> (uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t));
> this->filep = this->ufentryp->uf_file;
> self->offset = this->filep->f_offset;
> this->vnodep = this->filep != 0 ? this->filep->f_vnode
: 0;
> self->vpath = this->vnodep ? (this->vnodep->v_path != 0
?
> cleanpath(this->vnodep->v_path) :
"<unknown>") : "<unknown>";
>
> printf("tid: %d, pid: %d execname: %s %s\n", tid, pid,
execname, self->vpath );
> }
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
Dan Mick
2006-Oct-06 03:17 UTC
[dtrace-discuss] Re: newbie dtace filename for writes and count help
This was your original question (reposted here, because in email, I no longer know what it was you wanted):> Hi, I need to watch and see which files are writtent by httpd process and how > long it takes to complete the write operation. (between open and close. > > Also need to count total numbers of files written with the filenames.So, below, you''ve implemented code that fires on a ''close'' call from httpd, but doesn''t do anything with ''open'' or ''write''. How were you thinking you''d get the information you want at close() time? For the files you''re interested in, are they opened/closed every time they''re written? If so, then I''d assume you want to keep a timestamp in open, get a timestamp in close and see what the difference is?...you''ll have to keep it in a data structure indexed by filename, I suppose, so you can get information matching the same file in open and close. Sannjaya Srivastava wrote:> here is what I have so far. > > I am struggling with the count, time . > > > #!/usr/sbin/dtrace -s > #pragma D option quiet > > syscall::close:entry > /execname == "httpd" / > { > /* > * starting with a file descriptior, dig out useful info > * from the corresponding file_t and vnode_t. > */ > > > this->filistp = curthread->t_procp->p_user.u_finfo.fi_list; > this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp + > (uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t)); > this->filep = this->ufentryp->uf_file; > self->offset = this->filep->f_offset; > this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0; > self->vpath = this->vnodep ? (this->vnodep->v_path != 0 ? > cleanpath(this->vnodep->v_path) : "<unknown>") : "<unknown>"; > > printf("tid: %d, pid: %d execname: %s %s\n", tid, pid, execname, self->vpath ); > } > > > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Russ Petruzzelli
2006-Oct-06 06:16 UTC
[dtrace-discuss] Re: newbie dtace filename for writes and count help
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dan, <br>
<br>
I was just studying this small example script at:<br>
<a class="moz-txt-link-freetext"
href="http://www.sun.com/software/solaris/howtoguides/dtracehowto.jsp">http://www.sun.com/software/solaris/howtoguides/dtracehowto.jsp</a><br>
it gets the function counts and timestamps....Can you apply it to your
situation?<br>
<br>
# This is from step 8 on the page....and it had a typo at line
9...which I''ve corrected...<br>
<code>#!/usr/sbin/dtrace -s<br>
pid$1:::entry<br>
{<br>
self->ts[probefunc] = timestamp;<br>
}<br>
pid$1:::return<br>
/self->ts[probefunc]/<br>
{<br>
@func_time[probefunc] = sum(timestamp - self->ts[probefunc]);
## <-- line modified<br>
ts[probefunc] = 0;<br>
}
</code><br>
<br>
<br>
Russ<br>
<br>
Dan Mick wrote:
<blockquote cite="mid4525CAB4.5090408@sun.com"
type="cite">This was
your original question (reposted here, because in email, I no longer
know what it was you wanted):
<br>
<br>
<blockquote type="cite">Hi, I need to watch and see which
files are
writtent by httpd process and how
<br>
long it takes to complete the write operation. (between open and close.
<br>
<br>
Also need to count total numbers of files written with the
filenames.
<br>
</blockquote>
<br>
So, below, you''ve implemented code that fires on a
''close'' call from
httpd, but doesn''t do anything with ''open'' or
''write''.
<br>
<br>
How were you thinking you''d get the information you want at close()
time?
<br>
<br>
For the files you''re interested in, are they opened/closed every time
they''re written? If so, then I''d assume you want to keep a
timestamp
in open, get a timestamp in close and see what the difference
is?...you''ll have to keep it in a data structure indexed by filename, I
suppose, so you can get information matching the same file in open and
close.
<br>
<br>
<br>
<br>
Sannjaya Srivastava wrote:
<br>
<blockquote type="cite">here is what I have so far.
<br>
<br>
I am struggling with the count, time .
<br>
<br>
<br>
#!/usr/sbin/dtrace -s
<br>
#pragma D option quiet
<br>
<br>
syscall::close:entry
<br>
/execname == "httpd" /
<br>
{
<br>
/*
<br>
* starting with a file descriptior, dig out useful info
<br>
* from the corresponding file_t and vnode_t.
<br>
*/
<br>
<br>
<br>
this->filistp curthread->t_procp->p_user.u_finfo.fi_list;
<br>
this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp +
<br>
(uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t));
<br>
this->filep = this->ufentryp->uf_file;
<br>
self->offset = this->filep->f_offset;
<br>
this->vnodep = this->filep != 0 ?
this->filep->f_vnode : 0;
<br>
self->vpath = this->vnodep ? (this->vnodep->v_path
!= 0 ?
<br>
cleanpath(this->vnodep->v_path) : "<unknown>")
: "<unknown>";
<br>
<br>
printf("tid: %d, pid: %d execname: %s %s\n", tid, pid,
execname, self->vpath );
<br>
}
<br>
<br>
<br>
This message posted from opensolaris.org
<br>
_______________________________________________
<br>
dtrace-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:dtrace-discuss@opensolaris.org">dtrace-discuss@opensolaris.org</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
dtrace-discuss mailing list
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:dtrace-discuss@opensolaris.org">dtrace-discuss@opensolaris.org</a>
<br>
</blockquote>
</body>
</html>
Russ Petruzzelli
2006-Oct-06 06:21 UTC
[dtrace-discuss] Re: newbie dtace filename for writes and count help
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
This was meant for Sannjaya....<br>
And I noticed that the "count" part of the script is in another step
at
the URL I referenced...<br>
<br>
<code>#!/usr/sbin/dtrace -s<br>
pid$target:libc::entry<br>
{<br>
@[probefunc]=count();<br>
}
</code> <br>
<br>
<br>
Russ Petruzzelli wrote:
<blockquote cite="mid4525F4D8.8060703@sun.com"
type="cite">
<meta content="text/html;charset=UTF-8"
http-equiv="Content-Type">
Dan, <br>
<br>
I was just studying this small example script at:<br>
<a class="moz-txt-link-freetext"
href="http://www.sun.com/software/solaris/howtoguides/dtracehowto.jsp">http://www.sun.com/software/solaris/howtoguides/dtracehowto.jsp</a><br>
it gets the function counts and timestamps....Can you apply it to your
situation?<br>
<br>
# This is from step 8 on the page....and it had a typo at line
9...which I''ve corrected...<br>
<code>#!/usr/sbin/dtrace -s<br>
pid$1:::entry<br>
{<br>
self->ts[probefunc] = timestamp;<br>
}<br>
pid$1:::return<br>
/self->ts[probefunc]/<br>
{<br>
@func_time[probefunc] = sum(timestamp - self->ts[probefunc]);
## <-- line modified<br>
ts[probefunc] = 0;<br>
}
</code><br>
<br>
<br>
Russ<br>
<br>
Dan Mick wrote:
<blockquote cite="mid4525CAB4.5090408@sun.com"
type="cite">This was
your original question (reposted here, because in email, I no longer
know what it was you wanted): <br>
<br>
<blockquote type="cite">Hi, I need to watch and see which
files are
writtent by httpd process and how <br>
long it takes to complete the write operation. (between open and close.
<br>
<br>
Also need to count total numbers of files written with the
filenames. <br>
</blockquote>
<br>
So, below, you''ve implemented code that fires on a
''close'' call from
httpd, but doesn''t do anything with ''open'' or
''write''. <br>
<br>
How were you thinking you''d get the information you want at close()
time? <br>
<br>
For the files you''re interested in, are they opened/closed every time
they''re written? If so, then I''d assume you want to keep a
timestamp
in open, get a timestamp in close and see what the difference
is?...you''ll have to keep it in a data structure indexed by filename, I
suppose, so you can get information matching the same file in open and
close. <br>
<br>
<br>
<br>
Sannjaya Srivastava wrote: <br>
<blockquote type="cite">here is what I have so far.
<br>
<br>
I am struggling with the count, time . <br>
<br>
<br>
#!/usr/sbin/dtrace -s <br>
#pragma D option quiet <br>
<br>
syscall::close:entry <br>
/execname == "httpd" / <br>
{ <br>
/* <br>
* starting with a file descriptior, dig out useful info <br>
* from the corresponding file_t and vnode_t. <br>
*/ <br>
<br>
<br>
this->filistp curthread->t_procp->p_user.u_finfo.fi_list;
<br>
this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp +
<br>
(uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t)); <br>
this->filep = this->ufentryp->uf_file; <br>
self->offset = this->filep->f_offset; <br>
this->vnodep = this->filep != 0 ?
this->filep->f_vnode : 0; <br>
self->vpath = this->vnodep ? (this->vnodep->v_path
!= 0 ? <br>
cleanpath(this->vnodep->v_path) : "<unknown>")
: "<unknown>"; <br>
<br>
printf("tid: %d, pid: %d execname: %s %s\n", tid, pid,
execname, self->vpath ); <br>
} <br>
<br>
<br>
This message posted from opensolaris.org <br>
_______________________________________________ <br>
dtrace-discuss mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:dtrace-discuss@opensolaris.org">dtrace-discuss@opensolaris.org</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
dtrace-discuss mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:dtrace-discuss@opensolaris.org">dtrace-discuss@opensolaris.org</a>
<br>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
dtrace-discuss mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:dtrace-discuss@opensolaris.org">dtrace-discuss@opensolaris.org</a>
</pre>
</blockquote>
</body>
</html>
Hi, Running a Dtrace program with simple probe pattern: fbt:genunix::entry got dtrace: script ''cc.d'' matched 5953 probes in ONE second. However, running with 100 probe patterns such as: fbt:genunix:calcloadavg:entry, fbt:genunix:delay_wakeup:entry, fbt:genunix:deadman:entry, fbt:genunix:deadman_online:entry, fbt:genunix:clock_highres_settime:entry, .. .. <100 of them> got dtrace: script ''cc.d'' matched 100 probes in about TEN seconds. I also try 200 probes and got about 20 seconds. So, it appears to be proportional to the number of probe patterns. My question is: Why enabling 2% of the probes in a module takes 10 time longer than enabling the entire module? BTW, people might want to ask why I am doing this. It is because I am developing a test coverage tool which allow user to define their own tracing scope. For instance, user might want to select 600 probes in genunix as tracing scope and ends up waiting for one minute before they could run their applications or test programs. This may not be acceptable to the user. Thanks. ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
> However, running with 100 probe patterns such as: > > fbt:genunix:calcloadavg:entry, > fbt:genunix:delay_wakeup:entry, > fbt:genunix:deadman:entry, > fbt:genunix:deadman_online:entry, > fbt:genunix:clock_highres_settime:entry, > .. > .. > <100 of them> > > got > > dtrace: script ''cc.d'' matched 100 probes > > in about TEN seconds. > > I also try 200 probes and got about 20 seconds. > So, it appears to be proportional to the number > of probe patterns. > > My question is: > Why enabling 2% of the probes in a module takes > 10 time longer than enabling the entire module?Because -- as you said -- they''re proportional to the number of probe descriptions. Every probe description represents a disjoint DTRACEIOC_PROBEMATCH ioctl, followed by a DTRACEIOC_PROBEARG ioctl. There are certainly things we can do to speed this up -- but it will always be true that the time to enable probes will be proportional to the number of probe descriptions. This was a conscious design decision that we made; we have designed the system to be very quick when enabling many probes with few descriptions -- at the cost of having more per-description work.> BTW, people might want to ask why I am doing this. > It is because I am developing a test coverage > tool which allow user to define their own tracing > scope. For instance, user might want to select > 600 probes in genunix as tracing scope and ends > up waiting for one minute before they could run > their applications or test programs. This may > not be acceptable to the user.Why one would want to manually select 600 probes that could not be selected using higher-level mechanisms (e.g., by module) is somewhat beyond me. Even if it''s possible that someone would want to explicitly specify so many descriptions, it''s certainly not a case that we''re going to optimize for... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Bryan, Bryan Cantrill wrote On 10/06/06 14:53,:>>BTW, people might want to ask why I am doing this. >>It is because I am developing a test coverage >>tool which allow user to define their own tracing >>scope. For instance, user might want to select >>600 probes in genunix as tracing scope and ends >>up waiting for one minute before they could run >>their applications or test programs. This may >>not be acceptable to the user. > > > Why one would want to manually select 600 probes that could not be > selected using higher-level mechanisms (e.g., by module) is somewhat > beyond me. Even if it''s possible that someone would want to explicitly > specify so many descriptions, it''s certainly not a case that we''re going > to optimize for...Good question. Let me explain why. Actually, we translate the module''s ELF symbolic object into a function calling map from which user could select a function such that all functions and subsequent functions called from this select function are automatically selected so user do not need to hand pick each function. Potentially, the number of selections in this scheme could be hundreds even thousands. A lot of users really want to use this selection scheme to narrow their tracing scope. In fact, I already developed a effective algorithm to generate a list of regular expressions to allow D-compiler to translate into precise probes such that certain function probes are excluded (i.e. disabled) from all available probes. However, currently, I do not have similar algorithm for inclusion. If there is no good alternative to inclusion issue, then I may have to figure out a algorithm to generate a D-compiler understandable regular expression to include all selected functions and, hopefully, the number of regular expressions is much less than the number of selected functions. However, I hate to re-invent the wheel if there already exists a viable solution to this. If someone knows an existing way to generate a list of regular expressions that is much shorter than a list of selected name, please let me know. Thanks.> - Bryan > > -------------------------------------------------------------------------- > Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
CHIAN-PHON LIN wrote:>> Why one would want to manually select 600 probes that could not be >> selected using higher-level mechanisms (e.g., by module) is somewhat >> beyond me. Even if it''s possible that someone would want to explicitly >> specify so many descriptions, it''s certainly not a case that we''re going >> to optimize for... > > Good question. Let me explain why. > Actually, we translate the module''s ELF symbolic object into a function > calling map from which user could select a function such that all > functions and subsequent functions called from this select function > are automatically selected so user do not need to hand pick each > function.Why doesn''t the usual technique work: setting a dtrace variable in a probe on your "selected" function, and testing that variable in a predicate on probes on all functions? - Jeremy
Jeremy, Jeremy Harris wrote On 10/07/06 12:01,:> CHIAN-PHON LIN wrote: > >>> Why one would want to manually select 600 probes that could not be >>> selected using higher-level mechanisms (e.g., by module) is somewhat >>> beyond me. Even if it''s possible that someone would want to explicitly >>> specify so many descriptions, it''s certainly not a case that we''re going >>> to optimize for... >> >> >> Good question. Let me explain why. >> Actually, we translate the module''s ELF symbolic object into a function >> calling map from which user could select a function such that all >> functions and subsequent functions called from this select function >> are automatically selected so user do not need to hand pick each >> function. > > > Why doesn''t the usual technique work: setting a dtrace variable in a > probe on your "selected" function, and testing that variable in a > predicate on probes on all functions?Sounds a good idea as long as the probe trap overhead of non-selected probes is not significent. I guess what you suggest to do is something similar to below, right? BEGIN { pick["function1"] = 1; pick["function2"] = 1; .. .. } fbt:genunix::entry /pick[probefunc]/ { } Thanks.> - Jeremy > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
CHIAN-PHON LIN wrote:> Sounds a good idea as long as the probe trap overhead of non-selected > probes is not significent. I guess what you suggest to do is something > similar to below, right? > > BEGIN > { > pick["function1"] = 1; > pick["function2"] = 1; > .. > .. > } > > fbt:genunix::entry > /pick[probefunc]/ > { > }More along the lines of: fbt::function1:entry { self->tr = 1; } fbt::function1:return { self->tr = 0; } fbt:genunix:: /self->tr/ { } - Jeremy
Jeremy, Jeremy Harris wrote On 10/07/06 14:56,:> CHIAN-PHON LIN wrote: > >> Sounds a good idea as long as the probe trap overhead of non-selected >> probes is not significent. I guess what you suggest to do is something >> similar to below, right? >> >> BEGIN >> { >> pick["function1"] = 1; >> pick["function2"] = 1; >> .. >> .. >> } >> >> fbt:genunix::entry >> /pick[probefunc]/ >> { >> } > > > More along the lines of: > > fbt::function1:entry { self->tr = 1; } > fbt::function1:return { self->tr = 0; } > > fbt:genunix:: > /self->tr/ > { > } >This is an elegent solution if the number of selected functions is small. The problem of this scheme is D-compiler time becomes too long if the number of selected function is large. In my original mail, I mentioned about that fbt:::entry only takes about ONE second to compile but multiple fbt::xxx:entry could take much longer. For example, if you have 1000 of fbt::xxx:entry, then it will take about 100 second to compile that may not be acceptable to the user. Another problem of this scheme is that each probe is processed only once in the life time of this D-program so certain informations such as hit-count are not obtainable. Thanks.> > - Jeremy > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
CHIAN-PHON LIN wrote:>> fbt::function1:entry { self->tr = 1; } >> fbt::function1:return { self->tr = 0; } >> >> fbt:genunix:: >> /self->tr/ >> { >> } >> > > This is an elegent solution if the number of selected > functions is small. > > The problem of this scheme is D-compiler time becomes > too long if the number of selected function is large. > In my original mail, I mentioned about that > fbt:::entry only takes about ONE second to > compile but multiple fbt::xxx:entry could take > much longer. For example, if you have 1000 of > fbt::xxx:entry, then it will take about 100 second > to compile that may not be acceptable to the user.The point is that you only need a small number of the lines saying "function1" above. You wanted: > [...] user could select a function such that all > functions and subsequent functions called from this select function > are automatically selected so user do not need to hand pick each > function. Potentially, the number of selections in this scheme could be > hundreds even thousands. and you get that. Only the one function the user picks need be named in the D script. All of the called functions, and subsequent called functions, are handled by the /self->tr/ predicate.> Another problem of this scheme is that each probe is > processed only once in the life time of this D-program > so certain informations such as hit-count are not > obtainable.Pardon? "Processed"? The D script will run until you kill it, unless you program it to stop. During the run, however long, probes can be being hit. You can add code in the probes to count the number of hits, if you want that. - Jeremy
Jeremy, Now I got it and this is absolutely elegent solution. I really don''t know what I was thinking. Thanks a lot for your tireless explanation. Jeremy Harris wrote On 10/07/06 15:55,:> CHIAN-PHON LIN wrote: > >>> fbt::function1:entry { self->tr = 1; } >>> fbt::function1:return { self->tr = 0; } >>> >>> fbt:genunix:: >>> /self->tr/ >>> { >>> } >>> >> >> This is an elegent solution if the number of selected >> functions is small. >> >> The problem of this scheme is D-compiler time becomes >> too long if the number of selected function is large. >> In my original mail, I mentioned about that >> fbt:::entry only takes about ONE second to >> compile but multiple fbt::xxx:entry could take >> much longer. For example, if you have 1000 of >> fbt::xxx:entry, then it will take about 100 second >> to compile that may not be acceptable to the user. > > > The point is that you only need a small number of the > lines saying "function1" above. You wanted: > > > [...] user could select a function such that all > > functions and subsequent functions called from this select function > > are automatically selected so user do not need to hand pick each > > function. Potentially, the number of selections in this scheme could be > > hundreds even thousands. > > and you get that. Only the one function the user > picks need be named in the D script. All of > the called functions, and subsequent called functions, > are handled by the /self->tr/ predicate. > > >> Another problem of this scheme is that each probe is >> processed only once in the life time of this D-program >> so certain informations such as hit-count are not >> obtainable. > > > Pardon? "Processed"? > > The D script will run until you kill it, unless you > program it to stop. During the run, however long, > probes can be being hit. You can add code in the > probes to count the number of hits, if you want that. > > - Jeremy-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
Jeremy, Jeremy Harris wrote On 10/07/06 14:56,:> > More along the lines of: > > fbt::function1:entry { self->tr = 1; } > fbt::function1:return { self->tr = 0; } > > fbt:genunix:: > /self->tr/ > { > }This scheme traces root function and subsequent called functions. We also like to support multiple root functions such as below: fbt:module1:function1:entry { self->tr = 1; } fbt:module1:function1:return { self->tr = 0; } fbt:module2:function2:entry { self->tr = 1; } fbt:module2:function2:return { self->tr = 0; } fbt::: /self->tr/ { } Do you see any problem in this new scheme? Thanks.> - Jeremy > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
CHIAN-PHON LIN wrote:> Jeremy, > > Jeremy Harris wrote On 10/07/06 14:56,: > >> >> More along the lines of: >> >> fbt::function1:entry { self->tr = 1; } >> fbt::function1:return { self->tr = 0; } >> >> fbt:genunix:: >> /self->tr/ >> { >> } > > This scheme traces root function and subsequent called functions. > We also like to support multiple root functions such as below: > > fbt:module1:function1:entry { self->tr = 1; } > fbt:module1:function1:return { self->tr = 0; } > fbt:module2:function2:entry { self->tr = 1; } > fbt:module2:function2:return { self->tr = 0; } > > fbt::: > /self->tr/ > { > } > > Do you see any problem in this new scheme?if you have this sequence of events: function1() entry function2() entry function2() return then you''ll stop tracing your data. Better do self->tr++ and self->tr--, if the sequence I gave is a possibility. HTH -- Michael Schuster Recursion, n.: see ''Recursion''
Michael, Michael Schuster wrote On 10/19/06 10:09,:> CHIAN-PHON LIN wrote: > >> Jeremy, >> >> Jeremy Harris wrote On 10/07/06 14:56,: >> >>> >>> More along the lines of: >>> >>> fbt::function1:entry { self->tr = 1; } >>> fbt::function1:return { self->tr = 0; } >>> >>> fbt:genunix:: >>> /self->tr/ >>> { >>> } >> >> >> This scheme traces root function and subsequent called functions. >> We also like to support multiple root functions such as below: >> >> fbt:module1:function1:entry { self->tr = 1; } >> fbt:module1:function1:return { self->tr = 0; } >> fbt:module2:function2:entry { self->tr = 1; } >> fbt:module2:function2:return { self->tr = 0; } >> >> fbt::: >> /self->tr/ >> { >> } >> >> Do you see any problem in this new scheme? > > > if you have this sequence of events: > > function1() entry > function2() entry > function2() return > > then you''ll stop tracing your data. Better do self->tr++ and self->tr--, > if the sequence I gave is a possibility.Thank you for pointing out such potential scenario. So the D-program will look like: fbt:module1:function1:entry { self->tr++; } fbt:module1:function1:return { self->tr--; } fbt:module2:function2:entry { self->tr++; } fbt:module2:function2:return { self->tr--; } fbt::: /self->tr/ { } Right? Thanks.> HTH-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
CHIAN-PHON LIN wrote:> Thank you for pointing out such potential scenario. > So the D-program will look like: > > fbt:module1:function1:entry { self->tr++; } > fbt:module1:function1:return { self->tr--; } > fbt:module2:function2:entry { self->tr++; } > fbt:module2:function2:return { self->tr--; } > > fbt::: > /self->tr/ > { > } > > Right?this eliminates the pitfall I pointed out ... you''ll have to judge for yourself whether it satisfies your requirements :-) HTh -- Michael Schuster +49 89 46008-2974 / x62974 visit the online support center: http://www.sun.com/osc/ Recursion, n.: see ''Recursion''