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

[Mark Millard]

On 2020-Jun-11, at 14:41, Brandon Bergren <bdragon at FreeBSD.org> wrote:

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

Cool.

FYI:

Dual processors are not required for the
problem to happen: the stress based testing
showed the problem just as easily on the
single-socket/single-core contexts that I
tried.

> 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)