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/