Re: kern/57621 (Updated 10.0_BETA macppc MP kernel prone to hangs)

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

It turned out that my "fix" for pmap.c, v.1.115 breaks G5
(OEA64_BRIDGE). struct pmap should be in the direct-mapped
memory, and only the 0th 256MiB segment is direct-mapped
for OEA64_BRIDGE; they do not have BATs and therefore
direct-mapping requires PTEs (i.e., relatively expensive).

However:

(1) 256MiB limit should be too restrictive, which may
results in the stall reported by this PR. See rough
estimation below (*).

Also:

(2) OEA and OEA64_BRIDGE has only 512MiB of kernel
virtual space (13rd and 14th SRs).

For OEA, up to 3GiB memory (0th to 11th SRs, 12th SR is
reserved for copy{in,out}) is directly-mapped, and therefore
allocation from this region does not consume kernel address
space. However, for OEA64_BRIDGE, we need to map everything
within this 512MiB region.

Therefore, I will, at least temporarily for 10.0, directly
map up to 3GiB of physical memory also for OEA64_BRIDGE.
This consumes PTEs, but it should be much better than
(1) stall in pmap_create, or (2) kernel va starvation.

With series of commits, my Mac Mini G4 and Power Mac G5
(late 2005, DP) successfully build some memory-consuming
packages, including lang/rust and lang/clang, with
MAKE_JOBS=2 and 4, respectively.

I will send pullup request to netbsd-10 asap, after next
successful snapshot build for -current.

As a long-term challenge, it must be definitely better to
drastically rewrite low level routines for powerpc,
especially pmap.

(*)
As vendors recommend,

	(# of PTEG) = (# of physical pages) / 2,

round-up'ed to power of 2.

Consider the case of 2GiB of physical memory, we have 2^18 PTEG.
As each PTEG has 8 PTEs, we have 2^21 = 2Mi PTEs, which can map
8GiB of memory.

In order to manage 2Mi PTEs, we need

	sizeof(struct pvo_entry) * 2Mi = 80MiB

for OEA64_BRIDGE (**). We also have page table itself (16MiB),
kernel image, struct pmap, etc., in the 1:1 mapped segment.

(**)
After pmap_pvo_pool fix, will be committed soon.