Jesse Barnes <[EMAIL PROTECTED]> writes:
>
> It's really both (1) and (2). This document will become part of the
> regular manuals when the next version is published. And yes,
> processors may do something different internally, but software can rely
> on the behavior described by the rules
On Wednesday, September 12, 2007 11:26 am Dr. David Alan Gilbert wrote:
> * Jesse Barnes ([EMAIL PROTECTED]) wrote:
> > FYI, we just released a new white paper describing memory ordering
> > for Intel processors:
> > http://developer.intel.com/products/processor/manuals/index.htm
> >
> > Should
On Wednesday, September 12, 2007 11:26 am Dr. David Alan Gilbert wrote:
* Jesse Barnes ([EMAIL PROTECTED]) wrote:
FYI, we just released a new white paper describing memory ordering
for Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer
Jesse Barnes [EMAIL PROTECTED] writes:
It's really both (1) and (2). This document will become part of the
regular manuals when the next version is published. And yes,
processors may do something different internally, but software can rely
on the behavior described by the rules in the
* Jesse Barnes ([EMAIL PROTECTED]) wrote:
> FYI, we just released a new white paper describing memory ordering for
> Intel processors:
> http://developer.intel.com/products/processor/manuals/index.htm
>
> Should help answer some questions about some of the ordering primitives
> we use on i386
* Jesse Barnes ([EMAIL PROTECTED]) wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and
Nick Piggin wrote:
smp_rmb() should not need to do anything because loads are done
in order anyway. Both AMD and Intel have committed to this now.
The important point is that they *appear* to be done in order. AFAIK,
the CPUs can still do speculative and out of order loads, but throw
out the
> AMD processors guarantee loads are ordered and stores are ordered
> (with exceptions of non-temporal, and non-wb policy).
>
> As for the others that do out of order stores, are any of them SMP?
IDT winchip isn't, Geode isn't
-
To unsubscribe from this list: send the line "unsubscribe
On Sat, 8 Sep 2007, Petr Vandrovec wrote:
> dean gaudet wrote:
> > On Sun, 9 Sep 2007, Nick Piggin wrote:
> >
> > > I've also heard that string operations do not follow the normal ordering,
> > > but
> > > that's just with respect to individual loads/stores in the one operation,
> > > I
> > >
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
On Sun, 9 Sep 2007, Nick Piggin wrote:
> I've also heard that string operations do not follow the normal ordering, but
> that's just with respect to individual loads/stores in the one operation, I
> hope? And they will still follow ordering rules WRT surrounding loads and
> stores?
see section
On Saturday 08 September 2007 20:29, Alan Cox wrote:
> On Fri, 7 Sep 2007 15:26:50 -0700
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > FYI, we just released a new white paper describing memory ordering for
> > Intel processors:
> > http://developer.intel.com/products/processor/manuals/index.htm
On Saturday 08 September 2007 20:30, Alan Cox wrote:
> On Sat, 8 Sep 2007 18:54:57 +1000
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
> > > FYI, we just released a new white paper describing memory ordering for
> > > Intel processors:
> >
On Saturday 08 September 2007 20:19, Andi Kleen wrote:
> On Friday 07 September 2007 21:57:35 Nick Piggin wrote:
> > > > Anyway, the lfence should be able to go away without so much trouble.
> > >
> > > You mean sfence? lfence in rmb is definitely needed.
> >
> > I mean lfence in smp_rmb().
>
>
On Sat, 8 Sep 2007 18:54:57 +1000
Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
> > FYI, we just released a new white paper describing memory ordering for
> > Intel processors:
> > http://developer.intel.com/products/processor/manuals/index.htm
On Fri, 7 Sep 2007 15:26:50 -0700
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> FYI, we just released a new white paper describing memory ordering for
> Intel processors:
> http://developer.intel.com/products/processor/manuals/index.htm
>
> Should help answer some questions about some of the
On Friday 07 September 2007 21:57:35 Nick Piggin wrote:
>
> > > Anyway, the lfence should be able to go away without so much trouble.
> >
> > You mean sfence? lfence in rmb is definitely needed.
>
> I mean lfence in smp_rmb().
One point of rmb is to stop speculative loads and I don't think we
On Saturday 08 September 2007 18:53, Andi Kleen wrote:
> On Friday 07 September 2007 20:13:12 Nick Piggin wrote:
> > On Sunday 09 September 2007 03:48, Nick Piggin wrote:
> > > There is some suggestion in the source code that non-temporal stores
> > > (movntq) are weakly ordered. But AFAIKS from
On Friday 07 September 2007 20:13:12 Nick Piggin wrote:
> On Sunday 09 September 2007 03:48, Nick Piggin wrote:
>
> > There is some suggestion in the source code that non-temporal stores
> > (movntq) are weakly ordered. But AFAIKS from the documents, it is ordered
> > when operating on wb memory.
On Sunday 09 September 2007 03:48, Nick Piggin wrote:
> There is some suggestion in the source code that non-temporal stores
> (movntq) are weakly ordered. But AFAIKS from the documents, it is ordered
> when operating on wb memory. What's the situation there?
Sorry, it looks from the AMD
On Sunday 09 September 2007 03:34, Nick Piggin wrote:
> On Saturday 08 September 2007 09:20, Linus Torvalds wrote:
> > On Sat, 8 Sep 2007, Nick Piggin wrote:
> > > So, can we finally noop smp_rmb and smp_wmb on x86?
> >
> > Did AMD already release their version? If so, we should probably add a
> >
On Saturday 08 September 2007 09:20, Linus Torvalds wrote:
> On Sat, 8 Sep 2007, Nick Piggin wrote:
> > So, can we finally noop smp_rmb and smp_wmb on x86?
>
> Did AMD already release their version? If so, we should probably add a
> commit that does that in somewhat early 2.6.24 rc, and add the
On Saturday 08 September 2007 09:20, Linus Torvalds wrote:
On Sat, 8 Sep 2007, Nick Piggin wrote:
So, can we finally noop smp_rmb and smp_wmb on x86?
Did AMD already release their version? If so, we should probably add a
commit that does that in somewhat early 2.6.24 rc, and add the pointers
On Sunday 09 September 2007 03:34, Nick Piggin wrote:
On Saturday 08 September 2007 09:20, Linus Torvalds wrote:
On Sat, 8 Sep 2007, Nick Piggin wrote:
So, can we finally noop smp_rmb and smp_wmb on x86?
Did AMD already release their version? If so, we should probably add a
commit that
On Sunday 09 September 2007 03:48, Nick Piggin wrote:
There is some suggestion in the source code that non-temporal stores
(movntq) are weakly ordered. But AFAIKS from the documents, it is ordered
when operating on wb memory. What's the situation there?
Sorry, it looks from the AMD document
On Friday 07 September 2007 20:13:12 Nick Piggin wrote:
On Sunday 09 September 2007 03:48, Nick Piggin wrote:
There is some suggestion in the source code that non-temporal stores
(movntq) are weakly ordered. But AFAIKS from the documents, it is ordered
when operating on wb memory. What's
On Saturday 08 September 2007 18:53, Andi Kleen wrote:
On Friday 07 September 2007 20:13:12 Nick Piggin wrote:
On Sunday 09 September 2007 03:48, Nick Piggin wrote:
There is some suggestion in the source code that non-temporal stores
(movntq) are weakly ordered. But AFAIKS from the
On Friday 07 September 2007 21:57:35 Nick Piggin wrote:
Anyway, the lfence should be able to go away without so much trouble.
You mean sfence? lfence in rmb is definitely needed.
I mean lfence in smp_rmb().
One point of rmb is to stop speculative loads and I don't think we
can get
On Fri, 7 Sep 2007 15:26:50 -0700
Jesse Barnes [EMAIL PROTECTED] wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering
On Sat, 8 Sep 2007 18:54:57 +1000
Nick Piggin [EMAIL PROTECTED] wrote:
On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
On Saturday 08 September 2007 20:19, Andi Kleen wrote:
On Friday 07 September 2007 21:57:35 Nick Piggin wrote:
Anyway, the lfence should be able to go away without so much trouble.
You mean sfence? lfence in rmb is definitely needed.
I mean lfence in smp_rmb().
One point of rmb is
On Saturday 08 September 2007 20:30, Alan Cox wrote:
On Sat, 8 Sep 2007 18:54:57 +1000
Nick Piggin [EMAIL PROTECTED] wrote:
On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
On Saturday 08 September 2007 20:29, Alan Cox wrote:
On Fri, 7 Sep 2007 15:26:50 -0700
Jesse Barnes [EMAIL PROTECTED] wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
see section 7.2.3
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
On Sat, 8 Sep 2007, Petr Vandrovec wrote:
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering,
but
that's just with respect to individual loads/stores in the one operation,
I
hope? And they will
AMD processors guarantee loads are ordered and stores are ordered
(with exceptions of non-temporal, and non-wb policy).
As for the others that do out of order stores, are any of them SMP?
IDT winchip isn't, Geode isn't
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Nick Piggin wrote:
smp_rmb() should not need to do anything because loads are done
in order anyway. Both AMD and Intel have committed to this now.
The important point is that they *appear* to be done in order. AFAIK,
the CPUs can still do speculative and out of order loads, but throw
out the
On Sat, 8 Sep 2007, Nick Piggin wrote:
>
> So, can we finally noop smp_rmb and smp_wmb on x86?
Did AMD already release their version? If so, we should probably add a
commit that does that in somewhat early 2.6.24 rc, and add the pointers to
the whitepapers in the commit message.
On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
> FYI, we just released a new white paper describing memory ordering for
> Intel processors:
> http://developer.intel.com/products/processor/manuals/index.htm
>
> Should help answer some questions about some of the ordering primitives
> we
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and x86_64.
Jesse
-
To unsubscribe from this list:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and x86_64.
Jesse
-
To unsubscribe from this list:
On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on
On Sat, 8 Sep 2007, Nick Piggin wrote:
So, can we finally noop smp_rmb and smp_wmb on x86?
Did AMD already release their version? If so, we should probably add a
commit that does that in somewhat early 2.6.24 rc, and add the pointers to
the whitepapers in the commit message.
44 matches
Mail list logo
