On Tue, 24 Jul 2007, Linus Torvalds wrote:
> On Tue, 24 Jul 2007, Satyam Sharma wrote:
> >
> > Looks like when you said "CPU memory barrier extends to all memory
> > references" you were probably referring to a _given_ CPU ... yes,
> > that statement is correct in that case.
>
> No. CPU memory
On Tue, 24 Jul 2007, Satyam Sharma wrote:
>
> Looks like when you said "CPU memory barrier extends to all memory
> references" you were probably referring to a _given_ CPU ... yes,
> that statement is correct in that case.
No. CPU memory barriers extend to all CPU's. End of discussion.
It's
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Are you saying that it is OK for the store to var to
be reordered below the clear_bit? If not, what are you
saying?
I might be making a radical turn-around here, but all of a
sudden I think it's actually a good idea to put a
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > For the purpose of this discussion (Linux memory
> > > barrier semantics, on WB memory), it is true of CPU
> > > and compiler barriers.
> >
> > On later Intel processors, if the memory address range being referenced
> > (and say written to) by the
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
On later Intel processors, if the memory address range being referenced
(and say written to) by the
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
>
> > > > Consider this (the above two functions exist
> > only for clear_bit(),
> > > > the atomic variant, as you already know), the
> > _only_ memory reference
> > > > we care about is that of the address of the
> > passed
--- Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:
>
> > Satyam Sharma wrote:
> > > Consider this (the above two functions exist
> only for clear_bit(),
> > > the atomic variant, as you already know), the
> _only_ memory reference
> > > we care about is that
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > > [...]
> > > > So let's make these proper no-ops, because that's exactly what we
> > > > require
> > > > these to be on the i386 platform.
> > >
> > > No.
Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist only for clear_bit(),
the atomic variant, as you already know), the _only_ memory reference
we care about is that of the address of the passed bit-string:
(1) The compiler must not optimize / elid it
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around
Satyam Sharma wrote:
> Consider this (the above two functions exist only for clear_bit(),
> the atomic variant, as you already know), the _only_ memory reference
> we care about is that of the address of the passed bit-string:
>
> (1) The compiler must not optimize / elid it (i.e. we need to
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
> >
> > > From Documentation/atomic_ops.txt, those archs that require explicit
> > memory barriers around
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also
Satyam Sharma wrote:
Consider this (the above two functions exist only for clear_bit(),
the atomic variant, as you already know), the _only_ memory reference
we care about is that of the address of the passed bit-string:
(1) The compiler must not optimize / elid it (i.e. we need to disallow
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around
Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist only for clear_bit(),
the atomic variant, as you already know), the _only_ memory reference
we care about is that of the address of the passed bit-string:
(1) The compiler must not optimize / elid it
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
[...]
So let's make these proper no-ops, because that's exactly what we
require
these to be on the i386 platform.
No. clear_bit is not a compiler
--- Satyam Sharma [EMAIL PROTECTED] wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist
only for clear_bit(),
the atomic variant, as you already know), the
_only_ memory reference
we care about is that of the address of
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist
only for clear_bit(),
the atomic variant, as you already know), the
_only_ memory reference
we care about is that of the address of the
passed bit-string:
No.
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
On later Intel processors, if the memory address range being referenced
(and say written to) by the
On Tue, 24 Jul 2007, Nick Piggin wrote:
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
On later Intel processors, if the memory address range being referenced
(and say written to) by the (locked)
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Are you saying that it is OK for the store to var to
be reordered below the clear_bit? If not, what are you
saying?
I might be making a radical turn-around here, but all of a
sudden I think it's actually a good idea to put a
On Tue, 24 Jul 2007, Satyam Sharma wrote:
Looks like when you said CPU memory barrier extends to all memory
references you were probably referring to a _given_ CPU ... yes,
that statement is correct in that case.
No. CPU memory barriers extend to all CPU's. End of discussion.
It's not
On Tue, 24 Jul 2007, Linus Torvalds wrote:
On Tue, 24 Jul 2007, Satyam Sharma wrote:
Looks like when you said CPU memory barrier extends to all memory
references you were probably referring to a _given_ CPU ... yes,
that statement is correct in that case.
No. CPU memory barriers
Satyam Sharma wrote:
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
>From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386, clear_bit() is a
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386, clear_bit() is a strict,
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386,
28 matches
Mail list logo
