[Top] [All Lists]

Re: RFH: What are the semantics of writeb() and friends?

To: David Daney <>
Subject: Re: RFH: What are the semantics of writeb() and friends?
From: "Maciej W. Rozycki" <>
Date: Fri, 1 Jul 2005 10:33:58 +0100 (BST)
In-reply-to: <>
Original-recipient: rfc822;
References: <>
On Thu, 30 Jun 2005, David Daney wrote:

> My new question is:  What are the semantics of writeb(), writel() et 
> al.?  I would assume that the effects of these must be in the same order 
> that they were issued, and that any hardware write back queue cannot 
> combine or merge them in any way.  Is that correct?

 No it's not.  You need to insert appropriate barriers, one of: wmb(), 
mb() or rmb().  In rare cases you may need to use iob(), which is 
currently non-portable (which reminds me I should really push it 

 For historical reasons only outb(), inl(), outl(), inl(), etc. are meant 
to imply an mb() beforehand and afterwards (IOW, their resulting cycles 
always appear externally in the programmed order).  You may still need 
iob(), though.

> A second question I have is:  What is the difference in the semantics of 
> wbflush() and wmb()?  For my CPU they both evaluate to the same thing 
> (the 'sync' instruction).  So for my own sake I could use either, but 
> depending on the situation I assume that one would be used over the 
> other.

 wbflush() is an old name for iob() -- it will probably vanish one day as 
the name is somewhat inadequate for non-MIPS systems.  They are meant as a 
read/write barrier combined with write completion from the host's point of 
view (i.e. external writes cycles are actually issued by CPU and its 
system controller; they may still be posted e.g. in an I/O bus bridge and 
require another bridge-specific operation to proceed further).  wmb() is 
just a write barrier -- it assures later writes won't be combined with or 
reordered before earlier ones.

 Depending on your needs iob() may be too strong resulting in unnecessary 
performance penalty or wmb() may be to weak resulting in cycles appearing 
in the wrong order or being delayed for too long.  If your CPU happens to 
use "sync" for both, then it probably has an overkill implementation for 
this instruction resulting in performance loss in some places.


<Prev in Thread] Current Thread [Next in Thread>