Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[Brandon Bergren]

An update from my end: I now have the ability to test dual processor G4 as well, now that mine is up and running.

On Thu, Jun 11, 2020, at 4:36 PM, Mark Millard wrote:
> 
> How did you test?
> 
> In my context it was far easier to see the problem
> with builds that did not use MALLOC_PRODUCTION. In
> other words: jemalloc having its asserts tested.
> 
> The easiest way I found to get the asserts to fail
> was to do (multiple processes (-m) and totaling to
> more than enough to force paging/swapping):
> 
> stress -m 2 --vm-bytes 1700M &
> 
> (Possibly setting up some shells first
> to potentially later exit.)
> 
> Normally stress itself would hit jemalloc
> asserts. Apparently the asserts did not
> stop the code and it ran until a failure
> occurred (via dtv=0x0). I never had to
> manually stop the stress processes.
> 
> If no failures during, then exit shells
> that likely were swapped out or partially
> paged out during the stress run. They
> hit jemalloc asserts during their cleanup
> activity in my testing.
> 
> 
> > That said, the attached patch effectively copies
> > what's done in OEA6464 into OEA pmap.  Can you test it?
> 
> I'll try it once I get a chance, probably later
> today.
> 
> I gather from what I see that moea64_protect did not
> need the changes that you originally thought might
> be required? I only see moea_protect changes in the
> patch.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
>

-- 
  Brandon Bergren
  bdragon at FreeBSD.org