Would it be possible/reasonable to extend ATE support to a larger number of entries (four each for instruction and data is somewhat small) and to support the caching of directory entries in the ATB? By allowing directory entries to be cached in the ATB, increasing the number of ATB entries becomes much less wasteful. (To save power, one might define a bit indicating if any of the ATEs are valid page translations for the current context, allowing the processor to avoid accessing the ATB except on a TLB miss. [One might want a different bit for supervisor mode, which may be more likely to use huge pages.] The bit[s] could be considered part of the process state and saved on context switches or cleared and relearned after a context switch [if a page ATE was not evicted, it would only take a single TLB miss to reset the bit].) Caching directory entries would allow many TLB misses to be single memory look-ups (a modest win for 32-bit implementations, but a perhaps significant win for 64-bit implementations). It would also allow a weak hardware look-up assist (e.g., it would not be terribly expensive, I suspect, for hardware to support fetching the small-PTE on a TLB miss into a SPR, saving a few cycles since that memory access would otherwise have to wait until the pipeline refilled and an spr2gr-extract-spr2gr-insert- load sequence was executed), while keeping the more complex operations (PTE selection and eviction, table updating for dirty PTEs, optionally changing touched/dirty bits and updating the table [while the DRAM still has that memory as an active row]) part of the software. Furthermore, an OS could avoid using a full page of directory entries (two pages for 64-bit implementations) for small contexts by including a few directory entries as part of the saved context. (For a 32-bit implemenation, four entries could be stored in 20 bytes--only eight bits of VA are needed for each directory entry. For 64-bit systems with page tables mapped to the lower 64 TiB of memory, 32 bytes would suffice. This could be a significant savings if small [often short-lived] processes are somewhat common. Using zero as the page table base address could indicate that this method is used. [For hardware ATB updates {note: one could support only hardware TLB updates, leaving directory updates to software}, one would then need a means to lock the ATEs.]) Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040913/eb918e4e/attachment.htm