From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Gardner Subject: Re: unconditionally enable the trace buffer Date: Fri, 28 Oct 2005 00:45:37 -0600 Message-ID: <4361C911.4070301@hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Ian Pratt Cc: xen-devel@lists.xensource.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org Ian Pratt wrote: >>>>* ability to turn on/off via hypercall >>>> >>>> >>>Not currently implemented, but would not be difficult to add. >>> >>> >>Just as an aside I'm not sure this matters: From what Rob's >>told me, having the (inline) trace() calls in there produces >>the same overhead whether tracing is active or not. I guess >>it makes sense; once you've incurred the overhead of having >>the function there and evaluating the "is tracing on" >>conditional, you might as well have stored a few values also ;-) >> >> >We could cache miss on reading the tracebuffer producer counter and >tracebuffer base address, so its not totally a done deal. > >I don't have a big worry about performance, but I'd feel more >comfortable to see a more realistic assesment of overhead. Comparing >results from ttcp in a domU with 128k sock buf and the MTU set to 552 >bytes should do it. > > I just completed some benchmarks using ttcp as Ian suggests. I was surprised by the results, but essentially, Ian's intuition n this case may be right on the money. I tested three cases: 1. trace buffers turned off, that is not compiled in 2. trace buffers compiled in and turned on 3. trace buffers compiled in but disabled Cases 1 and 3 show no performance difference at all, but case 2 does show a non-trivial degradation. Details of the benchmarking: ttcp using 128k buffers to send data to a domU from another machine using a gigabit network. 2gb were transferred in each run, and 10 runs were performed for each case. Dom0 and domU together used up just about all of a cpu, and experienced 2000-2500 context switches per second to handle 40-50,000 I/O's per second. Please note that the additional trace events for XenMon were enabled in this system (case 2) so each of those 50,000 I/O's each second generates a trace record! I conclude the following from this: - there is no penalty for simply having the trace buffer code compiled into xen - there is a penalty for enabling tracing - therefore, the ability to turn tracing on/off via a hypercall is definitely important Rob