From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] sched_credit: Remove cpu argument to __runq_insert() Date: Tue, 3 Nov 2015 22:22:14 +0100 Message-ID: <1446585734.3829.84.camel@citrix.com> References: <1446217794-22320-1-git-send-email-write.harmandeep@gmail.com> <5633A7FE02000078000B04EB@prv-mh.provo.novell.com> <1446222826.28782.156.camel@citrix.com> <5633B03F02000078000B0599@prv-mh.provo.novell.com> <5638B8E502000078000B141B@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3718024157611289955==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ztj27-0007SB-Kz for xen-devel@lists.xenproject.org; Tue, 03 Nov 2015 21:22:23 +0000 In-Reply-To: <5638B8E502000078000B141B@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , George Dunlap Cc: xen-devel , Keir Fraser , Harmandeep Kaur , Tim Deegan List-Id: xen-devel@lists.xenproject.org --===============3718024157611289955== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2037KJg3MPIehuj23J8r" --=-2037KJg3MPIehuj23J8r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-11-03 at 05:38 -0700, Jan Beulich wrote: > > > > On 03.11.15 at 11:16, wrote: > > So you agree that this change makes the source code make more sense > > ("looks like an improvement at the source level"), but you think > > that > > this will make the compiled code less efficient; and you recommend > > instead of making the source code clearer, to make things even > > *better* by changing the BUG_ON() to an ASSERT? > >=20 > > Why do you think the compiler output will be less efficient? >=20 > Due to the two extra memory references, which the compiler is > unlikely to be able to eliminate in all cases?. >=20 Right. I had a quick look at the assembly code, and I think I saw something like that. As far as I've seen, though, the text sections of the generated binaries --with and without this patch-- were equally big (due to alignment, I think). Also, for the reasons explained here: http://lists.xen.org/archives/html/xen-devel/2015-11/msg00051.html As far as I'm concerned, this patch is: Acked-by: Dario Faggioli That being said... > > Overall I think the burden of proof is on you to show that the code > > as > > it is introduces a sufficient performance improvement over the more > > readable code, rather than on Harmandeep (or Dario or I) to show > > that > > it doesn't. >=20 > Okay, so far I thought people suggesting a change are the ones > to prove that the change doesn't have undesirable effects.=20 > ...just FTY, I probably will try having a look at what it means to make __runq_insert() non-inline. But that's another patch. :-) 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) --=-2037KJg3MPIehuj23J8r 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 v1 iEYEABECAAYFAlY5JYcACgkQk4XaBE3IOsQMEwCfbXUjG4eqZN8g2WQ4/WVFRUG1 E+cAn2ijj7SfUItbezgCas80IlNHWc5m =mVMq -----END PGP SIGNATURE----- --=-2037KJg3MPIehuj23J8r-- --===============3718024157611289955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3718024157611289955==--