Russell King <[EMAIL PROTECTED]> wrote:
> Yes you can. Well, you can on ARM at least. Between the load exclusive
> you can do anything you like until you hit the store exclusive.
How come atomic_set() on arm6 is implemented as:
static inline void atomic_set(atomic_t *v, int i)
Russell King [EMAIL PROTECTED] wrote:
Yes you can. Well, you can on ARM at least. Between the load exclusive
you can do anything you like until you hit the store exclusive.
How come atomic_set() on arm6 is implemented as:
static inline void atomic_set(atomic_t *v, int i)
{
Russell King wrote:
On Fri, Dec 08, 2006 at 12:18:52PM +1100, Nick Piggin wrote:
Russell King wrote:
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
architectures to produce optimal code.
Implementing
On Fri, 8 Dec 2006, Russell King wrote:
>>
> The only instructions which affect the exclusive access state are the
> exclusive access instructions themselves.
Not according to the docs I found.
The ARM1136 manual explicitly states that any attempt to modify that
address clears the tag (for
On Fri, 8 Dec 2006, Russell King wrote:
>
> No such restriction on ARM.
>
> Also not true. The architectural implementation is:
I checked the ARM manuals, and quite fankly, they don't back you up.
They do not claim that the physical address tag is byte-granular, and in
fact they make it
On Fri, Dec 08, 2006 at 11:35:39AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2006, Russell King wrote:
> >
> > Yes you can. Well, you can on ARM at least. Between the load exclusive
> > you can do anything you like until you hit the store exclusive. If you
> > haven't touched the
On Fri, Dec 08, 2006 at 11:37:45AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2006, Russell King wrote:
> >
> > I utterly disagree. I could code atomic_add() as:
>
> Sure. And Alpha could do that too. If you write the C code a specific way,
> you can make it work. That does NOT mean
On Fri, 8 Dec 2006, Russell King wrote:
>
> Yes you can. Well, you can on ARM at least. Between the load exclusive
> you can do anything you like until you hit the store exclusive. If you
> haven't touched the location (with anything other than another load
> exclusive) and no other CPU has
On Fri, 8 Dec 2006, Russell King wrote:
>
> I utterly disagree. I could code atomic_add() as:
Sure. And Alpha could do that too. If you write the C code a specific way,
you can make it work. That does NOT mean that you can expose it widely as
a portable interface - it's still just a very
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
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
On Fri, Dec 08, 2006 at 10:46:17AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2006, David Howells wrote:
> >
> > In fact I think more things have LL/SC than have CMPXCHG.
>
> But you cannot expose ll/sc to C, so that's a bogus argument.
Yes you can. Well, you can on ARM at least.
On Fri, 8 Dec 2006, David Howells wrote:
>
> In fact I think more things have LL/SC than have CMPXCHG.
But you cannot expose ll/sc to C, so that's a bogus argument.
If you do ll/sc, you need to program in assembly language.
Linus
-
To unsubscribe from this list: send the line
On Fri, 8 Dec 2006, Russell King wrote:
> As proven previously the reverse is also true. And as shown previously
> the cheaper out of the two for all platforms is the LL/SC based
> implementation, where the architecture specific implementation can
> be _either_ LL/SC based or cmpxchg based
On Fri, Dec 08, 2006 at 09:06:00AM -0800, Christoph Lameter wrote:
> On Fri, 8 Dec 2006, David Howells wrote:
>
> > > It is the most universal atomic instruction that I know of.
> >
> > I think TAS-type things and XCHG-type things are more common.
>
> Huh? The most popular architectures are
On Fri, 8 Dec 2006, David Howells wrote:
> > It is the most universal atomic instruction that I know of.
>
> I think TAS-type things and XCHG-type things are more common.
Huh? The most popular architectures are i386 x86_64 sparc ia64 etc which
all have one or the other form of cmpxchg (some
On Fri, Dec 08, 2006 at 08:53:22AM -0800, Christoph Lameter wrote:
> On Fri, 8 Dec 2006, Russell King wrote:
>
> > > Not having cmpxchg is even worse because it requires the introduction and
> > > maintenance of large sets of arch specific operations. Much more complex.
> >
> > And which bit of
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> cmpxchg is the simplest solution to realize many other atomic operations and
> its widely available on a wide variety of platforms.
But by no means all. Where it doesn't exist it can only be properly emulated
by something such as LL/SC if they are
On Fri, 8 Dec 2006, Russell King wrote:
> > Not having cmpxchg is even worse because it requires the introduction and
> > maintenance of large sets of arch specific operations. Much more complex.
>
> And which bit of "not available on many architectures" have you not grasped
> yet?
We
On Fri, Dec 08, 2006 at 08:43:09AM -0800, Christoph Lameter wrote:
> On Fri, 8 Dec 2006, Russell King wrote:
>
> > You're advocating cmpxchg is adopted by all architectures. It isn't
> > available on many architectures, and those which it can be requires
> > unnecessarily complicated coding.
>
On Fri, 8 Dec 2006, Russell King wrote:
> You're advocating cmpxchg is adopted by all architectures. It isn't
> available on many architectures, and those which it can be requires
> unnecessarily complicated coding.
Not having cmpxchg is even worse because it requires the introduction and
On Fri, Dec 08, 2006 at 08:06:23AM -0800, Christoph Lameter wrote:
> On Fri, 8 Dec 2006, Russell King wrote:
>
> > I'm trying to suggest a better implementation for atomic ops rather
> > than just bowing to this x86-centric "cmpxchg is the best, everyone
> > must implement it" mentality.
>
>
On Fri, 8 Dec 2006, Russell King wrote:
> I'm trying to suggest a better implementation for atomic ops rather
> than just bowing to this x86-centric "cmpxchg is the best, everyone
> must implement it" mentality.
cmpxchg is the simplest solution to realize many other atomic operations
and its
On Thu, Dec 07, 2006 at 03:06:06PM +, Russell King wrote:
> On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
> >
> >
> > On Wed, 6 Dec 2006, Christoph Lameter wrote:
> > >
> > > I'd really appreciate a cmpxchg that is generically available for
> > > all arches. It will allow
On Fri, Dec 08, 2006 at 12:18:52PM +1100, Nick Piggin wrote:
> Russell King wrote:
> >On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
>
> >>>Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
> >>>architectures to produce optimal code.
> >>>
> >>>Implementing an
On Fri, Dec 08, 2006 at 12:18:52PM +1100, Nick Piggin wrote:
Russell King wrote:
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
architectures to produce optimal code.
Implementing an cmpxchg based
On Thu, Dec 07, 2006 at 03:06:06PM +, Russell King wrote:
On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
On Wed, 6 Dec 2006, Christoph Lameter wrote:
I'd really appreciate a cmpxchg that is generically available for
all arches. It will allow lockless
On Fri, 8 Dec 2006, Russell King wrote:
I'm trying to suggest a better implementation for atomic ops rather
than just bowing to this x86-centric cmpxchg is the best, everyone
must implement it mentality.
cmpxchg is the simplest solution to realize many other atomic operations
and its widely
On Fri, Dec 08, 2006 at 08:06:23AM -0800, Christoph Lameter wrote:
On Fri, 8 Dec 2006, Russell King wrote:
I'm trying to suggest a better implementation for atomic ops rather
than just bowing to this x86-centric cmpxchg is the best, everyone
must implement it mentality.
cmpxchg is the
On Fri, 8 Dec 2006, Russell King wrote:
You're advocating cmpxchg is adopted by all architectures. It isn't
available on many architectures, and those which it can be requires
unnecessarily complicated coding.
Not having cmpxchg is even worse because it requires the introduction and
On Fri, Dec 08, 2006 at 08:43:09AM -0800, Christoph Lameter wrote:
On Fri, 8 Dec 2006, Russell King wrote:
You're advocating cmpxchg is adopted by all architectures. It isn't
available on many architectures, and those which it can be requires
unnecessarily complicated coding.
Not
Christoph Lameter [EMAIL PROTECTED] wrote:
cmpxchg is the simplest solution to realize many other atomic operations and
its widely available on a wide variety of platforms.
But by no means all. Where it doesn't exist it can only be properly emulated
by something such as LL/SC if they are
On Fri, 8 Dec 2006, Russell King wrote:
Not having cmpxchg is even worse because it requires the introduction and
maintenance of large sets of arch specific operations. Much more complex.
And which bit of not available on many architectures have you not grasped
yet?
We discussed various
On Fri, Dec 08, 2006 at 08:53:22AM -0800, Christoph Lameter wrote:
On Fri, 8 Dec 2006, Russell King wrote:
Not having cmpxchg is even worse because it requires the introduction and
maintenance of large sets of arch specific operations. Much more complex.
And which bit of not
On Fri, 8 Dec 2006, David Howells wrote:
It is the most universal atomic instruction that I know of.
I think TAS-type things and XCHG-type things are more common.
Huh? The most popular architectures are i386 x86_64 sparc ia64 etc which
all have one or the other form of cmpxchg (some issues
On Fri, Dec 08, 2006 at 09:06:00AM -0800, Christoph Lameter wrote:
On Fri, 8 Dec 2006, David Howells wrote:
It is the most universal atomic instruction that I know of.
I think TAS-type things and XCHG-type things are more common.
Huh? The most popular architectures are i386 x86_64
On Fri, 8 Dec 2006, Russell King wrote:
As proven previously the reverse is also true. And as shown previously
the cheaper out of the two for all platforms is the LL/SC based
implementation, where the architecture specific implementation can
be _either_ LL/SC based or cmpxchg based depending
On Fri, 8 Dec 2006, David Howells wrote:
In fact I think more things have LL/SC than have CMPXCHG.
But you cannot expose ll/sc to C, so that's a bogus argument.
If you do ll/sc, you need to program in assembly language.
Linus
-
To unsubscribe from this list: send the line
On Fri, Dec 08, 2006 at 10:46:17AM -0800, Linus Torvalds wrote:
On Fri, 8 Dec 2006, David Howells wrote:
In fact I think more things have LL/SC than have CMPXCHG.
But you cannot expose ll/sc to C, so that's a bogus argument.
Yes you can. Well, you can on ARM at least. Between the
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
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
On Fri, 8 Dec 2006, Russell King wrote:
I utterly disagree. I could code atomic_add() as:
Sure. And Alpha could do that too. If you write the C code a specific way,
you can make it work. That does NOT mean that you can expose it widely as
a portable interface - it's still just a very
On Fri, 8 Dec 2006, Russell King wrote:
Yes you can. Well, you can on ARM at least. Between the load exclusive
you can do anything you like until you hit the store exclusive. If you
haven't touched the location (with anything other than another load
exclusive) and no other CPU has issued
On Fri, Dec 08, 2006 at 11:37:45AM -0800, Linus Torvalds wrote:
On Fri, 8 Dec 2006, Russell King wrote:
I utterly disagree. I could code atomic_add() as:
Sure. And Alpha could do that too. If you write the C code a specific way,
you can make it work. That does NOT mean that you can
On Fri, Dec 08, 2006 at 11:35:39AM -0800, Linus Torvalds wrote:
On Fri, 8 Dec 2006, Russell King wrote:
Yes you can. Well, you can on ARM at least. Between the load exclusive
you can do anything you like until you hit the store exclusive. If you
haven't touched the location (with
On Fri, 8 Dec 2006, Russell King wrote:
No such restriction on ARM.
Also not true. The architectural implementation is:
I checked the ARM manuals, and quite fankly, they don't back you up.
They do not claim that the physical address tag is byte-granular, and in
fact they make it pretty
On Fri, 8 Dec 2006, Russell King wrote:
The only instructions which affect the exclusive access state are the
exclusive access instructions themselves.
Not according to the docs I found.
The ARM1136 manual explicitly states that any attempt to modify that
address clears the tag (for
Russell King wrote:
On Fri, Dec 08, 2006 at 12:18:52PM +1100, Nick Piggin wrote:
Russell King wrote:
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
architectures to produce optimal code.
Implementing
Russell King wrote:
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
architectures to produce optimal code.
Implementing an cmpxchg based accessor macro allows cmpxchg architectures
to produce optimal code
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
> Wrong. Your ll/sc implementation with cmpxchg is buggy. The cmpxchg
> load_locked is not locked at all, and there can be interleaving writes
> between the load and cmpxchg which do not cause the store_conditional
> to fail.
>
> It
On Thu, 7 Dec 2006, Nick Piggin wrote:
>
> It might be reasonable to implement this watered down version, but:
> don't some architectures have restrictions on what instructions can
> be issued between the ll and the sc?
Yes. You really probably do not want to expose ll/sc on a C level because
On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 6 Dec 2006, Christoph Lameter wrote:
> >
> > I'd really appreciate a cmpxchg that is generically available for
> > all arches. It will allow lockless implementation for various performance
> > criticial portions of
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
> Russell King wrote:
> >On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
>
> >No. If you read what I said, you'll see that you can _cheaply_ use
> >cmpxchg in a ll/sc based implementation. Take an atomic increment
>
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
> It might be reasonable to implement this watered down version, but:
> don't some architectures have restrictions on what instructions can
> be issued between the ll and the sc?
Yes. On Alpha you cannot execute other load/stores, taken
Russell King wrote:
On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
No. If you read what I said, you'll see that you can _cheaply_ use
cmpxchg in a ll/sc based implementation. Take an atomic increment
operation.
do {
old = load_locked(addr);
Linus Torvalds wrote:
On Thu, 7 Dec 2006, Roman Zippel wrote:
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
To be honest, it'd be much easier if we only defined these operations on
atomic_t's. We have all the infrastructure in place for them, and
they're fairly well understood. If you need
Linus Torvalds wrote:
On Thu, 7 Dec 2006, Roman Zippel wrote:
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
To be honest, it'd be much easier if we only defined these operations on
atomic_t's. We have all the infrastructure in place for them, and
they're fairly well understood. If you need
Russell King wrote:
On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
No. If you read what I said, you'll see that you can _cheaply_ use
cmpxchg in a ll/sc based implementation. Take an atomic increment
operation.
do {
old = load_locked(addr);
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
It might be reasonable to implement this watered down version, but:
don't some architectures have restrictions on what instructions can
be issued between the ll and the sc?
Yes. On Alpha you cannot execute other load/stores, taken
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Russell King wrote:
On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
No. If you read what I said, you'll see that you can _cheaply_ use
cmpxchg in a ll/sc based implementation. Take an atomic increment
On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
On Wed, 6 Dec 2006, Christoph Lameter wrote:
I'd really appreciate a cmpxchg that is generically available for
all arches. It will allow lockless implementation for various performance
criticial portions of the kernel.
On Thu, 7 Dec 2006, Nick Piggin wrote:
It might be reasonable to implement this watered down version, but:
don't some architectures have restrictions on what instructions can
be issued between the ll and the sc?
Yes. You really probably do not want to expose ll/sc on a C level because
of
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Wrong. Your ll/sc implementation with cmpxchg is buggy. The cmpxchg
load_locked is not locked at all, and there can be interleaving writes
between the load and cmpxchg which do not cause the store_conditional
to fail.
It might be
Russell King wrote:
On Thu, Dec 07, 2006 at 08:31:08PM +1100, Nick Piggin wrote:
Implementing ll/sc based accessor macros allows both ll/sc _and_ cmpxchg
architectures to produce optimal code.
Implementing an cmpxchg based accessor macro allows cmpxchg architectures
to produce optimal code
Matthew Wilcox <[EMAIL PROTECTED]> writes:
> On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
>> Or are you saying that gcc aligns normal 32-bit entities at
>> 16-bit alignment? Neither of those sound very likely.
>
> alignof(u32) is 2 on m68k. Crazy, huh?
The original 68000 had
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > m68060 produces a trap for unaligned atomic access, unfortunately standard
> > alignment is smaller than this.
>
> Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you
> saying that you can't do a 32-bit atomic access at
On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
> Or are you saying that gcc aligns normal 32-bit entities at
> 16-bit alignment? Neither of those sound very likely.
alignof(u32) is 2 on m68k. Crazy, huh?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, 7 Dec 2006, Roman Zippel wrote:
>
> m68060 produces a trap for unaligned atomic access, unfortunately standard
> alignment is smaller than this.
Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you
saying that you can't do a 32-bit atomic access at any 32-bit
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > Any _real_ CPU will simply never care about _anything_ else than just the
> > > size of the datum in question.
> >
> > ..or alignment which a dedicated atomic type would allow to be attached.
>
> Can you give any example of a real CPU where
On Thu, 7 Dec 2006, Roman Zippel wrote:
> >
> > Any _real_ CPU will simply never care about _anything_ else than just the
> > size of the datum in question.
>
> ..or alignment which a dedicated atomic type would allow to be attached.
Can you give any example of a real CPU where alignment
From: Al Viro <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 19:08:28 +
> On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
> >
> >
> > On Wed, 6 Dec 2006, Christoph Lameter wrote:
> > >
> > > I'd really appreciate a cmpxchg that is generically available for
> > > all arches. It
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > To be honest, it'd be much easier if we only defined these operations on
> > > atomic_t's. We have all the infrastructure in place for them, and
> > > they're fairly well understood. If you need different sizes, I'm OK
> > > with an
On Thu, 7 Dec 2006, Roman Zippel wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> > To be honest, it'd be much easier if we only defined these operations on
> > atomic_t's. We have all the infrastructure in place for them, and
> > they're fairly well understood. If you need different
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
Hi,
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> To be honest, it'd be much easier if we only defined these operations on
> atomic_t's. We have all the infrastructure in place for them, and
> they're fairly well understood. If you need different sizes, I'm OK
> with an atomic_pointer_t, or
On Wed, 6 Dec 2006, Christoph Lameter wrote:
>
> This means we tolerate the assignment race for SMP that was pointed out
> earlier?
The assignment "race" doesn't really exist in real code, I suspect.
There's two cases of assignment:
- pure initialization. This one isn't racy, since it's
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> To be honest, it'd be much easier if we only defined these operations on
> atomic_t's. We have all the infrastructure in place for them, and
> they're fairly well understood. If you need different sizes, I'm OK
> with an atomic_pointer_t, or whatever.
On Wed, Dec 06, 2006 at 01:52:20PM -0800, Christoph Lameter wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> > And for those of us with only load-and-zero, that's simply:
> >
> > #define load_locked(addr) spin_lock(hash(addr)), *addr
> > #define store_exclusive(addr, old, new) \
> >
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> And for those of us with only load-and-zero, that's simply:
>
> #define load_locked(addr) spin_lock(hash(addr)), *addr
> #define store_exclusive(addr, old, new) \
> *addr = new, spin_unlock(hash(addr)), 0
>
> which is also
On Wed, Dec 06, 2006 at 07:58:20PM +, Russell King wrote:
> No. If you read what I said, you'll see that you can _cheaply_ use
> cmpxchg in a ll/sc based implementation. Take an atomic increment
> operation.
>
> do {
> old = load_locked(addr);
> } while
On Wed, Dec 06, 2006 at 12:11:01PM -0800, Christoph Lameter wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> > Follow the thread back. I'm talking about parisc. Machines exist (are
> > still being sold) with up to 128 cores. I think the largest we've
> > confirmed work are 8 CPUs.
>
> And
On Wed, Dec 06, 2006 at 07:47:22PM +, David Howells wrote:
> > > Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
> >
> > That's not quite true, there exist ARMv5 processors that in theory
> > can support SMP.
>
> I meant that the Linux ARM arch doesn't support it:
Ah, yes, not
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> On Wed, Dec 06, 2006 at 11:47:40AM -0800, Christoph Lameter wrote:
> > Nope this is a UP implementation. There is no cpu B.
>
> Follow the thread back. I'm talking about parisc. Machines exist (are
> still being sold) with up to 128 cores. I think
On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
> On Wed, 6 Dec 2006, Russell King wrote:
>
> > On Wed, Dec 06, 2006 at 10:56:14AM -0800, Christoph Lameter wrote:
> > > I'd really appreciate a cmpxchg that is generically available for
> > > all arches. It will allow lockless
On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 6 Dec 2006, Christoph Lameter wrote:
> >
> > I'd really appreciate a cmpxchg that is generically available for
> > all arches. It will allow lockless implementation for various performance
> > criticial portions of
On Wed, 6 Dec 2006, Linus Torvalds wrote:
>
> Your problem will be, of course, that any architecture that does this in
> hardware will just DoTheRightThing, and as such, broken architectures with
> bad locking primitives will have to test and do source-level analysis
> more.
(The underlying
On Wed, Dec 06, 2006 at 11:47:40AM -0800, Christoph Lameter wrote:
> Nope this is a UP implementation. There is no cpu B.
Follow the thread back. I'm talking about parisc. Machines exist (are
still being sold) with up to 128 cores. I think the largest we've
confirmed work are 8 CPUs.
-
To
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> That doesn't help, since assignment can't be guarded by any lock.
True. Pure assignment will be lost, and is only ok for the case of a pure
initializer (where nobody can see the old state).
Your problem will be, of course, that any architecture
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> On Wed, Dec 06, 2006 at 11:29:42AM -0800, Christoph Lameter wrote:
> > On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> >
> > > It's just been pointed out to me that the parisc one isn't safe.
> > >
> > > imagine variable X is set to 3
> > > CPU A issues
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Also, I don't see quite why you think "cmpxchg()" and "atomic_cmpxchg()"
> would be different. ANY cmpxchg() needs to be atomic - if it's not,
> there's no point to the operation at all, since you'd just write it as
It's not that atomic_cmpxchg() is
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> > Ok. For SMP-safety, it's important that any architecture that can't do
> > this needs to _share_ the same spinlock (on SMP only, of course) that it
> > uses for the bitops.
>
> That doesn't help, since assignment can't be guarded by any lock.
On Wed, Dec 06, 2006 at 11:34:52AM -0800, Linus Torvalds wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> > Given parisc's paucity of atomic operations (load-and-zero-32bit and
> > load-and-zero-64bit), cmpxchg() is impossible to implement safely.
> > There has to be something we can hook to
On Wed, Dec 06, 2006 at 11:29:42AM -0800, Christoph Lameter wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> > It's just been pointed out to me that the parisc one isn't safe.
> >
> > imagine variable X is set to 3
> > CPU A issues cmpxchg(, 3, 5)
> > you'd expect that to change X to 5
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> Given parisc's paucity of atomic operations (load-and-zero-32bit and
> load-and-zero-64bit), cmpxchg() is impossible to implement safely.
> There has to be something we can hook to exclude another processor
> modifying the variable. I'm OK with
On Wed, 6 Dec 2006, Christoph Lameter wrote:
>
> > 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.
load_locked + store_conditional
On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
> On Wed, 6 Dec 2006, Christoph Lameter wrote:
> >
> > I'd really appreciate a cmpxchg that is generically available for
> > all arches. It will allow lockless implementation for various performance
> > criticial portions of the
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> It's just been pointed out to me that the parisc one isn't safe.
>
> imagine variable X is set to 3
> CPU A issues cmpxchg(, 3, 5)
> you'd expect that to change X to 5
> but what if CPU B assigns 6 to X between cmpxchg reading X
> and it setting X?
On Wed, Dec 06, 2006 at 11:25:35AM -0800, Linus Torvalds wrote:
> Ok. For SMP-safety, it's important that any architecture that can't do
> this needs to _share_ the same spinlock (on SMP only, of course) that it
> uses for the bitops.
That doesn't help, since assignment can't be guarded by any
On Wed, 6 Dec 2006, Al Viro wrote:
>
> No. sparc32 doesn't have one, for instance.
Ok. For SMP-safety, it's important that any architecture that can't do
this needs to _share_ the same spinlock (on SMP only, of course) that it
uses for the bitops.
It would be good (but perhaps not as
Have a look at arch/i386/kernel/cpu/intel.c. You can probably replace my
code that simulates cmpxchg for 386s
arch/i386/kernel/cpu/intel.c:
#ifndef CONFIG_X86_CMPXCHG
unsigned long cmpxchg_386_u8(volatile void *ptr, u8 old, u8 new)
{
u8 prev;
unsigned long flags;
/*
1 - 100 of 156 matches
Mail list logo
