Hi,
I like to find traced functions in a module and only want
to print it out once for each function traced regardless
how many times it is traced. So, I wrote d-program similar
to the one below and it works fine:
pid$target:xyz::entry
/!traced[probefunc]/
{
printf("%s\n", probefunc);
traced[probefunc] = 1;
}
But according to Performance Considerations (Chapter 38) of
Solaris Dynamic Tracing Guide, using global variable instead
of using cacheable variable is not recommanded. So, my
question is:
How can I use cacheable variable to get the same outcome?
THX.
--
************************************************
* 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 *
************************************************
Hm... I''m not sure you are going to be able to construct such a predicate. Is the enabled performance unacceptable? Adam On Mon, Nov 07, 2005 at 01:57:16PM -0800, CHIAN-PHON LIN wrote:> Hi, > > I like to find traced functions in a module and only want > to print it out once for each function traced regardless > how many times it is traced. So, I wrote d-program similar > to the one below and it works fine: > > pid$target:xyz::entry > /!traced[probefunc]/ > { > printf("%s\n", probefunc); > traced[probefunc] = 1; > } > > But according to Performance Considerations (Chapter 38) of > Solaris Dynamic Tracing Guide, using global variable instead > of using cacheable variable is not recommanded. So, my > question is: > > How can I use cacheable variable to get the same outcome? > > THX. > > -- > ************************************************ > * 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 * > ************************************************ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, Adam Leventhal wrote On 11/07/05 15:50,:> Hm... I''m not sure you are going to be able to construct such a predicate. > Is the enabled performance unacceptable?Yes, that is exact the reason especially when a short function is called billions times. The probing overhead to function run time ratio becomes too high. Other questions: Is there way to set every traced[probefunc] to zero at END{}? If not, what is the side effect to system memory? Are we going to have memory leak? THX.> Adam > > On Mon, Nov 07, 2005 at 01:57:16PM -0800, CHIAN-PHON LIN wrote: > >>Hi, >> >>I like to find traced functions in a module and only want >>to print it out once for each function traced regardless >>how many times it is traced. So, I wrote d-program similar >>to the one below and it works fine: >> >>pid$target:xyz::entry >>/!traced[probefunc]/ >>{ >> printf("%s\n", probefunc); >> traced[probefunc] = 1; >>} >> >>But according to Performance Considerations (Chapter 38) of >>Solaris Dynamic Tracing Guide, using global variable instead >>of using cacheable variable is not recommanded. So, my >>question is: >> >>How can I use cacheable variable to get the same outcome? >> >>THX. >> >>-- >>************************************************ >>* 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 * >>************************************************ >> >>_______________________________________________ >>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 * ************************************************
On Tue, Nov 08, 2005 at 07:00:30AM -0800, CHIAN-PHON LIN wrote:> > Hm... I''m not sure you are going to be able to construct such a predicate. > > Is the enabled performance unacceptable? > > Yes, that is exact the reason especially when a short function is called > billions times. The probing overhead to function run time ratio becomes > too high.You could key the associative array by the ''id'' variable which might give you a bit of an improvement since you wouldn''t have to perform the string hash each time.> Other questions: Is there way to set every traced[probefunc] to zero at > END{}? If not, what is the side effect to system memory? Are we going > to have memory leak?When your DTrace consumer stops (when END is called), all variable state is thrown out so you don''t have to worry about memory leaks or any other lasting impact to the system. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, Adam Leventhal wrote On 11/08/05 08:53,:> On Tue, Nov 08, 2005 at 07:00:30AM -0800, CHIAN-PHON LIN wrote: > >>>Hm... I''m not sure you are going to be able to construct such a predicate. >>>Is the enabled performance unacceptable? >> >>Yes, that is exact the reason especially when a short function is called >>billions times. The probing overhead to function run time ratio becomes >>too high. > > > You could key the associative array by the ''id'' variable which might give > you a bit of an improvement since you wouldn''t have to perform the string > hash each time.I am also interested in the caller (i.e. where it is calling from) and modified the d-program further: pid$target:xyz::entry /!traced[id, caller]/ { traced[id, caller] = 1; } Does traced[id, caller] have better performance than traced[probefunc, caller]? Or, no difference? THX.>>Other questions: Is there way to set every traced[probefunc] to zero at >>END{}? If not, what is the side effect to system memory? Are we going >>to have memory leak? > > > When your DTrace consumer stops (when END is called), all variable state > is thrown out so you don''t have to worry about memory leaks or any other > lasting impact to the system. > > Adam >-- ************************************************ * 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 * ************************************************
> Does traced[id, caller] have better performance than > traced[probefunc, caller]? Or, no difference?The improvement should be observable. I tried a little experiment and saw about 8-10%. Adam On Wed, Nov 09, 2005 at 08:54:31AM -0800, CHIAN-PHON LIN wrote:> Adam, > > Adam Leventhal wrote On 11/08/05 08:53,: > > On Tue, Nov 08, 2005 at 07:00:30AM -0800, CHIAN-PHON LIN wrote: > > > >>>Hm... I''m not sure you are going to be able to construct such a predicate. > >>>Is the enabled performance unacceptable? > >> > >>Yes, that is exact the reason especially when a short function is called > >>billions times. The probing overhead to function run time ratio becomes > >>too high. > > > > > > You could key the associative array by the ''id'' variable which might give > > you a bit of an improvement since you wouldn''t have to perform the string > > hash each time. > > I am also interested in the caller (i.e. where it is calling from) and > modified the d-program further: > > pid$target:xyz::entry > /!traced[id, caller]/ > { > traced[id, caller] = 1; > } > > Does traced[id, caller] have better performance than > traced[probefunc, caller]? Or, no difference? > > THX. > > >>Other questions: Is there way to set every traced[probefunc] to zero at > >>END{}? If not, what is the side effect to system memory? Are we going > >>to have memory leak? > > > > > > When your DTrace consumer stops (when END is called), all variable state > > is thrown out so you don''t have to worry about memory leaks or any other > > lasting impact to the system. > > > > Adam > > > > -- > ************************************************ > * 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 * > ************************************************-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl