The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them

[Alan Cox]

On Sun, Apr 9, 2017 at 7:10 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Apr-9, at 10:24 AM, Mark Millard <markmi at dsl-only.net> wrote:
>
> > On 2017-Apr-9, at 5:27 AM, Konstantin Belousov <kostikbel at gmail.com>
> wrote:
>
> >
> >> Hmm, could you try the following patch, I did not even compiled it.
> >
> > I'll try it later today.
> >
> >> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
> >> index 3d5756ba891..55aa402eb1c 100644
> >> --- a/sys/arm64/arm64/pmap.c
> >> +++ b/sys/arm64/arm64/pmap.c
> >> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva,
> vm_offset_t eva, vm_prot_t prot)
> >>                  sva += L3_SIZE) {
> >>                      l3 = pmap_load(l3p);
> >>                      if (pmap_l3_valid(l3)) {
> >> +                            if ((l3 & ATTR_SW_MANAGED) &&
> >> +                                pmap_page_dirty(l3)) {
> >> +                                    vm_page_dirty(PHYS_TO_VM_PAGE(l3 &
> >> +                                        ~ATTR_MASK));
> >> +                            }
> >>                              pmap_set(l3p, ATTR_AP(ATTR_AP_RO));
> >>                              PTE_SYNC(l3p);
> >>                              /* XXX: Use pmap_invalidate_range */
>
>
> Preliminary testing indicates that this fixes the
> some-pages-become-zero problem for fork-then-swapout/in.
>
> Thanks!
>
> I'll see if a buildworld can go through without being stopped
> by the type of issue. But that will take a while. (It is how
> I originally ran into the problem(s) that others had been
> reporting on the lists.)
>
>
> Side notes:
>
> The decreasing-RES(ident memory) behavior was unchanged.
>
> The "child gets only 80K RES initially" behavior was also
> unchanged.
>
>
That is because the arm64 pmap doesn't implement pmap_copy().


> (These are as shown by "top -PCwaopid" . These are just
> differences with what I see for other TARGET_ARCH's.)
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>