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

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

I had thought I moved tls to tls.disabled, but I'll check again.

-Andrew

On Wednesday 02 November 2005 13:17, Kip Macy wrote:
> 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 <http://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 <http://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 <http://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 <http://libc-2.3.5.so> malloc
> > 30316 5.1692 troff (no symbols)
> > 20632 3.5180 libc-2.3.5.so <http://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 <http://libc-2.3.5.so> getwchar
> > 8057 1.3738 xen-unstable-syms decode_register
> > 7347 1.2527 libc-2.3.5.so <http://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 <http://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 <http://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