levy@nsc.nsc.com (Jonathan Levy) (12/15/88)
In article <10738@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > >the hardware design requires that segment and page tables be in >cache-inhibited pages. Maybe it would be safe not to cache-inhibit >those pages and be sure to do cache flushes before the MMU does a table >walk, but the documentation doesn't say so. > >My guess is that segment and page tables are not cached simply because >it would make the hardware design very hard. The MMU and cache are >already working in parallel, because the cache begins its search when >the virtual address first shows up, at the same time that the MMU >begins the virtual to physical translation. (The cache starts with the >low 12 address bits, which are the same for virtual and physical, then >uses the other physical address bits when the MMU has them available.) >Giving the MMU the ability to break into the cache cycle on a BATC/PATC >miss, then restarting the cache cycle, seems awfully complicated. This problem came up while defining the MMU mecahnism within the NS32532 ( On chip MMU, Data cache, Instruction Cache). There, too, the memory accesses during MMU page walk are not cached. It did not seem necessary performance-wise, and would have complicated the design. On the other hand, the issue of allowing the page tables to reside in cacheable pages was more important. In multiprocessor applications page table accesses can cause a heavy penalty if not allowed to be cached in the external cache. As there is no difference (as far as the programmer can tell) between external cache and on-chip cache, cacheable pages can be entered into all levels of cache. The NS32532 solved the coherency problem by ensuring that all page table updates made by the MMU ( such as referenced and modified bits) would be written to both on-chip cache and external memory. THis allows the SW to saflely read in page tables as data, although they reside in cacheable pages. Jonathan Levy