Date: Sun, 9 Apr 2017 17:10:09 -0700 From: Mark Millard <markmi@dsl-only.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them Message-ID: <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> In-Reply-To: <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> =
wrote:
>=20
>> Hmm, could you try the following patch, I did not even compiled it.
>=20
> I'll try it later today.
>=20
>> 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 +=3D L3_SIZE) {
>> l3 =3D 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.)
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89D6D677-3BE2-45E2-A902-CC6A0305F3F9>