linux-mips
[Top] [All Lists]

Re: tlb magic

To: madprops@gmx.net
Subject: Re: tlb magic
From: Dominic Sweetman <dom@mips.com>
Date: Sat, 25 Jun 2005 06:51:22 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <18788.1118764826@www21.gmx.net>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <17069.62407.584863.185198@mips.com> <18788.1118764826@www21.gmx.net>
Sender: linux-mips-bounce@linux-mips.org
Long ago...

> yes, I'm reading "See MIPS Run". So thanks for the online support that comes
> with it. Now, if I got it correctly, the exception routing described in
> section 6.7 uses per-process mappings for kseg2, i.e. that e.g. the first
> 2MB of (each) kseg2 are used  as page table of the corresponding process and
> maybe another few kb for process related stuff. Provided the page tables are
> continuously at the same address ( e.g. KSEG2_BASE ) a change of ASID in
> EntryHi would indeed make a change of the kseg2 pointer in Context
> unnecessary ( it always points to KSEG2_BASE ). The mapping of kseg2 would
> automatically change as the global bit is set to zero. 

Yes.  I think I recall that the first BSD4.3 ports for MIPS had a
fixed-virtual address per-process structure which was extended to
include the L2 page table.

> Using the standard page table approach I would now need an additional page
> table for each process in order to map those 2+x MB in kseg2 which I could
> put in kseg0/1 or in kseg2 with 'wired' TLB entries.
> 
> If that's the way to go - why is it only used in early BSD ports of like
> 1987 ? Are there any troubles with it or have other mechanisms turned out to
> be better for any reason ?

It's rather a lot of assumptions to build into architecture-dependent
code, not very flexible, not very SMP-friendly, and in other ways not
as scalable as one would like.

Current Linux systems accept more computation in the TLB miss
handler in order to use largely portable data structures for keeping
page tables.  You can always push at that trade-off...

--
Dominic Sweetman
MIPS Technologies



<Prev in Thread] Current Thread [Next in Thread>