From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [PATCH 5/5] xen: RCU: avoid busy waiting until the
 end of grace period.
Date: Thu, 10 Aug 2017 15:55:33 +0200
Message-ID: <1502373333.5719.29.camel@citrix.com>
References: <150114201043.22910.12807057883146318803.stgit@Solace>
 <150114249858.22910.4601418126082976816.stgit@Solace>
 <59882AB402000078001038E0@prv-mh.provo.novell.com>
 <1502300045.5719.23.camel@citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8891041139664759148=="
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta6.messagelabs.com ([193.109.254.103])
 by lists.xenproject.org with esmtp (Exim 4.84_2)
 (envelope-from <prvs=388de1047=dario.faggioli@citrix.com>)
 id 1dfnwA-0005e7-Bu
 for xen-devel@lists.xenproject.org; Thu, 10 Aug 2017 13:55:46 +0000
In-Reply-To: <1502300045.5719.23.camel@citrix.com>
List-Unsubscribe: <https://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, julien.grall@arm.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

--===============8891041139664759148==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="=-Auuk3ZDH8b9mz2aZfpzO"

--=-Auuk3ZDH8b9mz2aZfpzO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2017-08-09 at 19:34 +0200, Dario Faggioli wrote:
> On Mon, 2017-08-07 at 02:54 -0600, Jan Beulich wrote:
> > > > > Dario Faggioli <dario.faggioli@citrix.com> 07/27/17 10:01 AM
> > > +/*
> > > + * Timer for making sure the CPU where a callback is queued does
> > > + * periodically poke rcu_pedning(), so that it will invoke the
> > > callback
> > > + * not too late after the end of the grace period.
> > > + */
> > > +void rcu_idle_timer_start()
> > > +{
> > > +=C2=A0=C2=A0=C2=A0=C2=A0struct rcu_data *rdp =3D &this_cpu(rcu_data)=
;
> > > +
> > > +=C2=A0=C2=A0=C2=A0=C2=A0if (likely(!rdp->curlist))
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return;
> >=20
> > I would have expected this to be the inverse of the original
> > condition in
> > rcu_needs_cpu() - why is there no rcu_pending() invocation here?
> >=20
>=20
> [...]
>
> Actually, it's entirely possible that it is having rcu_pending(cpu)
> in
> rcu_needs_cpu() is, for us, redundant. In fact, although it does make
> sense in Linux, both code inspection and some investigation I've just
> done, makes me believe that there won't be cases where a CPU is
> denied
> going offline because it sees rcu_pending() returning 1.
>=20
> In fact, when we call rcu_pending(), within cpu_is_haltable(), we
> have
> already gone through it before. And if there were pending work, we've
> raised the softirq and dealt with it. If there weren't, neither there
> is now.
>=20
> I'm therefore leaning toward removing rcu_pending() from the
> rcu_needs_cpu() check as well. At that point, we'll indeed have the
> check inside rcu_start_idle_timer(), be the opposite of the original
> check in rcu_needs_cpu(). :-)
>=20
FTR, I'm not so sure of this last thing any longer. I mean, the
analysis I provided is still correct, but I'm investigating the other
possible race existing in the code that Tim has hinted at in his mail,
and I think it could be useful to have rcu_pending() checked in here,
to solve/avoid that one.

It's also possible that I'll actually remove it from rcu_needs_cpu(),
but to move it somewhere else... As I said, I'm still looking into the
problem.

Regards,
Dario
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
--=-Auuk3ZDH8b9mz2aZfpzO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJZjGXWAAoJEBZCeImluHPuQjoQAOhEa6hvVEeOhLspHo7XVKhE
5oPN2IHOvMjW6Fy2NR4MR70qur2FWwOuRXtZBrNjyAZulVTdfMs1VEl20jz7E0Sc
Y1ZFARli1//MtxWJj+BYrmxTFFuKUdbWVWvqWsxmCuMsn5/D5BmakCL3bFFHsbNQ
mhaBO0P1+OJSGT2a9tc/55LfdU9KHWCyxik2BAfnbJZtmhbUTzOkVAGS0lSIZ+J8
E1GyKevNvox+YJQHjDtDUeiaHNWs8C61tNt+j5Z0iIuoenLhODxDwr6Elf5LV9MG
N8wgg1WKsDXcs2DOnjXnum8BHVc3YVAsQX8E5gy7EFu0dCyNxLcu06eOG0yvyz1F
vwDSN3tiq462KDOFhEXSYhDtoqAHpAEYUfE+jFJxyiRWU5/BfZ7cKbXuZ4we3/fv
sVGvgQUBs7t1jf0ATsvLKzk5NANvanue3CmjWwxzkiE1LHs8bTwThLibUkJQUFLs
9z2NqDwZ7e4Wc+id/WomtHObgYJsPYJVRYeGToWi0mNVLoViDXDtac3aS3JPOkZ/
zs8+sON6RTk8bR0m+4MGHvOLw4N4jHukDSt4fVXzyCwfrF01LPUUbCk6bhCRzlZV
GgjZF07t5fmdzjg7wdv83oNG2FVidFTJ0Bn7+Sa7WN+tG0L0DvrcxXKAtk9HYQxs
og4O6hpmVjrEcyrmdvek
=RQlV
-----END PGP SIGNATURE-----

--=-Auuk3ZDH8b9mz2aZfpzO--


--===============8891041139664759148==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============8891041139664759148==--