This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Re: [RFC PATCH 0/2] Perf support to SDT markers
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Hemant <hkshaw at linux dot vnet dot ibm dot com>
- Cc: Mark Wielaard <mjw at redhat dot com>, Namhyung Kim <namhyung at kernel dot org>, Ingo Molnar <mingo at kernel dot org>, linux-kernel at vger dot kernel dot org, srikar at linux dot vnet dot ibm dot com, peterz at infradead dot org, oleg at redhat dot com, mingo at redhat dot com, anton at redhat dot com, systemtap at sourceware dot org
- Date: Thu, 05 Sep 2013 13:59:51 +0900
- Subject: Re: Re: [RFC PATCH 0/2] Perf support to SDT markers
- Authentication-results: sourceware.org; auth=none
- References: <20130903072944 dot 4793 dot 93584 dot stgit at hemant-fedora> <20130903082503 dot GA20732 at gmail dot com> <5225A937 dot 2050507 at hitachi dot com> <5225E2C5 dot 3080001 at linux dot vnet dot ibm dot com> <87a9jtt72j dot fsf at sejong dot aot dot lge dot com> <1378283148 dot 4321 dot 16 dot camel at bordewijk dot wildebeest dot org> <5226F1B6 dot 3000801 at hitachi dot com> <5227770E dot 3060106 at linux dot vnet dot ibm dot com>
(2013/09/05 3:08), Hemant wrote:
> On 09/04/2013 02:09 PM, Masami Hiramatsu wrote:
>> (2013/09/04 17:25), Mark Wielaard wrote:
>>> On Wed, 2013-09-04 at 15:49 +0900, Namhyung Kim wrote:
>>>> On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote:
>>>>> On 09/03/2013 02:47 PM, Masami Hiramatsu wrote:
>>>>>> Indeed, and also I'd like to know what versions of SDT this support,
>>>>>> and where we can see the technical document of that. As far as I know,
>>>>>> the previous(?) SDT implementation also involves ugly semaphores.
>>>>>> Have that already gone?
>>>> It seems it's not. I see the SDT v3 document still mentions semaphores.
>>> It mentions them, but should normally not be used. They are there for
>>> dtrace (source) compatibility. And you don't have to use them.
>>>
>>> Since normally a SDT probe marker is just a NOP it doesn't have any
>>> overhead. But if you want to add complicated arguments that you would
>>> normally not generate in your code, then you might want to add a
>>> semaphore. That way you can have probes with a bit more overhead that
>>> still have zero overhead when not being probed.
>>>
>>> Note that if you use the normal DTRACE_PROBE macros no semaphore will be
>>> inserted. And you can opt to not support probes that have a semaphore in
>>> perf if you think that is easier (just check the semaphore link-time
>>> address for the probe, it should normally be zero). Just warn: "No way I
>>> am going to probe something that might have a little extra overhead! I
>>> am no debugger..." :)
>> OK, I see. And in that case, we'd better filter out the markers which
>> use a semaphore when list it up, since we can not enable it.
>>
>> Thank you,
>>
>>
>
> But isn't it a better idea to handle semaphores, because there can be
> many important markers using semaphores and people may still want to
> probe on them?
Yeah, I didn't mean that all markers with semaphore keep disabled forever.
Instead, I meant that should not be for the first step. And in the first step,
we'd better support only markers without semaphore, and to avoid confusing
users, it should list only probable markers at this point.
I agree that we need to continue discussing how we handle those semaphores.
Thank you!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com