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

[Mark Millard]

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.

(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