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

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

The following reply was made to PR kern/57621; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost, he%NetBSD.org@localhost
Cc: netbsd-bugs%NetBSD.org@localhost, Martin Husemann <martin%duskware.de@localhost>,
 macallan1888%gmail.com@localhost
Subject: Re: kern/57621 (Updated 10.0_BETA macppc MP kernel prone to hangs)
Date: Fri, 15 Dec 2023 18:26:11 +0900

 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.