Messages in this thread | | | Date | Fri, 13 Aug 1999 10:57:54 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New resources - pls, explain :-( |
| |
On Fri, 13 Aug 1999, Paul Mackerras wrote: > > (I exaggerate. Alan Cox said that not reordering was a safer default > (which is essentially my position) and Dave Miller said to me in > private email something along the lines that any sane architecture has > a side-effect bit in the PTEs to prevent reordering of accesses to > certain pages.)
Davem looks at it the wrong way. In-order is very much the default for sane architectures.
A sane architecture has a extra bit that _allows_ re-ordering to certain areas or pages. It should be off by default, but it might be turned on by specific drivers. We may add a hint field to "ioremap()" for PCI, for example, to let PCI devices that know thay can do write combining have a way to let the CPU know to go wild..
> Richard Henderson mentioned four drivers which he uses which deal with > this: ncr, aic7xxx, tulip, epic100. How many others would there be in > this category? It sounds to me like the vast majority of drivers > which use readl/writel would be assuming that they prevent reordering.
Almost ALL the current drivers depend on not re-ordering. There are actually very few cases where you can be allowed to re-order widly, and frame buffers is the only really common case.
Certain other drivers allow a subset of re-ordering which is to allow collapsing of write events - turning consecutive byte stores into word stores etc. Not really re-ordering the input or output, but combining events (works for reads too: a way to tell the hardware that it is ok to do burst reads over the bus if the pre-fetch logic implies that it makes sense).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |