* 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).