[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46E290D3.10304@vc.cvut.cz>
Date: Sat, 08 Sep 2007 05:08:51 -0700
From: Petr Vandrovec <vandrove@...cvut.cz>
To: dean gaudet <dean@...tic.org>
CC: Nick Piggin <nickpiggin@...oo.com.au>,
Linus Torvalds <torvalds@...ux-foundation.org>, ak@...e.de,
Jesse Barnes <jesse.barnes@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: Intel Memory Ordering White Paper
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?
>
> see section 7.2.3 of intel volume 3A...
>
> "Code dependent upon sequential store ordering should not use the string
> operations for the entire data structure to be stored. Data and semaphores
> should be separated. Order dependent code should use a discrete semaphore
> uniquely stored to after any string operations to allow correctly ordered
> data to be seen by all processors."
>
> i think we need sfence after things like copy_page, clear_page, and
> possibly copy_user... at least on intel processors with fast strings
> option enabled.
I do not think. I believe that authors are trying to say that
struct { uint8 lock; uint8 data; } x;
lea (x.data),%edi
mov $2,%ecx
std
rep movsb
to set both data and lock does not guarantee that x.lock will be set
after x.data and that you should do
lea (x.data),%edi
std
movsb
movsb # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete
enough to me
instead (and yes, I know that my example is silly).
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists