From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 07/19] xen: credit2: prevent load balancing to go mad if time goes backwards Date: Thu, 7 Jul 2016 12:53:25 +0200 Message-ID: <1467888805.23985.62.camel@citrix.com> References: <146620492155.29766.10321123657058307698.stgit@Solace.fritz.box> <146620512780.29766.17654986428277031886.stgit@Solace.fritz.box> <5767BF3102000078000F6802@prv-mh.provo.novell.com> <577E20F902000078000FBD9E@prv-mh.provo.novell.com> <577E3AA002000078000FC087@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7757726865249191956==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bL6vz-0004gk-KE for xen-devel@lists.xenproject.org; Thu, 07 Jul 2016 10:53:31 +0000 In-Reply-To: <577E3AA002000078000FC087@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , George Dunlap Cc: xen-devel , Anshul Makkar , David Vrabel List-Id: xen-devel@lists.xenproject.org --===============7757726865249191956== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-/j2VvfAn8RD8dym107EN" --=-/j2VvfAn8RD8dym107EN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-07-07 at 03:18 -0600, Jan Beulich wrote: > > > > On 07.07.16 at 11:09, wrote: > > > Oh, okay - I agree on those two parts then. But the question on > > > the > > > usefulness of absolute vs relative times remains. > > What is the usefulness of printing the relative time?=C2=A0=C2=A0If you= have > > the > > absolute time, you have some chance of catching mistakes like one > > of the > > times being 0 or something like that; or of being able to correlate > > it > > with another time printed somewhere else (for instance, a timestamp > > from > > a trace record). > Well, having had to deal with time going backwards elsewhere > (both in the past and recently) I have always found it cumbersome > to work out the delta from huge (far into the billions) absolute > numbers, and therefore consider logging the delta more useful - > And, in general, I agree with you. In this case, however... > apart from seeing at the first glance whether a particular delta is > positive or negative, this also allows at almost the first glance to > at least recognize the magnitude of the difference. But anyway ... >=20 true, for the magnitude part, but in this case we are only logging anything if delta is negative. So the fact itself that there is something being logged, tells about the sign of the delta. And... > > In any case, I think it's really a bike shed.=C2=A0=C2=A0Dario is the o= ne who > > has > > used this error message to find an actual bug recently, so I'll let > > him > > decide what he thinks the most useful thing to print here is. > ... fine with me; it was just a question after all. >=20 ...I caught two bugs thanks to this. The (more recent) one about lack of monotonicity, having two absolute values or a delta would have been the same. For the other one (the fact that we were using stale time samples because we were calling NOW() and then [potentially] waiting for acquiring a lock) seeing that there were repeating occurrences of the same absolute value of now, did indeed helped both identifying and debugging the issue, while having just a delta wouldn't have been as effective. And I've also done what George refers to, i.e., look for the exact value printed in the trace record, to have an idea of what was happening, and again having absolutes revealed useful for this. So, yes, I think it's actually fine to leave the message as it is. 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) --=-/j2VvfAn8RD8dym107EN 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 iQIcBAABCAAGBQJXfjSlAAoJEBZCeImluHPux9gQAKqQQrYJJT5/tA0bu6FrJRpN QUg2w4oa75BAxr8KuJtsslCXJuO2sB8hakrZgfp//+BAxtmqfVOUUkdVhE/KtO86 k86Y886ta6sE8Vo7yg775uuvdhxBRUml1uTymmhK50X9nlT+7sb7D7ztc9mySsek i+xLx8o1nP6rCVArxNqLqhIBk8m7VtVX8brUWn+UskzvHwkPZEa+yorC9oR1LvZg c8XMoKLaMBZKSpuhgyLJs4wwgrshUukNbBYZGf9pWaQiy06kXJIhIo9Z0of33Isa 2Lg0sO4qr2JD5daUZiR/0gKyT6uvinZWt5cMP+WFtUh6CAPaWSo31ssfz1KM0Tu7 kcw1brVqILq/95HJvnN24xsNfzHTy2BVteUL7PwmRZrpEfQYSsQoH1aEXdWGEcLo CU7XAo2dde8Zcw6HvjwfcfVsKC6mnm6SIvwakui/8CEDp3eK8Kjrk49jODuyP7Pz s4OlORhJwnZ5kQsVyY1GWxVL1adwYkzr+1ZDPB49UwTSolGXRhNpqx6zi1Qh9mFx j1sFQSu2sjs75+8mxVlkEyjzh2D2/XF4d3doyl87b1C6PM+CzOoS54AvkuI/usYL KaqeQY7e4OCLlvQl3lgL8Vfm6efBKdMbrPK+OGMtu3515TBbhbrmMN15z+V3APND pyRJMR8sTSua/SWu3SNP =uy2Q -----END PGP SIGNATURE----- --=-/j2VvfAn8RD8dym107EN-- --===============7757726865249191956== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7757726865249191956==--