public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Joe Perches <joe@perches.com>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC PATCH] Writer-biased low-latency rwlock v8
Date: Sat, 23 Aug 2008 16:30:16 -0400	[thread overview]
Message-ID: <20080823203016.GA1328@Krystal> (raw)
In-Reply-To: <alpine.LFD.1.10.0808231100090.3363@nehalem.linux-foundation.org>

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> 
> 
> On Sat, 23 Aug 2008, Mathieu Desnoyers wrote:
> > 
> > Now, let me explain why I need at least not one, but _four different_
> > contention bits. Simply because there are four types of contention, one
> > for each execution context which may take the read lock. (irq, softirq,
> > non-preemptable, preemptable)
> 
> No. You need _one_ contention bit in the fast-path.
> 
> Then, as you get into the slow-path, you can decide on four different 
> behaviours.
> 
> Quite frankly, I don't think this discussion is going anywhere. I don't 
> think I'd take anything from you, since you seem to have a really hard 
> time separating out the issue of fast-path and slow-path. So I'm simply 
> not going to bother, and I'm not going to expect to merge your work. 
> 
> Sorry, but it simply isn't worth my time or effort.
> 
> 			Linus

Hi,

OK, I now see how I can apply this contention bit idea to my algo.
Actually, the point I just fixed in my head is that this bit will be a
"MAY_CONTEND" bit, which could let higher priority readers access the
lock in the slow path. Only one fast path reader count will be required,
just as you said.

Sorry about taking that much time to get my head around this. Thanks for
your helpful explanations and your time.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2008-08-23 20:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-16  7:39 [PATCH] x86_64 : support atomic ops with 64 bits integer values Mathieu Desnoyers
2008-08-16 15:04 ` H. Peter Anvin
2008-08-16 15:43   ` Mathieu Desnoyers
2008-08-16 17:30     ` Linus Torvalds
2008-08-16 21:19       ` [RFC PATCH] Fair rwlock Mathieu Desnoyers
2008-08-16 21:33         ` Linus Torvalds
2008-08-17  7:53           ` [RFC PATCH] Fair low-latency rwlock v3 Mathieu Desnoyers
2008-08-17 16:17             ` Linus Torvalds
2008-08-17 19:10               ` [RFC PATCH] Fair low-latency rwlock v5 Mathieu Desnoyers
2008-08-17 21:30                 ` [RFC PATCH] Fair low-latency rwlock v5 (updated benchmarks) Mathieu Desnoyers
2008-08-18 18:59                 ` [RFC PATCH] Fair low-latency rwlock v5 Linus Torvalds
2008-08-18 23:25                 ` Paul E. McKenney
2008-08-19  6:04                   ` Mathieu Desnoyers
2008-08-19  7:33                     ` Mathieu Desnoyers
2008-08-19  9:06                       ` Mathieu Desnoyers
2008-08-19 16:48                       ` Linus Torvalds
2008-08-21 20:50                         ` [RFC PATCH] Writer-biased low-latency rwlock v8 Mathieu Desnoyers
2008-08-21 21:00                           ` Linus Torvalds
2008-08-21 21:15                             ` Linus Torvalds
2008-08-21 22:22                               ` Linus Torvalds
2008-08-23  5:09                               ` Mathieu Desnoyers
2008-08-23 18:02                                 ` Linus Torvalds
2008-08-23 20:30                                   ` Mathieu Desnoyers [this message]
2008-08-23 21:40                                     ` Linus Torvalds
2008-08-21 21:26                             ` H. Peter Anvin
2008-08-21 21:41                               ` Linus Torvalds
2008-08-25 19:20                 ` [RFC PATCH] Fair low-latency rwlock v5 Peter Zijlstra

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=20080823203016.GA1328@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.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