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
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, 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
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
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]
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 required because cmpxchg() is used by the reduced work queue patches to
adjust the management data in a
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.
From: David Howells <[EMAIL PROTECTED]>
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 required because cmpxchg() is used by the reduced work queue patches
From: David Howells [EMAIL PROTECTED]
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 required because cmpxchg() is used by the reduced work queue patches
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.
The
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 required because cmpxchg() is used by the reduced work queue patches to
adjust the management data in a
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]
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
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 evaluate the
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 said,
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 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 a
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.
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;
/*
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 strict
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
It's just been pointed out to me that the parisc one isn't safe.
dhowells imagine variable X is set to 3
dhowells CPU A issues cmpxchg(X, 3, 5)
dhowells you'd expect that to change X to 5
dhowells but what if CPU B assigns 6 to X between cmpxchg
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, 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.
I
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 should
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 using
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.
dhowells imagine variable X is set to 3
dhowells CPU A issues cmpxchg(X, 3, 5)
dhowells you'd expect that to
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 exclude
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 not a
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 different
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.
dhowells imagine variable X is set to 3
dhowells CPU A issues
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, 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, 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: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 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, 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 the
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 currently.
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 you only
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, 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 for
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:
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.
An
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
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, 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
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 sizes, I'm
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_pointer_t, or
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 will allow lockless
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 matters?
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 alignment
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
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 in
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 any
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 a 16-bit
101 - 156 of 156 matches
Mail list logo
