From: Dipankar Sarma <dipankar@in.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Paul E McKenney <paulmck@us.ibm.com>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] RCU: various merge candidates
Date: Mon, 28 Aug 2006 22:13:45 +0530 [thread overview]
Message-ID: <20060828164345.GH3325@in.ibm.com> (raw)
In-Reply-To: <1156782789.3034.216.camel@laptopd505.fenrus.org>
On Mon, Aug 28, 2006 at 06:33:09PM +0200, Arjan van de Ven wrote:
> On Mon, 2006-08-28 at 21:59 +0530, Dipankar Sarma wrote:
> > On Mon, Aug 28, 2006 at 06:15:48PM +0200, Arjan van de Ven wrote:
> > > On Mon, 2006-08-28 at 21:38 +0530, Dipankar Sarma wrote:
> > Hi Arjan,
> >
> > See this for a background - http://lwn.net/Articles/129511/
> >
> > Primarily, rcupreempt allows read-side critical sections to
> > be preempted unline classic RCU currently in mainline. It is
> > also a bit more aggressive in terms of grace periods by counting
> > the number of readers as opposed to periodic checks in classic
> > RCU.
> >
>
> hi,
>
> thanks for the explenation, this for sure explains one half of the
> equation; the other half is ... "why do we not always want this"?
It comes with read-side overheads for keeping track
of critical sections and we need to carefully
check its impact on performance over a more wide variety
of workload before deciding to switch the default.
See table 2 of page 10 in this paper -
http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
Thanks
Dipankar
next prev parent reply other threads:[~2006-08-28 16:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-28 16:08 [PATCH 0/4] RCU: various merge candidates Dipankar Sarma
2006-08-28 16:10 ` [PATCH 1/4] RCU: split classic rcu Dipankar Sarma
2006-08-31 1:12 ` Paul E. McKenney
2006-08-28 16:11 ` [PATCH 2/4] RCU: use a separate softirq Dipankar Sarma
2006-08-31 1:13 ` Paul E. McKenney
2006-08-28 16:12 ` [PATCH 3/4] RCU: preemptible RCU implementation Dipankar Sarma
2006-08-28 20:46 ` Christoph Hellwig
2006-08-29 1:33 ` Dipankar Sarma
2006-08-28 16:13 ` [PATCH 4/4] RCU: clean up RCU trace Dipankar Sarma
2006-08-28 16:15 ` [PATCH 0/4] RCU: various merge candidates Arjan van de Ven
2006-08-28 16:29 ` Dipankar Sarma
2006-08-28 16:33 ` Arjan van de Ven
2006-08-28 16:43 ` Dipankar Sarma [this message]
2006-08-28 19:06 ` Andrew Morton
2006-08-28 19:16 ` Dipankar Sarma
2006-08-28 19:40 ` Andrew Morton
2006-08-29 0:23 ` Dipankar Sarma
2006-08-29 0:28 ` Andrew Morton
2006-08-30 0:40 ` Paul E. McKenney
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=20060828164345.GH3325@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.com \
/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.