linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	torvalds@osdl.org, akpm@osdl.org,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it
Date: Thu, 7 Dec 2006 00:46:38 +0000	[thread overview]
Message-ID: <20061207004638.GA24032@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0612061111130.27263@schroedinger.engr.sgi.com>

On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:

> But then its also just requires disable/enable interrupts on UP which may 
> be cheaper than an atomic operation.
> 
> > For CPUs with load locked + store conditional, it is expensive.
> 
> Because it locks the bus? I am not that familiar with those architectures 
> but it seems that those will have a general problem anyways.

On a decent implementation ll/sc will have the same cost as ordinary
non-atomic load and store instructions.  A likely uniprocessor
implementation uses a single flip-flop ("llbit") in the CPU which is set
by ll and cleared by any exception handler, especially interrupt.  A later
store conditional will then simply fail if that bit is cleared.  That
is extremly trivial stuff.  On SMP it's somewhat more complex; A
processor will have to remember the address used with ll and start
snooping the bus for writes to it.  The store conditional will then
go and upgrade the cache line to exclusive state if the llbit is still
set and perform the store.  The llbit would be cleared if the processor
has snooped any other write to the cacheline.  Details are fun but that's
bascially how it's implemented.

Of course load linked / store conditional are typically used in loops
so there is a little extra overhead from that especially where when the
branch is misspredicted.

Also note there is no locked cycle required to implement load linked /
store conditional.

  Ralf

  parent reply	other threads:[~2006-12-07  0:47 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 16:43 [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it David Howells
2006-12-06 17:21 ` Linus Torvalds
2006-12-06 18:56 ` Christoph Lameter
2006-12-06 19:00   ` Russell King
2006-12-06 19:16     ` Christoph Lameter
2006-12-06 19:28       ` Linus Torvalds
2006-12-06 19:58       ` Russell King
2006-12-06 21:36         ` Matthew Wilcox
2006-12-06 21:52           ` Christoph Lameter
2006-12-06 22:05             ` Matthew Wilcox
2006-12-06 22:15               ` Christoph Lameter
2006-12-07  0:37               ` Roman Zippel
2006-12-07  0:54                 ` Linus Torvalds
2006-12-07  1:05                   ` Roman Zippel
2006-12-07  1:18                     ` Linus Torvalds
2006-12-07  1:24                       ` Roman Zippel
2006-12-07  1:36                         ` Linus Torvalds
2006-12-07  1:44                           ` Matthew Wilcox
2006-12-07  2:09                             ` Douglas McNaught
2006-12-07  1:52                           ` Roman Zippel
2006-12-07  9:23                   ` Nick Piggin
2006-12-06 22:38             ` Linus Torvalds
2006-12-07  9:31         ` Nick Piggin
2006-12-07 13:20           ` Ivan Kokshaysky
2006-12-07 15:03           ` Russell King
2006-12-08  1:18             ` Nick Piggin
2006-12-08  8:56               ` Russell King
2006-12-08 16:06                 ` Christoph Lameter
2006-12-08 16:31                   ` Russell King
2006-12-08 16:43                     ` Christoph Lameter
2006-12-08 16:47                       ` Russell King
2006-12-08 16:53                         ` Christoph Lameter
2006-12-08 16:58                           ` Russell King
2006-12-08 16:56                 ` David Howells
2006-12-08 17:06                   ` Christoph Lameter
2006-12-08 17:18                     ` Russell King
2006-12-08 17:23                       ` Christoph Lameter
2006-12-08 19:15                         ` Linus Torvalds
2006-12-08 19:31                           ` Russell King
2006-12-08 19:37                             ` Linus Torvalds
2006-12-08 19:43                               ` Russell King
2006-12-08 20:01                             ` Linus Torvalds
2006-12-08 18:46                   ` Linus Torvalds
2006-12-08 19:04                     ` Russell King
2006-12-08 19:35                       ` Linus Torvalds
2006-12-08 19:59                         ` Russell King
2006-12-08 20:34                           ` Linus Torvalds
2006-12-11 11:04                     ` David Howells
2006-12-08 22:33                 ` Nick Piggin
2006-12-07 15:36           ` Linus Torvalds
2006-12-07 16:51           ` Ralf Baechle
2006-12-07  0:46       ` Ralf Baechle [this message]
2006-12-06 19:05   ` Linus Torvalds
2006-12-06 19:08     ` Al Viro
2006-12-06 19:25       ` Linus Torvalds
2006-12-06 19:29         ` Matthew Wilcox
2006-12-06 19:54           ` Linus Torvalds
2006-12-06 19:56             ` Linus Torvalds
2006-12-06 19:43         ` David Howells
2006-12-07  1:09       ` David Miller
2006-12-06 19:26     ` Matthew Wilcox
2006-12-06 19:29       ` Christoph Lameter
2006-12-06 19:36         ` Matthew Wilcox
2006-12-06 19:47           ` Christoph Lameter
2006-12-06 19:50             ` Matthew Wilcox
2006-12-06 20:11               ` Christoph Lameter
2006-12-06 20:17                 ` Matthew Wilcox
2006-12-06 19:34       ` Linus Torvalds
2006-12-06 19:41         ` Matthew Wilcox
2006-12-06 19:45       ` David Howells
2006-12-06 20:00     ` Russell King
2006-12-07 15:06     ` Russell King
2006-12-08 15:32       ` Russell King
2006-12-06 19:12 ` Lennert Buytenhek
2006-12-06 19:47 ` David Howells
2006-12-06 20:09   ` Lennert Buytenhek

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=20061207004638.GA24032@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --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).