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>