[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] 46% performance drop with change in glibc
- To: habanero@xxxxxxxxxx
- From: Kip Macy <kip.macy@xxxxxxxxx>
- Date: Wed, 2 Nov 2005 11:17:40 -0800
- Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 02 Nov 2005 19:14:47 +0000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EbQLzen0U+dGc1zCnPbJlNFCxihPeToe/T8QAlOPGc2MFk1Q+v6hGS1jUM14mfM7KIVGRkGdKMFbSAw/NmA1Pi4sAFBzCN6fWSrSq90kEbWsP2JYZyGobODiCZNKOwimbgH+VRekwBQotMTbIVb8TjylsYKm9rpgssdvh3ir9BU=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
The segment offset handling emulation is expensive. You need to either
rename your TLS libraries away or use a glibc with the xen TLS patch.
-Kip
On 11/2/05, Andrew Theurer <habanero@xxxxxxxxxx> wrote:
I have been trying to track down a xen performance regression from Fedora
core3 to core4 i386 and I think I might have narrowed it down. First some
background info: I ran the SDET benchmark [1] and discovered that we have
about a 45% regression after upgrading to Fedora core 4. I noticed
xenoprofile showed ~20% in error_code on FC4, but only ~3.5% in error_code
(should we even have 3%?!?) on FC3. At first I thought the change to gcc-4
might have something to do with it, so I tried gcc4 on FC3 -no regression.
I noticed glibc was also different, so I upgraded FC3 from 2.3.3 to 2.3.5
-bingo. I am not sure what about glibc is causing this, but here are the
two profiles:
fc3 with glic-2.3.3:
samples % app
name
symbol name
56097 22.8770 cc1 (no
symbols)
22780
9.2900 troff (no
symbols)
8646 3.5259 xen-unstable-syms error_code
7822 3.1899 grotty
(no symbols)
5283 2.1545 libc-2.3.3.so _int_malloc
4914 2.0040 vmlinux-2.6.12-xen0-up buffered_rmqueue
4453 1.8160 bash
(no symbols)
4372 1.7830 xen-unstable-syms get_page_from_l1e
3492 1.4241 xen-unstable-syms put_page_from_l1e
3338 1.3613 vmlinux-2.6.12-xen0-up system_call
3040 1.2397 xen-unstable-syms hypercall
2801 1.1423 xen-unstable-syms alloc_page_type
2799 1.1415 vmlinux-2.6.12-xen0-up zap_pte_range
2798 1.1411 libstdc++.so.6.0.3 (no symbols)
2761 1.1260
libc-2.3.3.so vfprintf
2637 1.0754 vmlinux-2.6.12-xen0-up do_no_page
2555 1.0420 libc-2.3.3.so __i686.get_pc_thunk.bx
2548 1.0391 vmlinux-2.6.12-xen0-up
page_fault
fc3 with glibc-2.3.5:
samples % app
name
symbol name
133404 22.7469 xen-unstable-syms error_code
31411
5.3559 libc-2.3.5.so malloc
30316
5.1692 troff (no
symbols)
20632
3.5180 libc-2.3.5.so vfprintf
16626 2.8349 xen-unstable-syms gpf_emulate_4gb
10639
1.8141 xen-unstable-syms do_general_protection
10105
1.7230 grotty
(no symbols)
9837 1.6773 libc-2.3.5.so getwchar
8057 1.3738 xen-unstable-syms decode_register
7347 1.2527 libc-2.3.5.so
iswgraph
7114 1.2130 vmlinux-2.6.12-xen0-up buffered_rmqueue
6926 1.1810 cc1 is_attribute_p
6679 1.1388 libc-2.3.5.so _int_malloc
6350 1.0827 xen-unstable-syms fixup_seg
5673 0.9673 xen-unstable-syms get_baselimit
5039 0.8592 bash
(no symbols)
4957 0.8452 xen-unstable-syms get_page_from_l1e
4908 0.8369 xen-unstable-syms put_page_from_l1e
4576 0.7803 ld-2.3.5.so do_lookup_x
4322 0.7370 xen-unstable-syms hypercall
3915 0.6676 vmlinux-2.6.12-xen0-up system_call
I assume something related to gpf_emulate_4gb...
Anyone have an idea why this would cause such a regression?
-Andrew
[1] SDET described here:
http://www.spec.org/osg/sdm91/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
