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

To: habanero@xxxxxxxxxx
Subject: Re: [Xen-devel] 46% performance drop with change in glibc
From: Kip Macy <kip.macy@xxxxxxxxx>
Date: Wed, 2 Nov 2005 11:17:40 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 02 Nov 2005 19:14:47 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EbQLzen0U+dGc1zCnPbJlNFCxihPeToe/T8QAlOPGc2MFk1Q+v6hGS1jUM14mfM7KIVGRkGdKMFbSAw/NmA1Pi4sAFBzCN6fWSrSq90kEbWsP2JYZyGobODiCZNKOwimbgH+VRekwBQotMTbIVb8TjylsYKm9rpgssdvh3ir9BU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200511021310.51926.habanero@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200511021310.51926.habanero@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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