Re: 46% performance drop with change in glibc

[Anthony Liguori <aliguori@us.ibm.com>]

Hi Andrew,

My immediate guess would be TLS emulation.

Do you not disable TLS on FC4?

Regards,

Anthony Liguori

Andrew Theurer 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@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>