Re: Writing tapset functions for multiple versions

[Josh Stone <jistone at redhat dot com>]

On 07/20/2016 09:23 AM, Felix Lu wrote:
> 
>>>> A global integer instead of the string comparison could be set if you
>>>> are worried about the overhead. In the example above, tid() could be
>>>> saved in the probe alias body as a private global which would be
>>>> sufficient
>>>> for identifying the desired function.
>>>
>>> I'm not quite sure how saving tid() in a private global would work if
>>> you are probing more than one thread at a time. Or did I misunderstand
>>> your idea and your global is an array? If the private global is an
>>> array, now we've got 2 private global arrays (1 for version1.stp and 1
>>> for version2.stp).
>>
>> A global scalar should suffice in this case. All we want is for the function
>> f in version1.stp to be called when version1/process is executed and likewise
>> for version2. The probe alias body in the above example would update the
>> saved
>> tid() every time it's hit.

A scalar implies that there is only one such target at a given time.
Furthermore, if you use tid() that implies you only care about one
particular thread, where at least pid() would cover a whole process.

These may be acceptable choices for a user's script, but our tapsets
should be prepared to run with many process targets at once.

> Using a saved global may not be more efficient than the pp() regex comparison.
> Systemtap global variables are locked upon probe handler entry. By updating
> the saved tid(), an exclusive lock must be obtained. The overhead from this
> may be greater than the string matching.  

True, although if it's already locking any other variables, then this
particular lock might be overshadowed and always succeed anyway, which
is cheap.  (There's a bug to collapse these, PR10741.)


We can make lots of speculations, but if you're really concerned about
performance, you should directly measure and compare methods.