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.orgReceived on Thu Jun 11 2020 - 19:42:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC