Messages in this thread | | | Date | Fri, 26 Nov 1999 21:09:35 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Fri, 26 Nov 1999, Linus Torvalds wrote:
> On x86 where x >=6, the MTRR's do the same job. That's why the MTRR's were > introduced: because the P6 core can re-order accesses, you can no longer > afford to wait until the access hits the bus to know whether it is RAM or > not, so you have to introduce a in-core data structure to maintain that > knowledge.
i believe this still doesnt turn off store forwarding. If two PCI commands are written to the same register then they might get 'merged', resulting in the first written command to be lost. This usually doesnt happen, but can happen, and does happen in some cases.
> So note that we do NOT want to make all ioremapped accesses > uncacheable, because then we could no longer do clever tricks with > MTRR's.
the only MTRR stuff we do right now is mmap()-ing the frame buffer via /dev/mem, right? In that case we are doing things outside of ioremap()'s scope anyway.
> And we know that we want to do MTRR stuff, at least eventually.
yep, i agree that we want to do WC in drivers/video/*.c, but i think the interface should be additive. We still have __ioremap(,,flags), and can add an ioremap_wc() function easily, no? What i mean is that right now 99% of ioremap()s is for ordinary shared PCI memory drivers, which use command registers, and for those anything non-UC is potentially lethal.
actually this is how ioremap_nocache() popped up, i just didnt understand this issue at that time. (i hope i do now :). About 2 years ago CISCO found out when developing drivers that their driver fails mysteriously on PPro boxes. So i sent a small patch to add ioremap_nocache(), but that's the wrong solution now i believe.
Ingo
- 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/
| |