Hello, what is the reason for the empty tsc for some xentracing calls, like TRC_HVM_IOPORT_READ? It makes sorting the resulting logfile by tsc value difficult because the 0 entries end up at the beginning of the logfile. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Aug 31, Olaf Hering wrote:> what is the reason for the empty tsc for some xentracing calls, like > TRC_HVM_IOPORT_READ? > It makes sorting the resulting logfile by tsc value difficult because > the 0 entries end up at the beginning of the logfile.This change appears to work for me. So, what is the reason for the cycles parameter to trace_var()? --- xen-4.0.1-testing.orig/xen/common/trace.c +++ xen-4.0.1-testing/xen/common/trace.c @@ -631,6 +631,7 @@ void __trace_var(u32 event, bool_t cycle if( !tb_init_done ) return; + cycles = 1; /* Convert byte count into word count, rounding up */ extra_word = (extra / sizeof(u32)); if ( (extra % sizeof(u32)) != 0 ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2010-Sep-30 09:56 UTC
Re: [Xen-devel] no cycles for certain xentrace entries
The reason for the parameter is that cycles take up space, and are often redundant information. An HVM_IOPORT_READ, for example, will always occur shortly after a VMEXIT and before a VMENTER, both of which have cycles. Adding the cycles parameter doubles the size of that record. When taking long traces, every little bit of space saving helps. Have you tried using xenalyze to analyze your trace? http://xenbits.xensource.com/ext/xenalyze.hg It does all the hard work of sorting by TSC value, including trying to infer tsc drift. It''s designed to handle records that don''t have a tsc value in a reasonable way. -George On Wed, Sep 29, 2010 at 9:09 AM, Olaf Hering <olaf@aepfle.de> wrote:> On Tue, Aug 31, Olaf Hering wrote: > >> what is the reason for the empty tsc for some xentracing calls, like >> TRC_HVM_IOPORT_READ? >> It makes sorting the resulting logfile by tsc value difficult because >> the 0 entries end up at the beginning of the logfile. > > This change appears to work for me. > So, what is the reason for the cycles parameter to trace_var()? > > --- xen-4.0.1-testing.orig/xen/common/trace.c > +++ xen-4.0.1-testing/xen/common/trace.c > @@ -631,6 +631,7 @@ void __trace_var(u32 event, bool_t cycle > if( !tb_init_done ) > return; > > + cycles = 1; > /* Convert byte count into word count, rounding up */ > extra_word = (extra / sizeof(u32)); > if ( (extra % sizeof(u32)) != 0 ) > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Sep 30, George Dunlap wrote:> Have you tried using xenalyze to analyze your trace? > > http://xenbits.xensource.com/ext/xenalyze.hgI will try it, thanks. To build it, these changes are needed: xenalyze.c:8038: error: ignoring return value of ''pipe'', declared with attribute warn_unused_result xenalyze.c:7731: error: ''toplevel'' may be used uninitialized in this function xenalyze.c:6168: error: ''e.pte'' may be used uninitialized in this function xenalyze.c:6168: error: ''e.addr'' may be used uninitialized in this function xenalyze.c:6168: error: ''e.eip'' may be used uninitialized in this function xenalyze.c:7360: error: ''first_tsc'' may be used uninitialized in this function xenalyze.c:6611: error: ''sevt.new_runstate'' may be used uninitialized in this function xenalyze.c:6611: error: ''sevt.old_runstate'' may be used uninitialized in this function xenalyze.c:6591: error: ''type'' may be used uninitialized in this function --- xenalyze.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- xenalyze.hg/xenalyze.c +++ xenalyze.hg/xenalyze.c @@ -6167,6 +6167,7 @@ void pv_ptwr_emulation_process(struct re unsigned long long pte, addr, eip; } e; + memset(&e, 0x5a, sizeof(e)); switch ( pevt.minor ) { case PV_PTWR_EMULATION_PAE: if ( pevt.x64 ) @@ -6622,6 +6623,7 @@ void sched_runstate_process(struct pcpu_ sevt.old_runstate = _sevt.old_runstate; break; case 2: + default: type = CONTINUE; sevt.new_runstate = sevt.old_runstate = RUNSTATE_RUNNING; break; @@ -7366,8 +7368,7 @@ void process_lost_records(struct pcpu_in ri->extra_words); dump_unexpected_and_exit(ri); } - else - first_tsc = r->first_tsc; + first_tsc = r->first_tsc; if(opt.dump_cooked || opt.dump_all) { @@ -7728,7 +7729,7 @@ void create_dump_header(struct record_in int find_toplevel_event(struct record_info *ri) { - int toplevel, i, count; + int toplevel = 0, i, count; for(i=0, count=0; i<TOPLEVEL_MAX; i++) if(ri->evt.main & (1UL<<i)) @@ -8035,7 +8036,8 @@ void progress_child_exec(void) { void progress_init(void) { int pid; - pipe(G.progress.pipe); + if (pipe(G.progress.pipe) < 0) + perror("pipe"); if(!(pid = fork())) { progress_child_exec(); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2010-Sep-30 14:21 UTC
Re: [Xen-devel] no cycles for certain xentrace entries
Thanks for the patch; I''ll take a look and apply what I can. What version of gcc / what flags are you using? -George On 30/09/10 15:18, Olaf Hering wrote:> On Thu, Sep 30, George Dunlap wrote: > >> Have you tried using xenalyze to analyze your trace? >> >> http://xenbits.xensource.com/ext/xenalyze.hg > > I will try it, thanks. > > To build it, these changes are needed: > > > xenalyze.c:8038: error: ignoring return value of ''pipe'', declared with attribute warn_unused_result > xenalyze.c:7731: error: ''toplevel'' may be used uninitialized in this function > xenalyze.c:6168: error: ''e.pte'' may be used uninitialized in this function > xenalyze.c:6168: error: ''e.addr'' may be used uninitialized in this function > xenalyze.c:6168: error: ''e.eip'' may be used uninitialized in this function > xenalyze.c:7360: error: ''first_tsc'' may be used uninitialized in this function > xenalyze.c:6611: error: ''sevt.new_runstate'' may be used uninitialized in this function > xenalyze.c:6611: error: ''sevt.old_runstate'' may be used uninitialized in this function > xenalyze.c:6591: error: ''type'' may be used uninitialized in this function > > --- > xenalyze.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > --- xenalyze.hg/xenalyze.c > +++ xenalyze.hg/xenalyze.c > @@ -6167,6 +6167,7 @@ void pv_ptwr_emulation_process(struct re > unsigned long long pte, addr, eip; > } e; > > + memset(&e, 0x5a, sizeof(e)); > switch ( pevt.minor ) { > case PV_PTWR_EMULATION_PAE: > if ( pevt.x64 ) > @@ -6622,6 +6623,7 @@ void sched_runstate_process(struct pcpu_ > sevt.old_runstate = _sevt.old_runstate; > break; > case 2: > + default: > type = CONTINUE; > sevt.new_runstate = sevt.old_runstate = RUNSTATE_RUNNING; > break; > @@ -7366,8 +7368,7 @@ void process_lost_records(struct pcpu_in > ri->extra_words); > dump_unexpected_and_exit(ri); > } > - else > - first_tsc = r->first_tsc; > + first_tsc = r->first_tsc; > > if(opt.dump_cooked || opt.dump_all) > { > @@ -7728,7 +7729,7 @@ void create_dump_header(struct record_in > > int find_toplevel_event(struct record_info *ri) > { > - int toplevel, i, count; > + int toplevel = 0, i, count; > > for(i=0, count=0; i<TOPLEVEL_MAX; i++) > if(ri->evt.main& (1UL<<i)) > @@ -8035,7 +8036,8 @@ void progress_child_exec(void) { > void progress_init(void) { > int pid; > > - pipe(G.progress.pipe); > + if (pipe(G.progress.pipe)< 0) > + perror("pipe"); > > if(!(pid = fork())) { > progress_child_exec();_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Sep 30, George Dunlap wrote:> Thanks for the patch; I''ll take a look and apply what I can. What > version of gcc / what flags are you using?gcc 4.3.4 from SLES11 SP1. gcc -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -o xenalyze xenalyze.c Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel