Re: how to avoid lost trace records?

[Olaf Hering <olaf@aepfle.de>]

On Fri, Nov 19, Olaf Hering wrote:

> 
> Today I inspected the xenalyze and the dump-raw output and noticed that
> huge number of lost trace records, even when booted with tbuf_size=200:
> 
> grep -wn 1f001 log.sles11_6.xentrace.txt.dump-raw
> 274438:R p 5 o000000000063ffd4    1f001 4 t0000006d215b3c6b [ b6aed 57fff 9e668fb6 51 ]
...
> That means more than 740K lost entries on cpu5,3,2,1,0.
> Is this expected?

After reading the sources more carefully, its clear now.
There are a few constraints:

If booted with tbuf_size=N, tracing starts right away and fills up the
buffer until xentrace collects its content. So entries will be lost.

Once I just ran xentrace -e all > output, which filled up the whole disk
during my testing. So I changed the way to collect the output to a
compressed file:

 # mknod pipe p
 # gzip -v9 < pipe > output.gz &
 # xentrace -e all pipe &

This means xentrace will stall until gzip has made room in the pipe.
Which also means xentrace cant collect more data from the tracebuffer
while waiting. So that is the reason for the lost entries.

Now I changed T_INFO_PAGES in trace.c from 2 to 16, and reduced the
compression rate to speedup gzip emptying the pipe.

 # mknod pipe p
 # nice -n -19 gzip -v1 < pipe > output.gz &
 # nice -n -19 xentrace -s 1 -S 2031 -e $(( 0x10f000 )) pipe &


This means no more lost entries even with more than one guest running.


Olaf