linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>,
	dipankar@in.ibm.com, shemminger@osdl.org, akpm@osdl.org,
	torvalds@osdl.org, rusty@au1.ibm.com, tgall@us.ibm.com,
	jim.houston@comcast.net, manfred@colorfullife.com, gh@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: Real-Time Preemption and RCU
Date: Fri, 18 Mar 2005 18:19:29 +0100	[thread overview]
Message-ID: <20050318171929.GC30310@elte.hu> (raw)
In-Reply-To: <Pine.OSF.4.05.10503181336310.2466-100000@da410.phys.au.dk>


* Esben Nielsen <simlo@phys.au.dk> wrote:

> Why can should there only be one RCU-reader per CPU at each given
> instance? Even on a real-time UP system it would be very helpfull to
> have RCU areas to be enterable by several tasks as once. It would
> perform better, both wrt. latencies and throughput: With the above
> implementation an high priority task entering an RCU area will have to
> boost the current RCU reader, make a task switch until that one
> finishes and makes yet another task switch. to get back to the high
> priority task. With an RCU implementation which can take n RCU readers
> per CPU there is no such problem.

correct, for RCU we could allow multiple readers per lock, because the
'blocking' side of RCU (callback processing) is never (supposed to be)
in any latency path.

except if someone wants to make RCU callback processing deterministic at
some point. (e.g. for memory management reasons.)

clearly the simplest solution is to go with the single-reader locks for
now - a separate experiment could be done with a new type of rwlock that
can only be used by the RCU code. (I'm not quite sure whether we could
guarantee a minimum rate of RCU callback processing under such a scheme
though. It's an eventual memory DoS otherwise.)

	Ingo

  reply	other threads:[~2005-03-18 17:20 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18  0:20 Real-Time Preemption and RCU Paul E. McKenney
2005-03-18  7:49 ` Ingo Molnar
2005-03-18 16:43   ` Paul E. McKenney
2005-03-18 17:11     ` Ingo Molnar
2005-03-18 17:29       ` Paul E. McKenney
2005-03-18 20:35       ` Paul E. McKenney
2005-03-18 22:22         ` Paul E. McKenney
2005-03-19  0:48           ` Paul E. McKenney
2005-03-18  8:44 ` Ingo Molnar
2005-03-18  9:04 ` Ingo Molnar
2005-03-18  9:38   ` Ingo Molnar
2005-03-18  9:13 ` Ingo Molnar
2005-03-18  9:28   ` Ingo Molnar
2005-03-18  9:53     ` Ingo Molnar
2005-03-18 15:33       ` Paul E. McKenney
2005-03-19  5:03     ` Manfred Spraul
2005-03-19 16:26       ` Ingo Molnar
2005-03-20  6:36         ` Manfred Spraul
2005-03-20  9:25           ` Thomas Gleixner
2005-03-20 16:57             ` Manfred Spraul
2005-03-20 21:38               ` Bill Huey
2005-03-20 21:59                 ` Bill Huey
2005-03-18 10:03 ` Ingo Molnar
2005-03-18 11:30   ` Ingo Molnar
2005-03-18 16:48     ` Esben Nielsen
2005-03-18 17:19       ` Ingo Molnar [this message]
2005-03-20 13:29         ` Esben Nielsen
2005-03-20 22:38           ` Paul E. McKenney
2005-03-20 23:23             ` Esben Nielsen
2005-03-22  5:53               ` Paul E. McKenney
2005-03-22  8:55                 ` Esben Nielsen
2005-03-22  9:20                   ` Ingo Molnar
2005-03-22 10:19                     ` Esben Nielsen
2005-03-23  5:40                   ` Paul E. McKenney
2005-03-23 11:44                     ` Esben Nielsen
2005-03-24  7:02                       ` Paul E. McKenney
2005-03-22 10:56           ` Ingo Molnar
2005-03-22 11:39             ` Esben Nielsen
2005-03-22 13:10               ` Ingo Molnar
2005-03-22 15:08                 ` Esben Nielsen
2005-03-18 15:48   ` Paul E. McKenney
2005-03-18 11:38 ` Ingo Molnar
2005-03-18 12:56 ` Bill Huey
2005-03-18 13:17   ` Bill Huey
2005-03-18 15:57     ` Paul E. McKenney
2005-03-18 16:02     ` Ingo Molnar
2005-03-18 16:55       ` Esben Nielsen
2005-03-22 10:04         ` Bill Huey
2005-03-22 10:17           ` Bill Huey
2005-03-22 10:34             ` Bill Huey
2005-03-22 10:38           ` Esben Nielsen
2005-03-18 22:26       ` Herbert Xu
2005-03-19 16:31         ` Ingo Molnar
2005-03-20  8:01           ` Kyle Moffett
2005-03-22  8:08             ` Ingo Molnar
2005-03-18 15:54   ` Paul E. McKenney
2005-03-18 15:58     ` Ingo Molnar
2009-06-11 22:57 real-time preemption " James Huang

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=20050318171929.GC30310@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=gh@us.ibm.com \
    --cc=jim.houston@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=paulmck@us.ibm.com \
    --cc=rusty@au1.ibm.com \
    --cc=shemminger@osdl.org \
    --cc=simlo@phys.au.dk \
    --cc=tgall@us.ibm.com \
    --cc=torvalds@osdl.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 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).