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 bdra...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
