Re: Weird calculation for kernel L2 segment table

Ignatios Souvatzis <[email protected]>
Newsgroups gmane.os.netbsd.ports.amiga,gmane.os.netbsd.ports.m68k,gmane.os.netbsd.ports.atari
Message-ID <[email protected]>
On Sat, Jan 03, 2009 at 11:47:56AM +0900, Izumi Tsutsui wrote:

> The traditional hp300 derived pmap (designed for 68851 and HP MMU)
> uses two level table lookups for address translation.
> The first one is the segment table and the second is the page table.
> (there is a simple doc in arch/hp300/DOC/HPMMU.notes)
> 
> On 4kbytes/page systems (hp300 etc.), both have 1024 entries.
> On 8kbytes/page systems (i.e. on amiga and atari),
> the segment table has 256 entries and the page table has 2048
> (== NPTEPG == PAGE_SIZE / sizeof(pt_entry_t)) entries.
> (I don't know why these two traditional ports use different PAGE_SIZE)

I guess, because we can.

The 68030 MMU has only 22 TLB entries - although I never benchmarked
the effect, I felt that covering twice the VM with them would reduce
the pmap code traps. (I didn't *change* to 8k - it was that way when
I first looked tat the code).

(also from memory: 68851 has 64 TLB entries. Don't remember what 
68040 and 68060 have.)

HP300 has, I think, a motorola mmu like hardware built by HP, so it 
can only do 4k.

Somebody please correct me if I'm wrong.

	-is
-- 
seal your e-mail: http://www.gnupg.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.