From: David Woodhouse <[EMAIL PROTECTED]>
Date: Mon, 18 Dec 2006 08:56:24 +
> On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> > This uses "atomic_long_t" for the workstruct "data" field, which shares
> > the per-cpu pointer and the workstruct flag bits in one field.
>
> This
On Mon, Dec 18, 2006 at 08:56:24AM +, David Woodhouse ([EMAIL PROTECTED])
wrote:
> On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> > This uses "atomic_long_t" for the workstruct "data" field, which shares
> > the per-cpu pointer and the workstruct flag bits in one field.
>
> This
On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> This uses "atomic_long_t" for the workstruct "data" field, which shares
> the per-cpu pointer and the workstruct flag bits in one field.
This fixes drivers/connector/connector.c to cope...
Signed-off-by: David Woodhouse <[EMAIL
On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
This uses atomic_long_t for the workstruct data field, which shares
the per-cpu pointer and the workstruct flag bits in one field.
This fixes drivers/connector/connector.c to cope...
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
On Mon, Dec 18, 2006 at 08:56:24AM +, David Woodhouse ([EMAIL PROTECTED])
wrote:
On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
This uses atomic_long_t for the workstruct data field, which shares
the per-cpu pointer and the workstruct flag bits in one field.
This fixes
From: David Woodhouse [EMAIL PROTECTED]
Date: Mon, 18 Dec 2006 08:56:24 +
On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
This uses atomic_long_t for the workstruct data field, which shares
the per-cpu pointer and the workstruct flag bits in one field.
This fixes
On Wed, 13 Dec 2006, Nick Piggin wrote:
> Linus Torvalds wrote:
> >
> > On Tue, 12 Dec 2006, Russell King wrote:
> > >
> > > Why can't we just use atomic_t for this?
> >
> >
> > Well, others have answered that ("wrong sizes"), but I'm wavering on using
> > atomic_long_t. I have to admit that
On Wed, 13 Dec 2006, Nick Piggin wrote:
Linus Torvalds wrote:
On Tue, 12 Dec 2006, Russell King wrote:
Why can't we just use atomic_t for this?
Well, others have answered that (wrong sizes), but I'm wavering on using
atomic_long_t. I have to admit that I'd rather not add a
On Wed, 13 Dec 2006, Nick Piggin wrote:
>
> parisc seems to, but sparc uses its own open coded spinlock for bitops, and
> the array of regular spinlocks for atomic ops. OTOH, consolidating them
> might give more scalable code *and* a smaller cacheline footprint?
Yeah, I think you'd actually
Linus Torvalds wrote:
On Tue, 12 Dec 2006, Russell King wrote:
This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?
Why can't
On Tue, 12 Dec 2006, Russell King wrote:
>
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
>
> Why can't we just use
Russell King <[EMAIL PROTECTED]> wrote:
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
>
> Why can't we just use
Russell King writes:
> Why can't we just use atomic_t for this?
On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes. We could
use atomic_long_t for this, however.
Paul.
-
To unsubscribe from this list: send the line
On Tue, Dec 12, 2006 at 08:11:12PM +, David Howells wrote:
> diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
> index b41831b..5932134 100644
> --- a/include/asm-arm/bitops.h
> +++ b/include/asm-arm/bitops.h
> @@ -117,6 +117,32 @@ atomic_test_and_change_bit(unsigned
>
Add assign_bits() to give an atomic-bitops safe assignment on all archs without
having to rely on the presence of xchg or cmpxchg instructions.
This is needed where archs emulate atomic bitops using spinlocks as there's a
gap between reading the counter and updating it that a direct assignment
Add assign_bits() to give an atomic-bitops safe assignment on all archs without
having to rely on the presence of xchg or cmpxchg instructions.
This is needed where archs emulate atomic bitops using spinlocks as there's a
gap between reading the counter and updating it that a direct assignment
On Tue, Dec 12, 2006 at 08:11:12PM +, David Howells wrote:
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index b41831b..5932134 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -117,6 +117,32 @@ atomic_test_and_change_bit(unsigned
Russell King writes:
Why can't we just use atomic_t for this?
On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes. We could
use atomic_long_t for this, however.
Paul.
-
To unsubscribe from this list: send the line
Russell King [EMAIL PROTECTED] wrote:
This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?
Why can't we just use atomic_t
On Tue, 12 Dec 2006, Russell King wrote:
This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?
Why can't we just use
Linus Torvalds wrote:
On Tue, 12 Dec 2006, Russell King wrote:
This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?
Why can't
On Wed, 13 Dec 2006, Nick Piggin wrote:
parisc seems to, but sparc uses its own open coded spinlock for bitops, and
the array of regular spinlocks for atomic ops. OTOH, consolidating them
might give more scalable code *and* a smaller cacheline footprint?
Yeah, I think you'd actually end up
22 matches
Mail list logo
