[staalmannen]

The threshold change worked: 2MB and 16MB mappings now take the malloc arm, none of the eight fail, and section 0b answers 64 / 64 / 64 instead of 64 / 5 / 5.

That is the right answer and worth keeping as a regression check -- mmap spends no slot at any size a program is likely to ask for -- but all three of 0b's cases are now on the SAME arm, so its smallest size has stopped being a control and a run of 64/64/64 says nothing about how many slots exist. Read on its own it looks exactly like the Linux control. A section whose cases have collapsed onto one path is a check that can only pass.

Section 0c asks the platform question of the platform: _SEGATTACH in a loop at 64KB until refused. Cheaper as well as still alive -- reaching the ceiling through mmap would now need 64MB mappings, and five of those is 320MB of real pages, since p9_mmap_impl memsets what it returns. It is the one place a test here reaches past the POSIX surface on purpose, because the number is a property of the kernel and going through mmap would measure the library's policy instead.

The header also records that section 0 is no longer measuring what it measured in the first run. A 2MB mapping is malloc-backed now, so it reports where the allocator puts things, not where segattach does -- 0x436000, 0x837000, 0xc37000 ... spaced 4MB apart at offset 0x37000. Both readings are true of their own run and neither describes the other; the 2MB grid off by one page was a fact about segattach and is no longer reachable from here. The conclusion is unchanged where it counts: still misaligned, so zend still trims, and section 1's head trim went from 0 to 0x1c8000, so the real path now exercises both trims rather than only the tail.

Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs