On Thursday, August 31, 2006 1:11 am, Pierre Ossman wrote:
> I'm been trying to wrap my head around all this memory barrier
> business, and I'm slowly grasping the inter-CPU behaviours. Barriers
> with regard to devices still has me a bit confused though.
>
> The deviceiobook document and memory-barriers.txt both make it clear
> that memory operations to devices are strictly ordered from a single
> CPU. When more CPUs are involved, things get a bit fuzzier.
> memory-barriers.txt seems to suggest that mmiowb() is only needed
> before an unlock under special circumstances, but deviceiobook states
> that mmiowb() should be used before all unlocks where the writeX():s
> aren't followed by a readX() (which would flush the writes anyway).
>
> Grepping the tree indicates that mmiowb() isn't used that often, but
> according to deviceiobook, they should be plentiful. This leads me to
> believe that memory-barriers.txt is closer to the truth, but then the
> question is what those special cirumstances that require mmiowb() are.
AFAICT, they're both right. Generally, mmiowb() should be used prior to
unlock in a critical section whose last PIO operation is a writeX.
You're right though: for portability, many more drivers should use this
type of barrier. However, rather than doing an audit of the tree and
inserting mmiowb() everywhere (w/o testing it), we chose to add it on an
as-needed basis for drivers that run on platforms that have weak I/O
ordering. Feel free to add it in other places if you want though (esp.
if you have the hardware to test your changes).
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
