mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
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 14:40:36 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0808231435230.3363@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080823203016.GA1328@Krystal>



On Sat, 23 Aug 2008, Mathieu Desnoyers wrote:
>
> 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.

EXACTLY.

It's not even necessarily a "contention" bit per se - it's literally a 
"readers have to take the slow-path" bit (writers will obviously _always_ 
take the slowpath if there is any non-zero value at all, so they don't 
need it).

Then, the slow-path might actually decide that "hey, there is no _actual_ 
writer there yet - just some _waiting_ writer, but since this read lock is 
in an interrupt context, we have to let it go through _despite_ the fact 
that the lock is contended in order to avoid deadlock".

So it allows a fast-path for the trivial cases that is literally just a 
couple of instructions long, and that is nice not just because of 
performance issues, but because it then means that you can entirely ignore 
all those things in the slow path. It also means that everybody can look 
at the fast-path and decide that "ok, the fast-path really is optimal". 

That fast-path is what a lot of people care more about than just about 
anything else.

The slow-path, in comparison, can be in C, and can do all those checks 
like "are we in an (sw-)interrupt handler?" and basically prioritize 
certain classes of people.

			Linus

  reply	other threads:[~2008-08-23 21:41 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
2008-08-23 21:40                                     ` Linus Torvalds [this message]
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=alpine.LFD.1.10.0808231435230.3363@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.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

all inboxes | Powered by JetHome®