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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>  
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel