* no cycles for certain xentrace entries @ 2010-08-31 18:44 Olaf Hering 2010-09-29 8:09 ` Olaf Hering 0 siblings, 1 reply; 6+ messages in thread From: Olaf Hering @ 2010-08-31 18:44 UTC (permalink / raw) To: xen-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no cycles for certain xentrace entries 2010-08-31 18:44 no cycles for certain xentrace entries Olaf Hering @ 2010-09-29 8:09 ` Olaf Hering 2010-09-30 9:56 ` George Dunlap 0 siblings, 1 reply; 6+ messages in thread From: Olaf Hering @ 2010-09-29 8:09 UTC (permalink / raw) To: 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 ) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no cycles for certain xentrace entries 2010-09-29 8:09 ` Olaf Hering @ 2010-09-30 9:56 ` George Dunlap 2010-09-30 14:18 ` Olaf Hering 0 siblings, 1 reply; 6+ messages in thread From: George Dunlap @ 2010-09-30 9:56 UTC (permalink / raw) To: Olaf Hering; +Cc: xen-devel 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no cycles for certain xentrace entries 2010-09-30 9:56 ` George Dunlap @ 2010-09-30 14:18 ` Olaf Hering 2010-09-30 14:21 ` George Dunlap 0 siblings, 1 reply; 6+ messages in thread From: Olaf Hering @ 2010-09-30 14:18 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel 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(); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no cycles for certain xentrace entries 2010-09-30 14:18 ` Olaf Hering @ 2010-09-30 14:21 ` George Dunlap 2010-09-30 14:47 ` Olaf Hering 0 siblings, 1 reply; 6+ messages in thread From: George Dunlap @ 2010-09-30 14:21 UTC (permalink / raw) To: Olaf Hering; +Cc: xen-devel@lists.xensource.com 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(); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no cycles for certain xentrace entries 2010-09-30 14:21 ` George Dunlap @ 2010-09-30 14:47 ` Olaf Hering 0 siblings, 0 replies; 6+ messages in thread From: Olaf Hering @ 2010-09-30 14:47 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel@lists.xensource.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-30 14:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-31 18:44 no cycles for certain xentrace entries Olaf Hering 2010-09-29 8:09 ` Olaf Hering 2010-09-30 9:56 ` George Dunlap 2010-09-30 14:18 ` Olaf Hering 2010-09-30 14:21 ` George Dunlap 2010-09-30 14:47 ` Olaf Hering
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).