From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [RFC][PATCH] eliminate extra tb_init_done check Date: Wed, 15 Oct 2008 16:54:53 +0100 Message-ID: <48F6124D.5020604@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Lu, Guanqun" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Well, I just tested ddk-build running inside a w2k3 box. This normally touches a lot of shadow code, which has a lot of tracing in it. For each configuration, I ran the build once to warm up the disk cache, then three more times for actual testing. No patch: 156s, 161s, 156s Patch: 161s, 156s, 156s So I'm not seeing a big impact from this change. Personally, I think I'd leave it as-is, because I don't like the idea of marshalling all that code and then not doing anything, but I think that's just a taste thing at this point. :-) -George Keir Fraser wrote: > On 15/10/08 07:20, "Lu, Guanqun" wrote: > >> Two corner conditions are left untouched. One is the assembly in entry.S, >> the other is the check of tb_init_done not immediately followed by >> __trace_var. >> >> Or more aggressively, we can eliminate all the extra checks, make tb_init_done >> a static variable, and rename __trace_var to trace_var which looks more like >> a right interface name. > > The macros check tb_init_done before calling __trace_var() to try and reduce > the cost of the common case (tracing disabled) as far as possible. Hence we > avoid a function call and computation of some arguments to that function. > > I don't know if we've actually measured teh performance win from this. If we > have, George would know about it. > > -- Keir > >