question regarding organization of the pte hash table
Hello all-
If anyone has a free moment, I'm looking for education regarding the
organization and manipulation of the hash table which stores pte that are not listed in the TLB or software tables used by the MMU. From what I read regarding the use of the PPC860 MMU (my processor in question), multiple page tables/directories are interleaved through the use of the ASID/CASID identifiers which must match for a MMU translation to be successful. If I understand it correctly the hash table stores pte's which have been victimized from the MMU TLB and/or software tables due to another memory context (CASID) using that same virtual address. If that is correct, then I would like to better understand the hashing functions which the hash table uses to store ptes with identical virtual address and different CASID's. Also, if my previous thinking is correct, the hash table in question must be limited in the number of CASID's which it supports, and consequently, the number of processes which can be run at any one time. How is that limit determined?. If anyone knows of any documentation on the subject, or knows where in the source tree I can get a better understanding of the hash tables function I'd certainly appreciate it. I've tried to glean something from hash_page down in hashtable.S and I'm really quite lost. Thanks all!
Neil
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 1 line · Neil Horman
.... use of the PPC860 MMU (my processor in question),
The MPC8xx family processors don't use a hash table. We just use a two-level Linux page table and fill the TLBs using the software table walk as described in the manual.
Quoted 1 line
.... memory context (CASID) using that same
The MPC8xx identifies 16 possible ASIDs, plus a global identifier we use in the kernel. The sixteen ASIDs are assigned to the 16 most active memory contexts. If we require the use of a memory context that does not have an ASID assigned, we invalidate one of the existing ones and claim it.
To minimize source code changes, we try to utilize as much common code as possible. Sometimes, the same 'hash' functions are called on processors that don't use hash tables, because there is some TLB side effect we still want to cause. Anything hash table related is skipped, but the TLB management is still applied.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan-
Thanks for your reply. I appeciate your help!
Quoted 3 lines
The MPC8xx family processors don't use a hash table. We just use a two-level Linux page table and fill the TLBs using the software table walk as described in the manual.
If we don't use a hash table to store pte's that don't currently exist in the
MMU two-level page table, then do we reconstruct pte's on the fly (from the task's vm_area tree) for tasks which have had their pte's victimized from the page table by another process (I.E. identical Effective Addresses and conflicting ASID's)?
Thanks again!
Neil
Quoted 16 lines · Dan Malek
Quoted 1 line · Neil Horman
.... use of the PPC860 MMU (my processor in question),
The MPC8xx family processors don't use a hash table. We just use a two-level Linux page table and fill the TLBs using the software table walk as described in the manual.
Quoted 1 line
.... memory context (CASID) using that same
The MPC8xx identifies 16 possible ASIDs, plus a global identifier we use in the kernel. The sixteen ASIDs are assigned to the 16 most active memory contexts. If we require the use of a memory context that does not have an ASID assigned, we invalidate one of the existing ones and claim it.
Quoted 8 lines
To minimize source code changes, we try to utilize as much common code as possible. Sometimes, the same 'hash' functions are called on processors that don't use hash tables, because there is some TLB side effect we still want to cause. Anything hash table related is skipped, but the TLB management is still applied.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 1 line · Neil Horman
....then do we reconstruct pte's on the fly
I guess you could say that. The PTEs stored in the Linux page tables are in the proper format to be loaded into the TLBs, so there is little "reconstruction" required. This coupled with the hardware support makes the job fairly painless.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/