[illumos-Developer] Reaping enablings on defunct providers

Adam Leventhal ahl at delphix.com
Wed Jul 13 09:32:30 PDT 2011


Hey Bryan,

Cool; looks good to me.

Adam

On Tue, Jul 12, 2011 at 10:44 PM, Bryan Cantrill <bryan at joyent.com> wrote:
> On Tue, Jul 12, 2011 at 5:25 PM, Adam Leventhal <ahl at delphix.com> wrote:
>>>> I actually meant a negative test case.
>>>
>>> As I imagine you saw, there's already one there that uses speculative
>>> tracing and verifies that enablings are not reaped:
>>>
>>>  usr/src/cmd/dtrace/test/tst/common/usdt/tst.noreap.ksh
>>>
>>> Having a test that uses ring buffering is certainly possible, it's
>>> just a more complicated test to write. (I'm currently cheating a bit
>>> by using one enabling to kick off another.)  But I'm happy to add it
>>> if you'd like to see it...
>>
>> Yes. I saw that test case. It was just a suggestion to exercise the
>> other path in your code, but it's up to you.
>
> I added that test and integrated into our repo; patch is attached.
>
>>>> Would that be worth a one- or two-line comment?
>>>
>>> There's already the comment that it's padded out to avoid false
>>> sharing; does it merit more than that?
>>
>> I guess that's sufficient, but I needed to remind myself that these
>> were per-CPU data structures. Your call.
>
> I'm going to leave that one as it is; in addition to the comment next
> to the member, the block comment immediately above the structure also
> spells that out:
>
> /*
>  * DTrace Buffers
>  *
>  * Principal buffers, aggregation buffers, and speculative buffers are all
>  * managed with the dtrace_buffer structure.  By default, this structure
>  * includes twin data buffers -- dtb_tomax and dtb_xamot -- that serve as the
>  * active and passive buffers, respectively.  For speculative buffers,
>  * dtb_xamot will be NULL; for "ring" and "fill" buffers, dtb_xamot will point
>  * to a scratch buffer.  For all buffer types, the dtrace_buffer structure is
>  * always allocated on a per-CPU basis; a single dtrace_buffer structure is
>  * never shared among CPUs.  (That is, there is never true sharing of the
>  * dtrace_buffer structure; to prevent false sharing of the structure, it must
>  * always be aligned to the coherence granularity -- generally 64 bytes.)
>  *
>  ...
>
> Let me know if you have any other comments; otherwise, I'll assume
> that you've moved on to reviewing unprivileged tick probes. ;)
>
>        - Bryan
>



-- 
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl

275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com



More information about the Developer mailing list