[DTrace-devel] [PATCH 3/4] Drop counters support

Kris Van Hees kris.van.hees at oracle.com
Thu May 11 03:04:01 UTC 2023


On Wed, May 10, 2023 at 10:52:12PM -0400, Eugene Loh via DTrace-devel wrote:
> The R-b is still good, but...
> 
> On 5/9/23 03:19, Kris Van Hees via DTrace-devel wrote:
> > diff --git a/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.d b/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.d
> > -#pragma D option bufsize=512
> > +#pragma D option bufsize=3k
> > diff --git a/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.end.d b/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.end.d
> > -#pragma D option bufsize=512
> > +#pragma D option bufsize=3k
> 
> Saying bufsize=3k does not seem fair when...

What do you mean with "fair"?  The settings ensure that we can trace a certain
amount of data, but not all (so that we get a drop).  Yes, the implementation
is currently needing to enforce a buffer size that is a whole multiple of the
pagesize, and that will indeed be reported in the test output.  Which means
that if the required buffer size changes we will get an expected output
failure which is a good thing - it will explain why the test is not going to
report a drop.

But the values are chosen to ensure that we both have data reocrded *and* a
drop.

I deliberately chose the limit below the minimum (but large enough for the
test).

> > diff --git a/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.end.r b/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.end.r
> > +bufsize increased to 4096
> > diff --git a/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.r b/test/unittest/drops/drp.DTRACEDROP_PRINCIPAL.r
> > +bufsize increased to 4096
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel



More information about the DTrace-devel mailing list