From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 06/19] xen: credit2: read NOW() with the proper runq lock held Date: Thu, 7 Jul 2016 12:28:59 +0200 Message-ID: <1467887339.23985.48.camel@citrix.com> References: <146620492155.29766.10321123657058307698.stgit@Solace.fritz.box> <146620512051.29766.574756341169521466.stgit@Solace.fritz.box> <5767BDE502000078000F67E8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3565883958838308570==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bL6Yt-0001Yk-OR for xen-devel@lists.xenproject.org; Thu, 07 Jul 2016 10:29:39 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , Jan Beulich Cc: xen-devel , Anshul Makkar , David Vrabel List-Id: xen-devel@lists.xenproject.org --===============3565883958838308570== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-S7+PP/HxDlCy9SKNjJAI" --=-S7+PP/HxDlCy9SKNjJAI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-07-06 at 17:10 +0100, George Dunlap wrote: > On Mon, Jun 20, 2016 at 8:56 AM, Jan Beulich > wrote: > >=C2=A0 > > > > > On 18.06.16 at 01:12, wrote: > > > Yet another situation very similar to 779511f4bf5ae > > > ("sched: avoid races on time values read from NOW()"). > > >=20 > > > In fact, when more than one runqueue is involved, we need > > > to make sure that the following does not happen: > > > =C2=A01. take the lock of 1st runq > > > =C2=A02. now =3D NOW() > > > =C2=A03. take the lock of 2nd runq > > > =C2=A04. use now > > >=20 > > > as, if we have to wait at step 3, the value in now may > > > be stale when we get to use it at step 4. > > Is this really meaningful here? We're talking of trylocks, which > > don't > > incur any delay other than the latency of the LOCKed (on x86) > > instruction to determine lock availability. > This makes sense to me -- Dario? >=20 Yes, I think this patch is, after all, not really necessary. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-S7+PP/HxDlCy9SKNjJAI 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 iQIcBAABCAAGBQJXfi7rAAoJEBZCeImluHPuAj0QAMRhbumo5n0WFV0xLxZVq+8f hpeMpAK0WUh/ELRmOnss1SIjdcFleyCDa8Qym2+ES/nzQ4Hs/0qeW0cm/tEo3Wbc Spm39WQ7/4i4uBiZSvcRobimdysPEMh5Kl/cCqXayain5MARqpXjP/jRA33Ug19A TMIIJe6sqLHMsedAK0X5CDWFAgWKv4ifPYmoHQerrxhX1Jx924uAA4MaSDy2NKfw V3tOMgZbQuF5GeUgjXCZA6cj6EQJW7yZk4r+iG60aM2VTt8ezfdywmcNElthqu2Z d5x9Cfer9wxI5zKxN5FGKduwnL4gCBLuh6glDhsbIfo2QGUz6DCRGOiqDaei2gLJ B76SF0k7EFod2Ql9+9RPzRgYMPUU9f7yIojF2nnQzV87EdryFPG25NfsnVh7eN/t eVETpsi5XdGuQwn/q51EUOhJ2EUC/6kFcjHkLwzDD1wUJ9Qak3UFEYywMTkIieVq vLgunYl9gWs/Wh8Ly9JlQcCnRGGp6DHG9mX0TqlxWzznh8F52EGowNzPleg4a7k4 vMCZCkXEJyLR8VuAyNlFKqKgsnWQLiCK9tvgO+6kPf/wWRGc7vQObe3bPXG6Rm19 rtI3nBQzFc/JxTrWMTl3Ib4b2uo/2vNy8kVEGq0gHPQSn+L6Ulp47qqRbdYEixin BlRGxbTYqVgkC87p/U1x =YWeN -----END PGP SIGNATURE----- --=-S7+PP/HxDlCy9SKNjJAI-- --===============3565883958838308570== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3565883958838308570==--