From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6901 invoked by alias); 1 Sep 2010 19:15:45 -0000 Received: (qmail 6872 invoked by uid 22791); 1 Sep 2010 19:15:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Sep 2010 19:15:35 +0000 Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o81JFWg3007915 for ; Wed, 1 Sep 2010 12:15:33 -0700 Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by hpaq3.eem.corp.google.com with ESMTP id o81JFU5S022584 for ; Wed, 1 Sep 2010 12:15:31 -0700 Received: by vws5 with SMTP id 5so8274986vws.37 for ; Wed, 01 Sep 2010 12:15:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.58.1 with SMTP id e1mr4110338vch.26.1283368528051; Wed, 01 Sep 2010 12:15:28 -0700 (PDT) Received: by 10.220.200.73 with HTTP; Wed, 1 Sep 2010 12:14:57 -0700 (PDT) In-Reply-To: <4C7EA30B.7020007@redhat.com> References: <4C6946E1.6000709@redhat.com> <4C6D5C83.3050602@redhat.com> <4C756132.5050301@redhat.com> <20100901082539.GA24609@host1.dyn.jankratochvil.net> <20100901161952.GX2986@adacore.com> <20100901164716.GY2986@adacore.com> <4C7E96FA.2080209@redhat.com> <4C7EA30B.7020007@redhat.com> Date: Wed, 01 Sep 2010 19:15:00 -0000 Message-ID: Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache] From: Doug Evans To: sami wagiaalla Cc: Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00052.txt.bz2 On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla wrote: > On 09/01/2010 02:37 PM, Tom Tromey wrote: >>>>>>> >>>>>>> "Doug" =3D=3D Doug Evans =A0writes: >> >> Doug> =A0One would expect the original code to have done a memset too, >> instead >> Doug> =A0of using "static". =A0Presumably it didn't for performance reas= ons. >> =A0Do >> Doug> =A0we know if the performance concerns were real? >> >> No, we don't know. >> It is safest to just revert to what it was before. I hope I'm not reducing the S/N ratio here, but there's something I don't understand. The original patch doesn't initialize obj_section (right?) (except by virtue of using "static"). So if this fixes things, does it do so only because we're taking advantage of the fact that obj_section will be NULL in the static version and that's sufficient? So do we need the memset of the original patch (which only zeros psymbol.ginfo.value). Plus, reverting to the original patch leaves me a little uncomfortable: There's a comment that mentions gaps in the struct causing cache misses, but that's no longer an issue with the custom hash function (right?). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7083 invoked by alias); 1 Sep 2010 19:15:47 -0000 Received: (qmail 6904 invoked by uid 22791); 1 Sep 2010 19:15:45 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Sep 2010 19:15:43 +0000 Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o81JFenw018295 for ; Wed, 1 Sep 2010 12:15:40 -0700 Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by hpaq1.eem.corp.google.com with ESMTP id o81JFcJB017978 for ; Wed, 1 Sep 2010 12:15:39 -0700 Received: by vws3 with SMTP id 3so8124063vws.33 for ; Wed, 01 Sep 2010 12:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.95 with SMTP id k31mr4253238vcr.13.1283368498040; Wed, 01 Sep 2010 12:14:58 -0700 (PDT) Received: by 10.220.200.73 with HTTP; Wed, 1 Sep 2010 12:14:57 -0700 (PDT) In-Reply-To: <4C7EA30B.7020007@redhat.com> References: <4C6946E1.6000709@redhat.com> <4C6D5C83.3050602@redhat.com> <4C756132.5050301@redhat.com> <20100901082539.GA24609@host1.dyn.jankratochvil.net> <20100901161952.GX2986@adacore.com> <20100901164716.GY2986@adacore.com> <4C7E96FA.2080209@redhat.com> <4C7EA30B.7020007@redhat.com> Date: Wed, 01 Sep 2010 19:17:00 -0000 Message-ID: Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache] From: Doug Evans To: sami wagiaalla Cc: Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00053.txt.bz2 Message-ID: <20100901191700.lApvch3rP7J-GBpedmCKau7JDNFKtbYMY69SWdJ_Cjo@z> On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla wrote: > On 09/01/2010 02:37 PM, Tom Tromey wrote: >>>>>>> >>>>>>> "Doug" =3D=3D Doug Evans =A0writes: >> >> Doug> =A0One would expect the original code to have done a memset too, >> instead >> Doug> =A0of using "static". =A0Presumably it didn't for performance reas= ons. >> =A0Do >> Doug> =A0we know if the performance concerns were real? >> >> No, we don't know. >> It is safest to just revert to what it was before. I hope I'm not reducing the S/N ratio here, but there's something I don't understand. The original patch doesn't initialize obj_section (right?) (except by virtue of using "static"). So if this fixes things, does it do so only because we're taking advantage of the fact that obj_section will be NULL in the static version and that's sufficient? So do we need the memset of the original patch (which only zeros psymbol.ginfo.value). Plus, reverting to the original patch leaves me a little uncomfortable: There's a comment that mentions gaps in the struct causing cache misses, but that's no longer an issue with the custom hash function (right?).