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

Mark Millard markmi at dsl-only.net
Mon Apr 10 20:16:00 UTC 2017


On 2017-Apr-10, at 2:51 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Apr-9, at 5: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.)
> 
> buildworld buildkernel completed non-stop for the first time
> on a BPI-M3 board.

I had been thinking of the BPI-M3 for other reasons
and typed that instead of the correct: Pine64+ 2GB.
(True elsewhere as well.) I do really mean arm64
here, not armv7.

> Looks good for a check-in to svn to me (head and stable/11).
> 
> This combined with 2017-Feb-15's -r313772's fix to the fork
> trampline code's updating of sp_el0 makes arm64 far more stable
> for my purposes.
> 
> -r313772 was never MFC'd to stable/11. In my view it should be.

===
Mark Millard
markmi at dsl-only.net



More information about the freebsd-hackers mailing list