On Mon, 4 Feb 2002, Terry Lambert wrote:
> Narvi wrote: > > Speculative writes can only happen to pages in the TLB (so you don't get > > speculative TLB misses and replacements), not having a large amount of 4M > > pages around in the TLB means that addresses covered by these can't > > possibly be involved in speculative writes. > > > > I personaly suspect the reason the cache line flushes of speculatively > > "written to" cache lines derive from the AMD-s use of MOESI coherency and > > mapping that to actual bits. Another "minor" side effect is that you get > > direct cache-to-cahce transfers in SMP systems for shared data. > > I think that the problem is more related to the fact that > there are 16 TLB entries for 4K data pages, 16 for 4K code > pages, and another 8 for 4M pages. > > Peter is right, in other words, because there is a problem > with the interaction of 4K and 4M pages. I've seen this > myself, as I've previously reported, as well as seeing other > problems (and knowing how to work around them, after weeks > of investigation into characterizing them). > I wasn't aware that I was contradicting Peter 8-) Yes, it is possible that there are issues (some of which may in turn be bugs) in the 4KB and 4MB page handling. I'm not sure that 4K vs. 4M handling is done in any special way when it comes to speculative vs. normal writes. Speculative writes don't cross page boundaries (which means a different thing depending on which TLB you found the page from) - meaning that having a change of objects inside a "mapped" 4M page is asking for trouble. Writing back the cache lines that "may" have been written to is imho reasonable behaviour. > Note that I was "lucky", in that I had modified the FreeBSD > kernel to use certain types of mappings in a certain way; > I think it would be very difficult, or impossible, for > anyone else to duplicate the problem in order to better > characterize it beyond "DISABLE_PSE", except the chip > vendors themselves, if they started from first principles > with a simulation. > It may even well be possible to get different results with aligned vs. misaligned reads and writes, or a proper mix thereof. It may be possible to build a model to track down the "what is really going on" part, but its not clear its worth the trouble over just picking what (not) to do. > > -- Terry > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
