svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311
Justin Hibbits
chmeeedalf at gmail.com
Thu Jun 11 21:42:23 UTC 2020
On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Jun-11, at 13:55, Justin Hibbits <chmeeedalf at gmail.com>
> wrote:
>
> > On Wed, 10 Jun 2020 18:56:57 -0700
> > Mark Millard <marklmi at yahoo.com> wrote:
> >
> >> On 2020-May-13, at 08:56, Justin Hibbits <chmeeedalf at gmail.com>
> >> wrote:
> >>> Hi Mark,
> >>
> >> Hello Justin.
> >
> > Hi Mark,
>
> Hello again, Justin.
>
> >>
> >> I've been avoiding the old PowerMacs and leaving
> >> them at head -r360311 , pending an update that
> >> would avoid the kernel zeroing pages that it
> >> should not zero. But I've seen that you were busy
> >> with more modern contexts this last about a month.
> >>
> >> And, clearly, my own context has left pending
> >> (for much longer) other more involved activities
> >> (compared to just periodically updating to
> >> more recent FreeBSD vintages).
> >>
> >> . . .
> >>
> >
> > Sorry for the delay, I got sidetracked with a bunch of other
> > development.
>
> > I did install a newer FreeBSD on my dual G4 and couldn't
> > see the problem.
>
> 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.
My testing was only with a WITNESS kernel, and wasn't an exhaustive
test, so obviously is not a straight apples-to-apples comparison.
Unfortunately, my backlog of other work got in the way of doing a
meaningful extensive test.
>
>
> > 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.
The wording was a little ambiguous. I had meant to convey that I was
looking at mmu_oea64.c for inspiration for what's missing in mmu_oea.c.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
- Justin
More information about the svn-src-head
mailing list