LKML Archive on
help / color / mirror / Atom feed
From: Dipankar Sarma <>
To: Andrew Morton <>
Cc: Ingo Molnar <>,
	Paul E McKenney <>,
Subject: Re: [mm PATCH 4/6] RCU: preemptible RCU
Date: Sat, 27 Jan 2007 02:30:17 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jan 23, 2007 at 04:32:59PM -0800, Andrew Morton wrote:
> On Tue, 16 Jan 2007 00:58:58 +0530
> Dipankar Sarma <> wrote:
> > This patch implements a new version of RCU which allows its read-side
> > critical sections to be preempted.
> Why is it selectable if CONFIG_PREEMPT=n?

It would probably make sense to make CONFIG_RCU_PREEMPT dependent
on CONFIG_PREEMPT. I kept it independent because I wanted to
test rcupreempt as an equivalent RCU implementation not just
for its "preemptibility".

> > It uses a set of counter pairs
> > to keep track of the read-side critical sections and flips them
> > when all tasks exit read-side critical section. The details
> > of this implementation can be found in this paper -
> >
> >
> >
> > This patch was developed as a part of the -rt kernel
> > development and meant to provide better latencies when
> > read-side critical sections of RCU don't disable preemption.
> Does it succeed in that attempt?  Thus far you've given no reason for
> merging this code..
> This is a pile of tricky new core kernel code for us to test, maintain,
> understand, debug, etc.  It needs to provide a substantial benefit.  Does
> it?

I am working to compare some latency numbers between different
implementations. I will have them out soon.

> > As a consequence of keeping track of RCU readers, the readers
> > have a slight overhead (optimizations in the paper).
> > This implementation co-exists with the "classic" RCU
> > implementations and can be switched to at compiler.
> That's yet another question we need to ask people when their kernel dies,
> and yet another deviation between the kernels which we all test, causing
> more dilution of testing efforts.  It would be much better if we could
> remove classic RCU.  You say this would incur extra cost, but the magnitude
> of that cost is not clear.  Please help us make that decision.

See the Table 2, page 10 of the paper mentioned above. There is a
~100ns cost per read-side critical section involved in the preemptible
version of RCU at the moment. Until, we are sure that we don't have
an impact on common workloads, we need to keep the "classic" 
implementation around.


  reply	other threads:[~2007-01-26 21:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15 19:19 [mm PATCH] RCU: various patches Dipankar Sarma
2007-01-15 19:21 ` [mm PATCH 1/6] RCU: split classic rcu Dipankar Sarma
2007-01-16 17:49   ` Paul E. McKenney
2007-01-15 19:22 ` [mm PATCH 2/6] RCU: softirq for RCU Dipankar Sarma
2007-01-16 17:49   ` Paul E. McKenney
2007-01-15 19:24 ` [mm PATCH 3/6] RCU: Fix barriers Dipankar Sarma
2007-01-16 17:53   ` Paul E. McKenney
2007-01-15 19:28 ` [mm PATCH 4/6] RCU: preemptible RCU Dipankar Sarma
2007-01-24  0:32   ` Andrew Morton
2007-01-26 21:00     ` Dipankar Sarma [this message]
2007-01-26 21:25       ` Andrew Morton
2007-01-24  0:38   ` Andrew Morton
2007-01-15 19:30 ` [mm PATCH 5/6] RCU: debug trace for RCU Dipankar Sarma
2007-01-15 19:31 ` [mm PATCH 6/6] RCU: trivial fixes Dipankar Sarma
2007-01-16 17:56   ` 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:

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

  git send-email \ \ \ \ \ \ \
    --subject='Re: [mm PATCH 4/6] RCU: preemptible RCU' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).