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

[Santosh Shukla <sshukla at mvista dot com>]

Also, Curious to know any benchmarking tool to test on performance
impact of the port? any sugegstion. Thanks.

On Mon, Sep 15, 2014 at 10:18 PM, Santosh Shukla <sshukla@mvista.com> wrote:
> On Mon, Sep 15, 2014 at 10:15 PM, Josh Stone <jistone@redhat.com> wrote:
>> On 09/15/2014 09:35 AM, Santosh Shukla wrote:
>>> On Mon, Sep 15, 2014 at 9:52 PM, Josh Stone <jistone@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 09/15/2014 08:41 AM, Santosh Shukla wrote:
>>>>> first wanted to get raw_locking specific to get into stap.
>>>>
>>>> One ugly aspect of this is that we try to maintain compatibility with
>>>> older platforms too.  It looks like raw_spin_lock didn't come into the
>>>> kernel until 2.6.33, which doesn't even cover RHEL6.  If possible we try
>>>> to keep things running all the way back to RHEL4 (though see my earlier
>>>> RFC about dropping that).
>>>
>>> Right, I did saw your early RFC and noticed few important stuff
>>> missing so to keep compatibility per se  .i..e.. some type of locking
>>> function helper api which could ably switch between PREEMPT and
>>> non-PREEMPT kernel.
>>>
>>>
>>> In v2 version which I am working on [inspired by Corey suggestion] to
>>> add below type of locking facility, pseudo code look like below
>>>
>>> #ifdef CONFIG_PREEMPT_RT
>>> static inline my_readlock(raw_spinlock_t *lock) { raw_spin_lock(&lock); }
>>> static inline my_readunlock(raw_spinlock_t *lock) {
>>> raw_spin_unlock(&lock); }
>>> static inline my_writelock(raw_spinlock_t *lock) { raw_spin_lock(&lock); }
>>> static inline my_writeunlock(raw_spinlock_t *lock) {
>>> raw_spin_unlock(&lock); }
>>> #else
>>> static inline my_readlock(rwlock_t *lock) {read_lock(&lock); }
>>> static inline my_readunlock(rwlock_t *lock) {read_unlock(&lock); }
>>> static inline my_writelock(rwlock_t *lock) { write_lock(&lock); }
>>> static inline my_writeunlock(rwlock_t *lock) {write_unlock(&lock); }
>>> #endif
>>
>> Ok, if the raw interfaces have always existed with PREEMPT_RT, then this
>> should be fine.
>>
> Yes they are.
>
>> I suggest "stp_" rather than "my_" though.  </bikeshed>
>
> Yup.