From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 5/5] xen: RCU: avoid busy waiting until the end of grace period. Date: Tue, 1 Aug 2017 00:03:41 +0200 Message-ID: <1501538621.30551.3.camel@citrix.com> References: <150114201043.22910.12807057883146318803.stgit@Solace> <150114249858.22910.4601418126082976816.stgit@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8010483153087175888==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dcIn2-00006N-Oz for xen-devel@lists.xenproject.org; Mon, 31 Jul 2017 22:03:52 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Jan Beulich , Andrew Cooper List-Id: xen-devel@lists.xenproject.org --===============8010483153087175888== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-X2YNq98G1B8q4e1MnsQl" --=-X2YNq98G1B8q4e1MnsQl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-07-31 at 14:20 -0700, Stefano Stabellini wrote: > On Thu, 27 Jul 2017, Dario Faggioli wrote: > >=20 > > diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c > > index f0fdc87..4586f2a 100644 > > --- a/xen/common/rcupdate.c > > +++ b/xen/common/rcupdate.c > > @@ -84,8 +84,14 @@ struct rcu_data { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int cpu; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct rcu_head barrier; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0long=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0last_rs_qlen;=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0/* qlen during the last > > resched */ > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0/* 3) idle CPUs handling */ > > +=C2=A0=C2=A0=C2=A0=C2=A0struct timer idle_timer; > > +=C2=A0=C2=A0=C2=A0=C2=A0bool idle_timer_active; > > =C2=A0}; > > =C2=A0 > > +#define RCU_IDLE_TIMER_PERIOD MILLISECS(10) >=20 > Isn't this a bit too short? How is it chosen? >=20 It's totally arbitrary (and that would be the case for whatever value we choose). Basically, it's how long, at worst, after the actual end of a grace period, a (batch of) callback(s) will be invoked. Currently, on Credit1 on ARM (without my patch, from this series, that suspends the tick) that's (by chance) 30 ms (or whatever value is chosen for Credit1 timeslice). On Credit2 (on both ARM and x86), it's never, but on x86 it (apparently) is 'however frequent time sync rendezvouses happs' (which I don't recall, but it's longer), while on ARM is (potentially) never. I accept suggestions about alternatives values, and I'm certainly fine with adding a comment, containing something along the lines of the explanation above, but I fear it's going to be hard to figure out what value is actually the "absolute best". In Linux (which is where the same 'callback book-keeping' happens for them), a tick with a frequency of 1000Hz (=3D=3D 1ms) is considered 'low- latency/Deskop/real-time'. For us, as said above, tick --when it's there-- would be 30ms by default. I just went with something in the middle. Also, it's not that we'll have a 10ms periodic timer going on for significant amount of time. In fact we expect it to actually fire just once (for each grace period). It's not 100% guaranteed that it won't be reprogrammed and fire a couple of times, but it should not, in the vast majority of cases. What makes you think it's short? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-X2YNq98G1B8q4e1MnsQl 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 iQIcBAABCAAGBQJZf6k+AAoJEBZCeImluHPuod4QAJE0pTiCgmPsSg6NzB4znXWG d9BUeTpgjCO4pudsTQeCd3XwcqIF7psoOfMLdmUP8KjnOliDaAy61YK2yr6tT+io oKiC5ozPq73iPA4aCxKmME/mrSTW+WkwwFL6/ZvilbB+CbtVvZEQE8ELlJf5Azv6 QB69ABi0KrUII+55ZjoJlT9G2lU3U9ewgjmiHo5VDDPiLtrgHYYh5ABjF0K14lYr ZLiXO4CY62Sy+m+rog+kK9lE+M8jCQXAgD/yRA+4lYYYRyUtAhDTS0IilqRsCFSF l9ONrLUCLGheFB5cQSPD6wl1PooRMXdccTCf1GBoTkW82yATMmyBD73i/MtwHjF8 nGJkp1bQV31Kc815knnsVGYCTCh/o8KLMkXfSGlawQUCPoDaNLk0h5O27bbFsDu8 Rq/lKVkpXSvlkeuXqfs2d3XYQM0EdtFOlwlofYfQS8lLz7ZLfBggvMZZWokGQv48 DdIX3X/T30QfAvb+KKIjCzdwPy+wxy7BFAgJyxsKJAjlSDivp+lTMRHyu5RomFjv 2FMTeGWhE5AG6ipwgmdx1etIvkG3T64Ej7GRXL5gCMNwtE1NCFt8baKI59/Y4pyx 9X7KfhTb1iSpBjnUmBNqmBp9beEi4UO2JViUKNXz7SFh5cYjpprgRNpTowFNuUhm ykyZB5N8CnLKeOU/6VVa =Iczq -----END PGP SIGNATURE----- --=-X2YNq98G1B8q4e1MnsQl-- --===============8010483153087175888== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8010483153087175888==--