[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
>> 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 thi
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)
[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
of
> 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 instruction
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 sp
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 an
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 sh
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 pre
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 locati
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 tha
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 is
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 _no
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 "you
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. Betwe
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 depend
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
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 iss
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 t
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
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
maint
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.
>
> cmpx
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 wid
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 l
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
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 an
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 mig
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 th
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 di
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 a
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" i
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 alig
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 a
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 matt
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 wi
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 atomic_poi
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 siz
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
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 whate
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 lit
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 optimal
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 (store_exclu
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 y
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 c
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 th
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 im
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 th
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 unsub
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 th
Lennert Buytenhek <[EMAIL PROTECTED]> 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:
#else /* ARM_ARCH_6 */
#inc
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 d
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.
It's
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 ex
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(&X, 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 usin
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 shoul
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 kern
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(&X, 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 stric
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;
/* Poor
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 implementation for various performance
> > criticial portions of the kernel.
>
On Wed, Dec 06, 2006 at 04:43:14PM +, 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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 th
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.
I suspect ARM may have been the last one without one, no?
That sai
On Wed, 6 Dec 2006, David Howells wrote:
> Implement generic UP cmpxchg() where an arch doesn't otherwise support it.
> This assuming that the arch doesn't have support SMP without providing its own
> cmpxchg() implementation.
>
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>
I cannot evaluat
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 implementation for various performance
> criticial portions of the kernel.
Let's recap on cmpxchg.
For CPUs with no atomic
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
On Wed, 6 Dec 2006, David Howells wrote:
>
> Implement generic UP cmpxchg() where an arch doesn't otherwise support it.
> This assuming that the arch doesn't have support SMP without providing its own
> cmpxchg() implementation.
This is too ugly to live. At least the kernel/workqueue.c part.
T
83 matches
Mail list logo
