Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
I prefer burying barriers into other primitives.
When they should naturally be there, eg. locking or the
On Wednesday 15 August 2007, Paul E. McKenney wrote:
ACCESS_ONCE() is indeed intended to be used when actually loading or
storing the variable. That said, I must admit that it is not clear to me
why you would want to add an extra order() rather than ACCESS_ONCE()ing
one or both of the
On Wednesday 15 August 2007 15:29:43 Arnd Bergmann wrote:
On Wednesday 15 August 2007, Paul E. McKenney wrote:
ACCESS_ONCE() is indeed intended to be used when actually loading or
storing the variable. That said, I must admit that it is not clear to me
why you would want to add an extra
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use it.
rmb() orders *any* two reads; that includes two reads from the same
location.
Consider that smp_rmb basically will do anything from flushing the
On Wed, Aug 15, 2007 at 08:51:58PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use it.
rmb() orders *any* two reads; that includes two reads from the same
location.
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
If the two reads are to the same location, all CPUs I am aware of
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
If the two reads are to the same location, all CPUs I am aware of
will
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
I prefer burying barriers into other
On Wed, Aug 15, 2007 at 09:46:55PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
On Wed, Aug 15, 2007 at 10:13:49PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
Please check the definition of cache coherence.
Which of the twelve thousand such definitions? :-)
Summary: the CPU is indeed within its rights to execute loads and
stores
to a single variable out of order, -but- only if it gets the same
result
that it would have obtained by executing them
Segher Boessenkool wrote:
Please check the definition of cache coherence.
Which of the twelve thousand such definitions? :-)
Every definition I have seen says that writes to a single memory
location have a serial order as seen by all CPUs, and that a read
will return the most recent write
Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them in
as a just in case thin now (unless there is a better reason).
On Thu, Aug 16, 2007 at 11:09:25AM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them in
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
What do you think of this crazy idea?
/* Enforce a compiler barrier for only operations to location X.
* Call multiple times to provide an ordering between multiple
* memory locations. Other memory operations can be assumed by
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
On Tuesday 14 August 2007, Paul E. McKenney wrote:
#define order(x) asm volatile( : +m (x))
There was something very similar discussed earlier in this thread,
with quite a bit of debate as to exactly what the m flag should
look like. I suggested something similar named ACCESS_ONCE in the
On Wed, Aug 15, 2007 at 12:01:54AM +0200, Arnd Bergmann wrote:
On Tuesday 14 August 2007, Paul E. McKenney wrote:
#define order(x) asm volatile( : +m (x))
There was something very similar discussed earlier in this thread,
with quite a bit of debate as to exactly what the m flag should
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For non-smp
architectures, I'm concerned about interacting with interrupt handlers. Some
drivers do use atomic_* operations.
I'm not sure that actually answers my
Paul E. McKenney wrote:
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing.
Chris Snook wrote:
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp
architectures, I'm concerned about interacting with interrupt
handlers. Some
drivers do use atomic_* operations.
I'm not sure that
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For non-smp
architectures, I'm concerned about interacting with interrupt handlers. Some
drivers do use atomic_* operations.
I'm not sure that actually answers my question. Why not
Chris Snook [EMAIL PROTECTED] wrote:
To head off the criticism, I admit this is an oversimplification, and true
busy-waiters should be using cpu_relax(), which contains a barrier.
Why would you want to use cpu_relax()? That's there to waste time efficiently,
isn't it? Shouldn't you be using
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
To head off the criticism, I admit this is an oversimplification, and true
busy-waiters should be using cpu_relax(), which contains a barrier.
Why would you want to use cpu_relax()? That's there to waste time efficiently,
isn't it?
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
handlers. Some drivers do use atomic_* operations.
What problems with interrupt handlers? Access to int/long
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
handlers. Some drivers do use atomic_*
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
To head off the criticism, I admit this is an
30 matches
Mail list logo
