[EMAIL PROTECTED] wrote:
> do {
> oldvalue = ll(addr)
> newvalue = ... oldvalue ...
> } while (!sc(addr, oldvalue, newvalue))
>
> Where sc() could be a cmpxchg. But, more importantly, if the
> architecture did implement LL/SC, it could be a "try plain SC; if
> that fails try CMPXCHG
[EMAIL PROTECTED] wrote:
do {
oldvalue = ll(addr)
newvalue = ... oldvalue ...
} while (!sc(addr, oldvalue, newvalue))
Where sc() could be a cmpxchg. But, more importantly, if the
architecture did implement LL/SC, it could be a try plain SC; if
that fails try CMPXCHG built
>> to keep the amount of code between ll and sc to an absolute minimum
>> to avoid interference which causes livelock. Processor timeouts
>> are generally much longer than any reasonable code sequence.
> "Generally" does not mean you can just ignore it and hope the C compiler
> does the right
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)
{
to keep the amount of code between ll and sc to an absolute minimum
to avoid interference which causes livelock. Processor timeouts
are generally much longer than any reasonable code sequence.
Generally does not mean you can just ignore it and hope the C compiler
does the right thing. Nor
[EMAIL PROTECTED] wrote:
atomic_ll() / atomic_sc() with the restriction that they cannot be
nested, you cannot write any C code between them, and may only call
into some specific set of atomic_llsc_xxx primitives, operating on
the address given to ll, and must not have more than a given number
> atomic_ll() / atomic_sc() with the restriction that they cannot be
> nested, you cannot write any C code between them, and may only call
> into some specific set of atomic_llsc_xxx primitives, operating on
> the address given to ll, and must not have more than a given number
> of
On Sun, 10 Dec 2006, [EMAIL PROTECTED] wrote:
>
> While I agree that LL/SC can't be part of the kernel API for people to
> get arbitrarily clever with in the device driver du jour, they are *very*
> nice abstractions for shrinking the arch-specific code size.
I'm not sure.
The thing is, it's
Hi "Linux",
[EMAIL PROTECTED] wrote:
Even if ARM is able to handle any arbitrary C code between the
"load locked" and store conditional API, other architectures can not
by definition.
Maybe so, but I think you and Linus are missing the middle ground.
Nobdy argued against adding nice arch
Hi Linux,
[EMAIL PROTECTED] wrote:
Even if ARM is able to handle any arbitrary C code between the
load locked and store conditional API, other architectures can not
by definition.
Maybe so, but I think you and Linus are missing the middle ground.
Nobdy argued against adding nice arch
On Sun, 10 Dec 2006, [EMAIL PROTECTED] wrote:
While I agree that LL/SC can't be part of the kernel API for people to
get arbitrarily clever with in the device driver du jour, they are *very*
nice abstractions for shrinking the arch-specific code size.
I'm not sure.
The thing is, it's
atomic_ll() / atomic_sc() with the restriction that they cannot be
nested, you cannot write any C code between them, and may only call
into some specific set of atomic_llsc_xxx primitives, operating on
the address given to ll, and must not have more than a given number
of instructions
[EMAIL PROTECTED] wrote:
atomic_ll() / atomic_sc() with the restriction that they cannot be
nested, you cannot write any C code between them, and may only call
into some specific set of atomic_llsc_xxx primitives, operating on
the address given to ll, and must not have more than a given number
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
1 - 100 of 168 matches
Mail list logo
