All of lore.kernel.org
 help / color / mirror / Atom feed
From: Priyanka Gupta Jain <p.priyankagupta@gmail.com>
To: linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: looking for something like raw_rwlock_t or some optimization in rwlock_t in Linux 3.0
Date: Mon, 7 May 2012 10:19:59 +0530	[thread overview]
Message-ID: <CACpc7petSnyR4qwE+F_b-OcdXc9+c5RRrX_u0TiLZnzy2eDWOg@mail.gmail.com> (raw)

hi,

I would really appreciate if someone can help in finding an
alternative to rwlock_t.
I want one particular rw_lock to behave as in native linux not as
mutex of if there is any other optimization that I can do in that
rwlock or in general to all rwlocks as well.
This is required to boost the performance in case of multicore systems

Regards
Priyanka

On Thu, May 3, 2012 at 4:21 PM, Priyanka Gupta Jain
<p.priyankagupta@gmail.com> wrote:
> hi,
>
> I am still looking for the answer to the below. I will be highly
> thankful if someone can help in it.
>
> Is there something like raw_rwlock_t in Linux3.0 which can make the
> rwlock_t behave in similar way as in RT disable.
> This might help me in solving throughput issue in 8-core system due to
> read/write lock.
>
> Regards
> Priyanka
>
> On Wed, Apr 11, 2012 at 10:32 AM, Priyanka Gupta Jain
> <p.priyankagupta@gmail.com> wrote:
>> hi,
>>
>> I am observing drastic throughput reduction in IPSEC traffic with RT
>> enable and disable. Throughput drops from 576 fps to 69fps.
>> Please note that I am using 8-core system with Linux 3.0.26-rt45 (SMP)
>> running on it.
>>
>> With the help of ftrace (function graph) in case of RT enable, I could
>> see xfrm_policy_get_afinfo() and xfrm_policy_put_afinfo taking time()
>> sometimes taking time arounnd 1.43 msec and  1.351msec respectively.
>>
>> As in my test case, I was writing afinfo_policy before starting the
>> traffic without chainging in between, it was safe to remove read lock
>> and read unlock from xfrm_policy_get_afinfo() and
>> xfrm_policy_put_afinfo() functions. With the read lock/unlock removed,
>> I could see throughput rising from 69fps to 133fps.
>>
>> Now I need your suggestions for the below:
>> 1) Removing the read lock is not a good way as the system might now
>> work properly in the real set-up. But with the change of read-write
>> lock to mutex by PREEMPT_RT patch, I am not able to fully utilize
>> 8-core system leading to drastic reduction in throughput. So what is
>> the suggested way to tackle this situation.
>>
>> 2) Even after removing the read lock, I could see the difference in
>> IPSEC thoughput in RT enable (133fps) and RT disable (576fps). Any
>> suggestion?.
>>
>>
>> Regards
>> Priyanka
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2012-05-07  4:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07  4:49 Priyanka Gupta Jain [this message]
2012-05-08 15:17 ` looking for something like raw_rwlock_t or some optimization in rwlock_t in Linux 3.0 Steven Rostedt
2012-05-16  1:36 ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACpc7petSnyR4qwE+F_b-OcdXc9+c5RRrX_u0TiLZnzy2eDWOg@mail.gmail.com \
    --to=p.priyankagupta@gmail.com \
    --cc=linux-rt-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.