From: Kyle McMartin on
On Fri, May 21, 2010 at 03:42:06PM +0200, Peter Zijlstra wrote:
> Implements local64_t.
>
> On 64bit, local_t is of size long, and thus we make local64_t an alias.
> On 32bit, we fall back to atomic64_t.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
> Cc: linux-arch(a)vger.kernel.org
> LKML-Reference: <new-submission>

Header looks good.

Acked-by: Kyle McMartin <kyle(a)mcmartin.ca>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Howells on


Peter Zijlstra <a.p.zijlstra(a)chello.nl> wrote:

> + * This is the default implementation, which uses atomic64_t. Which is
> + * rather pointless. The whole point behind local64_t is that some processors
> + * can perform atomic adds and subtracts in a manner which is atomic wrt IRQs
> + * running on this CPU. local64_t allows exploitation of such capabilities.

Interesting... What FRV does in atomic64-ops.S should probably be rebranded
local64_t, and atomic64_t ops be based on that in non-SMP mode.

What I did on FRV was to emulate LL/ST instructions using some of the
excessive numbers of conditional bits to do so - but it only works on UP
systems.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/