[parisc-linux] Proposal for altering our Page Table layouts

Carlos O'Donell carlos at baldric.uwo.ca
Sat Apr 10 15:46:03 MDT 2004


> To be honest, I don't see the value of hashed page tables.  A two level
> structure is about as optimal as you can get.  Particularly as the pgdir
> will be cache hot (from the tlb refill misses).
>
> In a hashed page table layout, you just have to have a page collision 
> and you've already lost to the two level page table (because of the
> cache hotness of pgdir).

While pgdir might be hot in cache, but the rest of the structures will
sprawl to fill the entire cache.

In contrast a hashed page table layout would be extremely dense, and fit
better in the cache. If you were to have a collision the likelyhood
that what you want is in the cache can actually be higher.

> In particular, on PA because of our congruence requirements for shared
> mappings, it would be difficult to find an efficient hashing mechanism
> that didn't generate deep collision chains (and remember, we're all
> ILP32 at the moment, so just one collision and we lose to the 2 level).

Huck & Hayes says "high va bits XOR low va bits."

http://www.baldric.uwo.ca/~carlos/Architectural-support-for-translation-table-management-in-large-address-space-machines.pdf

I've been doing some literature searches on the issue, mainly IEEE and
ACM over the last 10-20 years. Most of the research was done in the mid
90's and interestingly enough a lot of it has to do with PA's.

Read the paper at the above link and tell me what you think of the
16-byte PTE presented, and how the allocations happen on a single entry
by entry basis. Another author suggests that the HAT and the PDIR could
be merged (you'll have to read the paper to find out what I mean). I'm
not sure what to do about the aliasing restrictions...

c.



More information about the parisc-linux mailing list