From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 03/14] xen: sched: fi position of TRC_SCHED_DOM_{ADD, REM} Date: Mon, 15 Feb 2016 17:37:05 +0100 Message-ID: <1455554225.14334.57.camel@citrix.com> References: <20160205183137.4543.56523.stgit@Solace.station> <20160205183349.4543.23589.stgit@Solace.station> <20160215162205.GC4697@char.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6465553125825787699==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aVM9m-0004eD-6O for xen-devel@lists.xenproject.org; Mon, 15 Feb 2016 16:37:50 +0000 In-Reply-To: <20160215162205.GC4697@char.us.oracle.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: Konrad Rzeszutek Wilk Cc: George Dunlap , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============6465553125825787699== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0ClVKHuChHkSuPuj2l0K" --=-0ClVKHuChHkSuPuj2l0K Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-02-15 at 11:22 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:33:50PM +0100, Dario Faggioli wrote: >=20 > On the title you have 'fi', but I think you meant 'fix'. >=20 Indeed, sorry for that. > > so that they actually live in the functions that > > do the scheduling related domain initialization and > > destruction. > >=20 > > Signed-off-by: Dario Faggioli >=20 > .. would it make sense to have an overall high-level > 'DOM_ADD' and 'DOM_REM' trace ? >=20 > Especially as it is useful for figuring out how long > an domain destruction takes time (based on the initial > trace to say this TRC_SCHED_REM)? >=20 I think it makes sense, and I can either do this in this patch (and resend) or as a follow up. I guess the only possible concern is that we may introduce too much tracing, to the point that it hurts performance, even when not enabled. (I was starting to think about this anyway, as I've got other series, either posted or in my queues, that adds a few more tracepoints, because they're so damn useful! ;-P) In that case, I guess we could think of doing something similar to what ftrace does in Linux --for disabling and enabling tracing and tracepoints-- which should be more lightweight than what we do. In any case, none of this applies to a "DOM_ADD" / "DOM_REM" tracing events. :-) 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) --=-0ClVKHuChHkSuPuj2l0K 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 iEYEABECAAYFAlbB/rEACgkQk4XaBE3IOsSIPQCbBgceEpE+glpSJmmW6P9Sw0DE mOEAn2B5uu6OIO+pKlQj45A5Ln3+kjwv =fzgR -----END PGP SIGNATURE----- --=-0ClVKHuChHkSuPuj2l0K-- --===============6465553125825787699== 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 --===============6465553125825787699==--