[GH-ISSUE #82] kernel (ppc): hashed page table stops growing at 4MB, undersized above 512MB of RAM #75

New issue

Closed

opened 2026-11-03 22:03:48 -07:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-11-03 22:03:48 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/82

Summary

On ppc, pmap_bootstrap() (src/kernel-7/machdep/ppc/pmap.c) stops growing the hashed page table at 4MB, so machines with more than about 512MB of RAM get an undersized table. The loop bound looks like a typo:

hash_table_size = 64*1024; rounded_mem_size = 8*1024*1024;
while (hash_table_size < 32*1024*104 &&     /* 3,407,872: 32*1024*1024 intended? */
       rounded_mem_size < mem_size) {
	hash_table_size *= 2; rounded_mem_size *= 2;
}

32*1024*104 is 3,407,872, so the loop stops after it reaches 4MB. The clamp further down in the same block uses 32*1024*1024 (if (hash_table_size > 32*1024*1024 || hash_table_size == 0) hash_table_size = 32*1024*1024;), which suggests a 32MB maximum was intended.

Effect

The table should grow with RAM: 64KB per 8MB, the ratio the loop itself starts from and the PowerPC Programming Environments sizing table follows. Instead it stays at 4MB:

RAM	Size the loop is aiming for	What it gets
512MB	4MB	4MB
1GB	8MB	4MB
2GB	16MB	4MB

The pool of struct mapping entries is sized from the table (mapping_table_size = sizeof(struct mapping) * (hash_table_size/sizeof(pte_t))), so it is capped as well. When the pool runs out, pmap_reap_mappings() reclaims entries, so this should cost speed rather than correctness: more PTEG overflow, more evictions and more page-table refills under load.

The non-power-of-2 adjustment that follows the loop, and its special case for 2–3GB, also start from the capped value.

Suggested fix

Change the bound to 32*1024*1024, then check the sizes printed for 512MB, 1GB and 2GB guests. QEMU mac99 goes up to 2GB.

Found by reading the code while comparing the ppc and i386 memory models; not yet reproduced on a guest.

Originally created by @raynorpat on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/82 ## Summary On ppc, `pmap_bootstrap()` (`src/kernel-7/machdep/ppc/pmap.c`) stops growing the hashed page table at 4MB, so machines with more than about 512MB of RAM get an undersized table. The loop bound looks like a typo: ```c hash_table_size = 64*1024; rounded_mem_size = 8*1024*1024; while (hash_table_size < 32*1024*104 && /* 3,407,872: 32*1024*1024 intended? */ rounded_mem_size < mem_size) { hash_table_size *= 2; rounded_mem_size *= 2; } ``` `32*1024*104` is 3,407,872, so the loop stops after it reaches 4MB. The clamp further down in the same block uses `32*1024*1024` (`if (hash_table_size > 32*1024*1024 || hash_table_size == 0) hash_table_size = 32*1024*1024;`), which suggests a 32MB maximum was intended. ## Effect The table should grow with RAM: 64KB per 8MB, the ratio the loop itself starts from and the PowerPC Programming Environments sizing table follows. Instead it stays at 4MB: | RAM | Size the loop is aiming for | What it gets | | --- | --- | --- | | 512MB | 4MB | 4MB | | 1GB | 8MB | 4MB | | 2GB | 16MB | 4MB | The pool of `struct mapping` entries is sized from the table (`mapping_table_size = sizeof(struct mapping) * (hash_table_size/sizeof(pte_t))`), so it is capped as well. When the pool runs out, `pmap_reap_mappings()` reclaims entries, so this should cost speed rather than correctness: more PTEG overflow, more evictions and more page-table refills under load. The non-power-of-2 adjustment that follows the loop, and its special case for 2–3GB, also start from the capped value. ## Suggested fix Change the bound to `32*1024*1024`, then check the sizes printed for 512MB, 1GB and 2GB guests. QEMU mac99 goes up to 2GB. Found by reading the code while comparing the ppc and i386 memory models; not yet reproduced on a guest.

gitea-mirror

2026-11-03 22:03:48 -07:00