Date: Wed, 22 May 2019 18:50:10 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org>, Mark Johnston <markj@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me - second potential problem Message-ID: <94d051a3-3427-7a5b-efe7-169cff2265d3@FreeBSD.org> In-Reply-To: <28c7430b-fb7c-6472-5c1b-fa3ff63a9e73@FreeBSD.org> References: <369cb1e9-f36a-a558-6941-23b9b811825a@FreeBSD.org> <20190520164202.GA2130@spy> <28c7430b-fb7c-6472-5c1b-fa3ff63a9e73@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BlV7hosPIwYhYCaZHvapg666riVhkmAeN Content-Type: multipart/mixed; boundary="JQ4hsq8GWofW47oUNQaui45CORKWOjTpL"; protected-headers="v1" From: Lev Serebryakov <lev@FreeBSD.org> Reply-To: lev@FreeBSD.org To: Alexander Motin <mav@FreeBSD.org>, Mark Johnston <markj@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <94d051a3-3427-7a5b-efe7-169cff2265d3@FreeBSD.org> Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me - second potential problem References: <369cb1e9-f36a-a558-6941-23b9b811825a@FreeBSD.org> <20190520164202.GA2130@spy> <28c7430b-fb7c-6472-5c1b-fa3ff63a9e73@FreeBSD.org> In-Reply-To: <28c7430b-fb7c-6472-5c1b-fa3ff63a9e73@FreeBSD.org> --JQ4hsq8GWofW47oUNQaui45CORKWOjTpL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 22.05.2019 18:19, Alexander Motin wrote: >>> But looks like `arc_kmem_reap_soon()` is synchronous on FreeBSD! So,= >>> this `delay()` looks very wrong. Am I right? >=20 > Why is it wrong? One second pause after synchronous operation to wait it completion? There one more questionable piece of code: 6936 static void 6937 arc_lowmem(void *arg __unused, int howto __unused) 6938 { =2E... 6947 arc_reduce_target_size(to_free); 6948 =09 6949 mutex_enter(&arc_adjust_lock); 6950 arc_adjust_needed =3D B_TRUE; 6951 zthr_wakeup(arc_adjust_zthr); 4587 static void 4588 arc_reduce_target_size(int64_t to_free) 4589 { =2E.. 4612 if (asize > arc_c) { 4613 DTRACE_PROBE2(arc__shrink_adjust, uint64_t, asize, 4614 uint64_t, arc_c); 4615 /* See comment in arc_adjust_cb_check() on why lock+flag */ 4616 mutex_enter(&arc_adjust_lock); 4617 arc_adjust_needed =3D B_TRUE; 4618 mutex_exit(&arc_adjust_lock); 4619 zthr_wakeup(arc_adjust_zthr); 4620 } 4621 } Looks like lock/flag/wakeup sequence (which is now very cheap =E2=80=94 = mutexes are not cheap, and this mutex could become contended in low-memory situation) could be called twice. Looks like `arc_reduce_target_size()` should return boolean value and unconditional signalling in `arc_lowmem()` should become conditional. --=20 // Lev Serebryakov --JQ4hsq8GWofW47oUNQaui45CORKWOjTpL-- --BlV7hosPIwYhYCaZHvapg666riVhkmAeN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlzlb7JfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R48Euw/8DRFP4xmKsRGd0YSZC8HIxEi2Sk7PvgPe6IH4bOMDyJac85OlNl+ME82J pyLA9smqMktiApB8u0phtI6qciM91fQsmfJiBfEwWCNywXTKp0RsQ6ItimYPLaq4 PLkm8L/ldI5JjJXlGw6lEIJznWsmF4ZwGxjbev3ET+4PNkIJVSySJUG46suVL8SQ noxSpM9FZyYcwAho3NQ+q0MhaBqnYFiTQyK+yKFyNoK6XBbdaSI87VlYjeSmqeao F28qyTCUmOqbqp1vmKEAgqdxjpFGG+fp2/2nn2wqg4AyF61omRST7oSKwByDcBD4 X7z6RcniB4GVaGpGlzCZA48CwsNuYsZiIP1iuBYc876UNFvTJVRn9UuUb2zsMYRS 67Meq84DLWbwm7wACO8CB8RF3DwOQ1d10G0qfKmqzl9hx6sMRnIKKmZIN/HJgpNI 7QZrPpS8VZrYpoW8u0bvIsP9CqpUjFnD1WGyA1HOXeMaDspPlrKH1wF1E9MrpvqT 8xA7OYdKkdAEvia9OszerJz0YLtZTukQxDPPPPigR9twFAr2IKRJ7nzrfojjhVRL p0XPYuBzukhZRs+uecc+Zy+LjnszwcLJclDyE7yk7fvg8EjE1Rl6ux4h8jV7HrXa YRq1cc1hHO2cM3xvdo68IkB/5X4xjkX5C1fEuDZVzubokV6eilw= =wRGm -----END PGP SIGNATURE----- --BlV7hosPIwYhYCaZHvapg666riVhkmAeN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94d051a3-3427-7a5b-efe7-169cff2265d3>