From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Christoph Lameter <clameter@sgi.com>,
David Howells <dhowells@redhat.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
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: Fri, 8 Dec 2006 19:31:16 +0000 [thread overview]
Message-ID: <20061208193116.GI31068@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0612081101280.3516@woody.osdl.org>
On Fri, Dec 08, 2006 at 11:15:58AM -0800, Linus Torvalds wrote:
> On Fri, 8 Dec 2006, Christoph Lameter wrote:
> >
> > As also shown in this thread: There are restrictions on what you can do
> > between ll/sc
>
> This, btw, is almost certainly true on ARM too.
>
> There are three major reasons for restrictions on ll/sc:
>
> - bus-cycle induced things (eg variations of "you cannot do a store in
> between the ll and the sc, because it will touch the cache and clear
> the bit", where "the store" might be a load too, and "the cache" might
> be just "the bus interface")
No such restriction on ARM.
> - trap handling usually clears the internal lock bit too, which means
> that depending on the micro-architecture, even internal microtraps
> (like even just branch misprediction, but more commonly things like TLB
> misses etc) can cause a sc to always fail.
Also not true. The architectural implementation is:
ldrex: tags the _physical_ address + cpu number,
transitions to exclusive access.
strex: if in exclusive access state and matches the previous
tagged physical address + cpu number pair, store
succeeds.
This is typically implemented in hardware, and in the case of a SMP
system, external to the CPU cores themselves. So all it's doing is
looking at the exclusive accesses. It is not embedded into the CPU
core so that micro-architectural stuff affects it.
> - timing. Livelock in particular.
That is a problem that we're facing, and the solution is rather simple.
You need to introduce a CPU-number specific number of cycles before
retrying the operation on failure.
> All of which means that _nobody_ can really do this reliably in C.
I utterly disagree. I could code atomic_add() as:
extern void cpu_specific_delay(void);
static inline int atomic_add_return(int i, atomic_t *v)
{
do {
asm("ldrex %0, [%1]" : "=r" (val) : "r" (v));
val += i;
asm("strex %0, %1, [%2]" : "=r" (res) : "r" (val), "r" (v));
if (res)
cpu_specific_delay();
} while (res);
return val;
}
and actually we /are/ going to have to go down this path to break the
livelock problem, like it or not. Ditto for the ARM bitops operations,
so we might as well have ARM at least implement a generic ll/sc thing.
Coding the cpu specific delays into every strex site is going to make
them far too heavy to put inline.
> So right now, I think the "cmpxchg" or the "bitmask set" approach are the
> alternatives. Russell - LL/SC simply isn't on the table as an interface,
> whether you like it or not.
Buggerit then. cmpxchg sucks as an interface, and I am going to
continue to assert that.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2006-12-08 19:31 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 [this message]
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
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:43 ` David Howells
2006-12-06 19:54 ` Linus Torvalds
2006-12-06 19:56 ` Linus Torvalds
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=20061208193116.GI31068@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--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=nickpiggin@yahoo.com.au \
--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