Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks

[Stephan Diestelhorst <stephan.diestelhorst@xxxxxxx>]

On Wednesday 28 September 2011 18:44:25 Jeremy Fitzhardinge wrote:
> On 09/28/2011 06:58 AM, Stephan Diestelhorst wrote:
> >> I guess it comes down to throwing myself on the efficiency of some kind
> >> of fence instruction.  I guess an lfence would be sufficient; is that
> >> any more efficient than a full mfence?
> > An lfence should not be sufficient, since that essentially is a NOP on
> > WB memory. You really want a full fence here, since the store needs to
> > be published before reading the lock with the next load.
> 
> The Intel manual reads:
> 
>     Reads cannot pass earlier LFENCE and MFENCE instructions.
>     Writes cannot pass earlier LFENCE, SFENCE, and MFENCE instructions.
>     LFENCE instructions cannot pass earlier reads.
> 
> Which I interpreted as meaning that an lfence would prevent forwarding. 
> But I guess it doesn't say "lfence instructions cannot pass earlier
> writes", which means that the lfence could logically happen before the
> write, thereby allowing forwarding?  Or should I be reading this some
> other way?

Indeed. You are reading this the right way. 

> >> Could you give me a pointer to AMD's description of the ordering rules?
> > They should be in "AMD64 Architecture Programmer's Manual Volume 2:
> > System Programming", Section 7.2 Multiprocessor Memory Access Ordering.
> >
> > http://developer.amd.com/documentation/guides/pages/default.aspx#manuals
> >
> > Let me know if you have some clarifying suggestions. We are currently
> > revising these documents...
> 
> I find the English descriptions of these kinds of things frustrating to
> read because of ambiguities in the precise meaning of words like "pass",
> "ahead", "behind" in these contexts.  I find the prose useful to get an
> overview, but when I have a specific question I wonder if something more
> formal would be useful.

It would be, and some have started this efort:

http://www.cl.cam.ac.uk/~pes20/weakmemory/

But I am not sure whether that particular nasty forwarding case is
captured properly in their model It is on my list of things to check.

> I guess it's implied that anything that is not prohibited by the
> ordering rules is allowed, but it wouldn't hurt to say it explicitly.
> That said, the AMD description seems clearer and more explicit than the
> Intel manual (esp since it specifically discusses the problem here).

Thanks! Glad you like it :)

Stephan
-- 
Stephan Diestelhorst, AMD Operating System Research Center
stephan.diestelhorst@xxxxxxx, Tel. +49 (0)351 448 356 719

Advanced Micro Devices GmbH
Einsteinring 24
85609 Aschheim
Germany

Geschaeftsfuehrer: Alberto Bozzo;
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel