Hello dtrace-discuss,
With a bug id
6495013 Loops and recursion in metaslab_ff_alloc can kill
performance, even on a pool with lots of free data
There''s associated D script below.
What''s the point setting self->in_metaslab in a BEGIN probe?
I''m not talking about setting it to 0 as this is not necessary but
rather about self-> variables in BEGIN probe. I guess it has no
rather about self-> predictable meaning, right?
#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN
{
self->in_metaslab = 0;
}
fbt::metaslab_ff_alloc:entry
/self->in_metaslab == 0/
{
self->in_metaslab = 1;
self->loopcount = 0;
}
fbt::avl_walk:entry
/self->in_metaslab/
{
self->loopcount++;
}
fbt::metaslab_ff_alloc:return
/self->in_metaslab/
{
self->in_metaslab = 0;
@loops["Loops count"] = quantize(self->loopcount);
self->loopcount = 0;
}
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Robert Milkowski wrote: Seems pointless and meaningless to me. The BEGIN-time thread surely is not relevant for most of the rest of the script, and of course the variable has default value 0 anyway...> What''s the point setting self->in_metaslab in a BEGIN probe? > I''m not talking about setting it to 0 as this is not necessary but > rather about self-> variables in BEGIN probe. I guess it has no > rather about self-> predictable meaning, right? > > > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > BEGIN > { > self->in_metaslab = 0; > }
----- Original Message ----- From: Robert Milkowski <rmilkowski at task.gda.pl> Date: Wednesday, February 14, 2007 11:02 am Subject: [dtrace-discuss] self-> in BEGIN probe To: dtrace-discuss at opensolaris.org> Hello dtrace-discuss, > > > With a bug id > > 6495013 Loops and recursion in metaslab_ff_alloc can kill > performance, even on a pool with lots of free data > > There''s associated D script below. > > What''s the point setting self->in_metaslab in a BEGIN probe? > I''m not talking about setting it to 0 as this is not necessary but > rather about self-> variables in BEGIN probe. I guess it has no > rather about self-> predictable meaning, right? >I think it is used as a forward declaration. The predicate on the first clause would cause the script not to run since slef->in_metaslab would be undefined at that point. The proper way to do the forward declaration would be something like: #!/usr/sbin/dtrace -s #pragma D option quiet self int in_metaslab; fbt::metaslab_ff_alloc:entry /self->in_metaslab == 0/ { self->in_metaslab = 1; self->loopcount = 0; }
Hello Menno, Wednesday, February 14, 2007, 11:30:16 AM, you wrote: ML> ----- Original Message ----- ML> From: Robert Milkowski <rmilkowski at task.gda.pl> ML> Date: Wednesday, February 14, 2007 11:02 am ML> Subject: [dtrace-discuss] self-> in BEGIN probe ML> To: dtrace-discuss at opensolaris.org>> Hello dtrace-discuss, >> >> >> With a bug id >> >> 6495013 Loops and recursion in metaslab_ff_alloc can kill >> performance, even on a pool with lots of free data >> >> There''s associated D script below. >> >> What''s the point setting self->in_metaslab in a BEGIN probe? >> I''m not talking about setting it to 0 as this is not necessary but >> rather about self-> variables in BEGIN probe. I guess it has no >> rather about self-> predictable meaning, right? >>ML> I think it is used as a forward declaration. The predicate on the ML> first clause would cause the script not to run since ML> slef->in_metaslab would be undefined at that point. The proper way ML> to do the forward declaration would be something like: Actually it will work without declaration on BEGIN only you are checking for zero (or non zero). ML> #!/usr/sbin/dtrace -s ML> #pragma D option quiet ML> self int in_metaslab; That''s interesting - I didn''t know one can do it for self-> variables in that way. -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com