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

[Andrew Theurer <habanero@xxxxxxxxxx>]

Well, I thought I was losing my mind, but hopefully not.  When I upgraded 
glibc on FC3, I did forget to move tls to tls.disabled.  So, I moved it to 
tls.disabled, and the problem goes away.  HOWEVER, on FC4, I always had tls 
moved to tls.disabled, and I am still getting this problem.  So, on FC4, why 
would these libs not be in /lib/tls in the first place?

/lib/tls[.disabled] on fc3:

i486  i686           libc.so.6      libm.so.6            libpthread.so.0  
librt.so.1           libthread_db.so.1
i586  libc-2.3.3.so  libm-2.3.3.so  libpthread-2.3.3.so  librt-2.3.3.so   
libthread_db-1.0.so

/lib/tls[.disabled] on fc4:

i486  i586  i686



-Andrew

On Wednesday 02 November 2005 13:23, Andrew Theurer wrote:
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel