This is the mail archive of the
mailing list for the systemtap project.
Re: [to-be-posted-soon] Multiple handlers per marker
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Mike Mason <mmlnx at us dot ibm dot com>
- Cc: ltt-dev at shafik dot org, linux-kernel at vger dot kernel dot org, systemtap at sources dot redhat dot com
- Date: Mon, 5 Nov 2007 18:17:35 -0500
- Subject: Re: [to-be-posted-soon] Multiple handlers per marker
- References: <472A345C.email@example.com> <20071101221530.GC19700@Krystal> <20071102033654.GA1301@Krystal> <20071104232442.GA32320@Krystal> <472F9D63.firstname.lastname@example.org>
* Mike Mason (email@example.com) wrote:
> Mathieu Desnoyers wrote:
>> * Mathieu Desnoyers (firstname.lastname@example.org) wrote:
>>> * Mathieu Desnoyers (email@example.com) wrote:
>>>> * Mike Mason (firstname.lastname@example.org) wrote:
>>>>> Hi Mathieu,
>>>>> Are you aware of any working being done to allow multiple handlers to
>>>>> be attached to a marker? Something like what kprobes allows. I've
>>>>> started to look into this and don't want to duplicate efforts.
>>>> Nope, but I know we will have to address this.
>>>> Something along the lines of walking an RCU list of function pointers,
>>>> calling them.
>>>> The only downside I see is that we will have to pass a va_list * instead
>>>> of real va args. The could make the marker site a little bit bigger and
>>>> will change the probe callback arguments.
>>>> What do you think about these ideas ?
>>>> If we can find a way to make the common case (only one probe connected)
>>>> _ultra_ fast, and yet architecture independent, that would be awesome. A
>>>> simple call is kind of hard to beat though.. So we may have to think
>>>> about a design with :
>>>> - One call at the marker site
>>>> - if 1 probe is installed :
>>>> - If the format string is empty, connect a probe without va args.
>>>> - If the format string is not empty, connect a "stage 1" probe that
>>>> the va args, starts/ends the va_list and calls _one_ function (let's
>>>> call it "stage 2" probe), that takes va_list as parameter.
>>>> - if more than 1 probe is installed :
>>>> - The stage 1 probe creates the va_list and passes it to each function
>>>> connected, iterated with an RCU list.
>>>> What do you think ?
>>> I'm working on an implementation.
>> It's ready for testing. Please grab
>> patch name :
> This patch alone doesn't apply cleanly at all on 2.6.24-rc1-git14. Are
> there other patches in this series I should apply first?
Yes, the following ones should suffice :
# instrumentation menu removal
Tell me if you still have rejects.
>> It still need to go through patchcheck.pl and some polishing, but it
>> seems to work fine for me with multiple probes (the sample marker,
>> sample probe and multiple instances of my lttng probes can
>> connect/disconnect without problem).
>> Currently, the "connect/disconnect" and "arm/disarm" operations are
>> separate. However, they could be merged. Any comment/preference on this?
>> Being separate, a probe provider can wait until the very last moment
>> before it activates its markers, with a minimalistic impact on the
>> system, but it is not such a strong argument.
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68