Re: [SYSTEMTAP/PATCH 0/4] RT aware systemtap patch set

[Santosh Shukla <sshukla at mvista dot com>]

On Mon, Sep 15, 2014 at 7:43 PM, David Smith <dsmith@redhat.com> wrote:
> On 09/15/2014 05:17 AM, Santosh Shukla wrote:
>> Ping!
>>
>> do we care about making stap -rt aware. Just an fyi that I revisited
>> my patch specially 2nd patch and found some serious improvement to be
>> done.. RCU use to replace rd/wr lock just not right, So I am spinning
>> the patch series. Also I am thinking to come up with locking helper
>> function API on raw_locking vs existing spin lock so to avoid
>> cluttering the code.
>
> Santosh,
>
> Sorry about not responding sooner. Making systemtap work better on -rt
> kernels would be nice, if the changes aren't too disruptive. I meant to
> find the -rt kernel and test your patches last week but I ended up not
> finding the time. Luckily for me you've got a 2nd patch set coming...
>
> I'll try to review the 2nd patch set when you get it finished. Here's a
> question I've got, do you think the -rt patches will cause any
> performance changes (positive or negative) on the regular kernel?
>

Thanks for responding -:).

I don't thing so as my patch set intent to provide -rt flavor locks
only so that when I run my stap example scripts under stress/load such
as make -jX.. It should work gracefully.. applicable to virtualization
hooks in stap too.

However I do have some serious comment on choice of locking used in
general in systemtap. Specially reader and writer lock used to protect
hlist, I strongly believe that use of RCU lock would be a better fit..
As per my reading systemtap's some modules like stp_utrace.c and
others.. they do operations like add, search/traverse[reading] then
remove.. Use of rcu lock with rcu variant hlist api would greatly
increase performance overall. As RCU by design immune to deadlock,
prio inversion right?

Reason for raising this question motivated by my 2nd patch which look
dirty though and hardly make use of RCU feature like grace period
elpse then call free list. But my reading in existing design module
such as task_map_finder.c is - It uses two list i.e.. one
__stp_tf_map_list used by reader func and adder func ,although remover
func does remove reader entry from __stp_tf_map_entry contruct and
then updates free list all the time to populate new map entry for next
iteration of adder function. Which is awkward as if sticking with one
list and letting RCU to protect / control reader and writer context
would greatly improve thing.. And in essence It will save some cycles
like _irqsave/restore etc..

Keeping above design limitation in mind, I choose to drop RCU method
to replace reader/writer lock for now and use them in coming further
patches.. first wanted to get raw_locking specific to get into stap.

Also curious to know - How to measure stap performance? is there any
tool or any specific steps to follow. Thanks.


> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)