On Wed, 1 Dec 2010 15:09:54 +0000 David Laight <David.Laight@xxxxxxxxxx> wrote: > The in_le32() not only contains the unwanted 'sync', but also > a 'twi' (trap immediate - NFI exactly what this does) and 'isync'. It turns a data dependency into a flow dependency. It's basically equivalent to: lwz rX, ... cmpw rX, rX bne 1f 1: isync > The 'isync' is particularly horrid and unnecessary (aborts > the instruction queue and refeches the opcode bytes) The isync makes sure that the twi has completed before proceeding. Note that the guarded, cache-inhibited load itself can be pretty painful -- the core can't restart it, so it must complete before you can take an interrupt. > The very slow in_le32() might be there to give semi-synchronous > traps on address fault - but unless the hardware is being probed > that really isn't necessary. There are times when you really want to be sure that the I/O is finished before proceeding with something that isn't a load/store and thus can't be serialized with normal barriers. E.g. you're about to execute instructions in a physical address window that you just set up (or even just create a non-guarded mapping to it -- could get speculative accesses any time), or you just masked an interrupt at the PIC (with a readback to flush) and are about to enable MSR[EE]. Most of the time, though, it's overkill. It should probably be an alternate accessor form, or maybe a wait_for_io() wrapper -- if it can be shown to make a real performance difference. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
