WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] how to avoid lost trace records?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] how to avoid lost trace records?
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Fri, 19 Nov 2010 16:46:52 +0100
Delivery-date: Fri, 19 Nov 2010 07:48:06 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290181620; l=1616; s=domk; d=aepfle.de; h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=g3rpu4jKx8bHpje8iSq5tU/SPzw=; b=l8kDS7+/hHFzkQV6m1fLISrvvG4SpL3S8qhcTl9w3Teczp8JjLw4W9D/hl6e2cUMU1W Gc0E0P9KJNc+3qdG6NCT6KJKIfmX1Omxi7JyoRsKcw5ek9kMB/LKXw7JacHy1lzSIDWtf sC8i34FJi96VtqNcR7RVpn1WYO9b1CIbKY4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
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 ]
274468:R p 3 o00000000006401e8    1f001 4 t0000006e21a1c004 [ b557d 37fff 
87924040 51 ]
274554:R p 2 o0000000000640668    1f001 4 t0000006e62629592 [ c7747 40000 
b8f5d7ac 4f ]
274562:R p 0 o00000000006406dc    1f001 4 t0000006e63e3415a [ be911 7fff 
fb77cb80 4a ]
274567:R p 1 o0000000000640728    1f001 4 t0000006e6e45e5d5 [ e624e 0 199d7db0 
4b ]
321539:R p 1 o0000000000726128    1f001 4 t0000006e76da7821 [ 2554 0 756c584b 
6e ]
329858:R p 1 o000000000074eba8    1f001 4 t0000006e95de2638 [ 289b7 0 781c474a 
6e ]
348457:R p 1 o00000000008042a0    1f001 4 t0000006e9c0cea86 [ 15202 0 96ff6f1e 
6e ]
352634:R p 7 o000000000082ca74    1f001 4 t0000006ed46cea24 [ b18f0 40000 
9efcab44 51 ]
354038:R p 4 o0000000000837df0    1f001 4 t0000006fe86a765f [ c402e 1 86b51960 
51 ]
356635:R p 6 o00000000008474e0    1f001 4 t0000007671b75052 [ b69dd 1 9e4272a2 
51 ]
356716:R p 1 o0000000000847b80    1f001 4 t000000769dc250ca [ 21f5f 1 9c526d83 
6e ]

That means more than 740K lost entries on cpu5,3,2,1,0.
Is this expected?
This is 4.0 with a simple boot into Linux and shut it down again.

My command line was first just '-e all', now its like this and it does
not really reduce the number of lost entries:
xentrace -s 1 -e $(( 0x0010f000 | 0x0001f000 + 1 | 0x0001f000 + 2 | 0x0001f000 
+ 3 )) $file

Is the tracebuffer handling well debugged?

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel