All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Jim Houston <jim.houston@comcast.net>
Cc: linux-kernel@vger.kernel.org,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Manfred Spraul <manfred@colorfullife.com>,
	Andrew Morton <akpm@osdl.org>,
	William Lee Irwin III <wli@holomorphy.com>,
	Jack Steiner <steiner@sgi.com>,
	Jesse Barnes <jbarnes@engr.sgi.com>,
	rusty@rustcorp.com.au
Subject: Re: [RFC&PATCH] Alternative RCU implementation
Date: Mon, 30 Aug 2004 11:52:23 -0700	[thread overview]
Message-ID: <20040830185223.GF1243@us.ibm.com> (raw)
In-Reply-To: <1093886020.984.238.camel@new.localdomain>

On Mon, Aug 30, 2004 at 01:13:41PM -0400, Jim Houston wrote:
> I know that I'm questioning one of your design goals for RCU by adding
> overhead to the read-side.  I have read everything I could find on RCU.
> My belief is that the cost of the xchg() instruction is small 
> compared to the cache benifit of freeing memory more quickly.
> I think it's more interesting to look at the impact of the xchg() at the
> level of an entire system call.  Adding 30 nanoseconds to a open/close
> path that tasks 3 microseconds seems reasonable.  It is hard to measure
> the benefit of reusing the a dcache entry more quickly.

Hello, Jim,

The other thing to keep in mind is that reducing the grace-period
duration increases the per-access overhead, since each grace period
incurs a cost.  So there is a balance that needs to be struck between
overflowing memory with a too-long grace period and incurring too
much overhead with a too-short grace period.

How does the rest of the kernel work with all interrupts to
a particular CPU shut off?  For example, how do you timeslice?

						Thanx, Paul

PS.  My concerns with some aspects of your design aside, your
     getting a significant change to the RCU infrastructure to
     work reasonably well is quite impressive!

  parent reply	other threads:[~2004-08-30 19:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3brgwgi30.fsf@new.localdomain>
2004-08-30  0:43 ` [RFC&PATCH] Alternative RCU implementation Paul E. McKenney
2004-08-30 17:13   ` Jim Houston
2004-08-30 17:38     ` Dipankar Sarma
2004-09-01  0:10       ` Jim Houston
2004-09-01  0:57         ` Paul E. McKenney
2004-08-30 18:52     ` Paul E. McKenney [this message]
2004-08-31  3:22       ` Jim Houston
2004-09-01  3:53         ` Paul E. McKenney
2004-09-01 13:02           ` Jim Houston
2004-09-02 16:38             ` Paul E. McKenney
2004-09-02 18:54               ` Jim Houston
2004-09-02 21:20                 ` Manfred Spraul
2004-09-03  1:19                   ` Jim Houston

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=20040830185223.GF1243@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=jbarnes@engr.sgi.com \
    --cc=jim.houston@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=rusty@rustcorp.com.au \
    --cc=steiner@sgi.com \
    --cc=wli@holomorphy.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.