question regarding organization of the pte hash table

question regarding organization of the pte hash table

[Neil Horman]

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/

Re: question regarding organization of the pte hash table

[Dan Malek]

Neil Horman wrote:

> .... 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.

> .... 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/

Re: question regarding organization of the pte hash table

[Neil Horman]

Dan-
	Thanks for your reply.   I appeciate your help!

> 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



Dan Malek wrote:
>
> Neil Horman wrote:
>
> > .... 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.
>
> > .... 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/

Re: question regarding organization of the pte hash table

[Dan Malek]

Neil Horman wrote:


> ....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/