Re: [Xen-devel] 46% performance drop with change in glibc

[Kip Macy <kip.macy@xxxxxxxxx>]

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