the phrase "at least" in the text Tsubai quotes below is worth 
considering.  it seems we are using the minimal page table size;
does it matter?

two aspects to consider:

1. collisions & use of secondary hashing function -- 
   is this serialized behind the primary hash resulting 
   in longer lookup?  The PEM goes on to say: "...making the 
   page table larger... reduces the frequency of collisions".
   
2. overflow (trap to software miss handler) -- that's got to hurt.

has anyone measured cost/benefit of larger-than-minimum
page tables?  maybe the overall effect is too dependent
on the application mix to make a gneralization?

	-cliff-

---
cliff neighbors
allegro networks, inc.
cliff@allegronetworks.com
408-821-5532
---

-----Original Message-----
From: Tsubai Masanari [mailto:tsubai@iri.co.jp]
Sent: Thursday, August 10, 2000 6:35 AM
To: port-macppc@netbsd.org; port-powerpc@netbsd.org
Subject: Re: G4, 2GB RAM report (fwd)


>For folks only on port-powerpc, the current powerpc pmap doesn't size
>things well when the machine has 2GB of memory. It calculates the number
>of bytes in the system in an integer quantity. 2GB > INT_MAX, so bad
>things happen.

The Programming Environments Manual says:

7.6.1.2  Page Table Size

...
In a 32-bit implementation, the minimum size for a page table is 64 Kbytes
(2^10 PTEGs of 64 bytes each). However, it is recommended that the total
number of PTEGs in the page table be at least half the number of physical
page frames to be mapped. While avoidance of hash collisions cannot be ...

So,

	if (physmem < 0x800)
		ptab_cnt = 0x400;
	else {
#ifdef HTABENTS
		ptab_cnt = HTABENTS;
#else
		ptab_cnt = (physmem + 1) / 2;
		/* Align 2^n. */
		for (i = 0; i < 32; i++)
			if ((1U << i) >= ptab_cnt) {
				ptab_cnt = 1 << i;
				break;
			}
#endif /* HTABENTS */
	}

Comments?