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