Date: Thu, 11 Jun 2020 15:04:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brandon Bergren <bdragon@FreeBSD.org> Cc: Justin Hibbits <chmeeedalf@gmail.com>, Eric van Gyzen <vangyzen@FreeBSD.org>, svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-ID: <1C6209E6-E980-407B-B635-B76C5F192E8C@yahoo.com> In-Reply-To: <8bf74674-4ccf-4f97-bbc5-fa5131209b66@www.fastmail.com> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <DCABCD83-27B0-4F2D-9410-69102294A98E@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <F5953A6B-56CE-4D1C-8C18-58D44B639881@yahoo.com> <D0C483E5-3F6A-4816-A6BA-3D2C82C24F8E@yahoo.com> <C440956F-139E-4EF7-A68E-FE35D9934BD3@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <B1225914-43BC-44EF-A73E-D06B890229C6@yahoo.com> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <8bf74674-4ccf-4f97-bbc5-fa5131209b66@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> How did you test? >>=20 >> 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. >>=20 >> 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): >>=20 >> stress -m 2 --vm-bytes 1700M & >>=20 >> (Possibly setting up some shells first >> to potentially later exit.) >>=20 >> Normally stress itself would hit jemalloc >> asserts. Apparently the asserts did not >> stop the code and it ran until a failure >> occurred (via dtv=3D0x0). I never had to >> manually stop the stress processes. >>=20 >> 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. >>=20 >>=20 >>> That said, the attached patch effectively copies >>> what's done in OEA6464 into OEA pmap. Can you test it? >>=20 >> I'll try it once I get a chance, probably later >> today. >>=20 >> 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1C6209E6-E980-407B-B635-B76C5F192E8C>