mark@hubcap.clemson.edu (Mark Smotherman) (02/02/91)
I'm interested in how the cache aliasing problem was solved on the IBM RS/6000 and any implications for the OS paging management. The RS/6000 has a physically addressed cache in which virtual address translation is overlapped with cache lookup. In a straight- forward implementation, only the invariant bits would be used for the overlapped lookup. That is, only the low 12 bits (specifying the byte offset in a 4k page) would be used in lookup since they would remain unchanged between the virtual address and the physical address. The page frame number, which arrives later -- after translation -- , would be used for the tag matching. However, this approach limits the total cache size to the page size times the set associativity. (cf. i486) However, the RS/6000 uses 20 bit lookup: the 12-bit byte offset plus the low 8 bits from the virtual page number. The Oehler and Groves paper in Jan. 1990 IBM JRD has one paragraph (1st column, p. 35) on the implications of this, and the Groves and Oehler paper in the IBM RISC System/6000 Technology book also has one paragraph (1st column, p. 22). However, I don't understand these paragraphs as to what they imply for the OS. In my simple thinking, it seems that if they use the 8 low bits of the VPN, a page can only be mapped into a page frame whose PFN mod 255 == VPN mod 255. This seems to tremendously impact frame allocation by the OS -- and cause contention for a limited number of page frames in each mod 255 equivalence class. (A worst case?? Lots of processes executing with locality in their own unique virtual page 0's contending for a set of page frames that is only 1/256 the size of main memory.) How does the alias avoidance actually work? How are equivalence classes of page frames avoided? -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark