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 upstream). 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. Maciej
