All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Esben Nielsen <simlo@phys.au.dk>,
	Rui Nuno Capela <rncbc@rncbc.org>, "K.R. Foley" <kr@cybsft.com>,
	Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>,
	mark_h_johnson@raytheon.com, Amit Shah <amit.shah@codito.com>,
	Karsten Wiese <annabellesgarden@yahoo.de>,
	Bill Huey <bhuey@lnxw.com>, Adam Heath <doogie@debian.org>,
	emann@mrv.com, Gunther Persoons <gunther_persoons@spymac.com>,
	linux-kernel@vger.kernel.org,
	Florian Schmidt <mista.tapas@gmx.net>,
	Lee Revell <rlrevell@joe-job.com>,
	Shane Shrybman <shrybman@aei.ca>,
	Thomas Gleixner <tglx@linutronix.de>,
	Michal Schmidt <xschmi00@stud.feec.vutbr.cz>
Subject: Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)
Date: Fri, 28 Jan 2005 16:28:02 +0100	[thread overview]
Message-ID: <20050128152802.GA15508@elte.hu> (raw)
In-Reply-To: <20050128115640.GP10843@holomorphy.com>


* William Lee Irwin III <wli@holomorphy.com> wrote:

> On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
> > no, it's not a big scalability problem. rwlocks are really a mistake -
> > if you want scalability and spinlocks/semaphores are not enough then one
> > should either use per-CPU locks or lockless structures. rwlocks/rwsems
> > will very unlikely help much.
> 
> I wouldn't be so sure about that. SGI is already implicitly relying on
> the parallel holding of rwsems for the lockless pagefaulting, and
> Oracle has been pushing on mapping->tree_lock becoming an rwlock for a
> while, both for large performance gains.

i dont really buy it. Any rwlock-type of locking causes global cacheline
bounces. It can make a positive scalability difference only if the
read-lock hold time is large, at which point RCU could likely have
significantly higher performance. There _may_ be an intermediate locking
pattern that is both long-held but has a higher mix of write-locking
where rwlocks/rwsems may have a performance advantage over RCU or
spinlocks.

Also this is about PREEMPT_RT, mainly aimed towards embedded systems,
and at most aimed towards small (dual-CPU) SMP systems, not the really
big systems.

But, the main argument wrt. PREEMPT_RT stands and is independent of any
scalability properties: rwlocks/rwsems have so bad deterministic
behavior that they are almost impossible to implement in a sane way.

	Ingo

  reply	other threads:[~2005-01-28 15:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-10 17:49 [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15 Mark_H_Johnson
2004-12-10 21:09 ` Ingo Molnar
2004-12-10 21:12 ` Ingo Molnar
2004-12-10 21:24 ` Ingo Molnar
2004-12-13  0:16 ` Fernando Lopez-Lezcano
2004-12-13  6:47   ` Ingo Molnar
2004-12-14  0:46     ` Fernando Lopez-Lezcano
2004-12-14  4:42       ` K.R. Foley
2004-12-14  8:47         ` Rui Nuno Capela
2004-12-14 11:35           ` Ingo Molnar
2004-12-27 14:35             ` Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) Esben Nielsen
2004-12-27 15:27               ` Steven Rostedt
2004-12-27 16:23                 ` Esben Nielsen
2004-12-27 16:39                   ` Steven Rostedt
2004-12-27 21:06                     ` Bill Huey
2004-12-27 21:48                       ` Valdis.Kletnieks
2004-12-28 21:59                       ` Lee Revell
2005-01-04 15:25                       ` Andrew McGregor
2004-12-28 21:42                   ` Lee Revell
2005-01-28  7:38               ` Ingo Molnar
2005-01-28 11:56                 ` William Lee Irwin III
2005-01-28 15:28                   ` Ingo Molnar [this message]
2005-01-28 15:55                     ` William Lee Irwin III
2005-01-28 16:16                       ` Ingo Molnar
2005-01-28 19:18                 ` Trond Myklebust
2005-01-28 19:45                   ` Ingo Molnar
2005-01-28 23:25                     ` Bill Huey
2005-01-28 21:13                   ` Lee Revell
2005-01-30 22:03                 ` Esben Nielsen
2005-01-30 23:59                   ` Kyle Moffett

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=20050128152802.GA15508@elte.hu \
    --to=mingo@elte.hu \
    --cc=amit.shah@codito.com \
    --cc=annabellesgarden@yahoo.de \
    --cc=bhuey@lnxw.com \
    --cc=doogie@debian.org \
    --cc=emann@mrv.com \
    --cc=gunther_persoons@spymac.com \
    --cc=kr@cybsft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark_h_johnson@raytheon.com \
    --cc=mista.tapas@gmx.net \
    --cc=nando@ccrma.stanford.edu \
    --cc=rlrevell@joe-job.com \
    --cc=rncbc@rncbc.org \
    --cc=shrybman@aei.ca \
    --cc=simlo@phys.au.dk \
    --cc=tglx@linutronix.de \
    --cc=wli@holomorphy.com \
    --cc=xschmi00@stud.feec.vutbr.cz \
    /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.