From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
Date: Wed, 01 Sep 2010 19:15:00 -0000 [thread overview]
Message-ID: <AANLkTimsOWkmm-n08E5d-kZNDvjhmhzNZ65w1cxTiffq@mail.gmail.com> (raw)
In-Reply-To: <4C7EA30B.7020007@redhat.com>
On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla <swagiaal@redhat.com> wrote:
> On 09/01/2010 02:37 PM, Tom Tromey wrote:
>>>>>>>
>>>>>>> "Doug" == Doug Evans<dje@google.com> writes:
>>
>> Doug> One would expect the original code to have done a memset too,
>> instead
>> Doug> of using "static". Presumably it didn't for performance reasons.
>> Do
>> Doug> we 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?).
WARNING: multiple messages have this Message-ID
From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
Date: Wed, 01 Sep 2010 19:17:00 -0000 [thread overview]
Message-ID: <AANLkTimsOWkmm-n08E5d-kZNDvjhmhzNZ65w1cxTiffq@mail.gmail.com> (raw)
Message-ID: <20100901191700.lApvch3rP7J-GBpedmCKau7JDNFKtbYMY69SWdJ_Cjo@z> (raw)
In-Reply-To: <4C7EA30B.7020007@redhat.com>
On Wed, Sep 1, 2010 at 12:01 PM, sami wagiaalla <swagiaal@redhat.com> wrote:
> On 09/01/2010 02:37 PM, Tom Tromey wrote:
>>>>>>>
>>>>>>> "Doug" == Doug Evans<dje@google.com> writes:
>>
>> Doug> One would expect the original code to have done a memset too,
>> instead
>> Doug> of using "static". Presumably it didn't for performance reasons.
>> Do
>> Doug> we 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?).
next prev parent reply other threads:[~2010-09-01 19:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 14:11 [RFC] Use custom hash function with bcache sami wagiaalla
2010-08-16 18:29 ` Doug Evans
2010-08-16 18:56 ` Doug Evans
2010-08-16 19:56 ` sami wagiaalla
2010-08-19 16:32 ` [patch 1/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-19 20:26 ` Tom Tromey
2010-08-25 18:30 ` sami wagiaalla
2010-08-30 20:53 ` Tom Tromey
2010-09-01 8:25 ` Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] " Jan Kratochvil
2010-09-01 16:20 ` Joel Brobecker
2010-09-01 16:47 ` Joel Brobecker
2010-09-01 17:03 ` sami wagiaalla
2010-09-01 17:17 ` Joel Brobecker
2010-09-01 18:09 ` sami wagiaalla
2010-09-01 18:19 ` Jan Kratochvil
2010-09-01 18:24 ` Doug Evans
2010-09-01 18:38 ` Tom Tromey
2010-09-01 19:01 ` sami wagiaalla
2010-09-01 19:15 ` Doug Evans [this message]
2010-09-01 19:17 ` Doug Evans
2010-09-01 19:59 ` sami wagiaalla
2010-09-01 23:11 ` Doug Evans
2010-09-01 23:16 ` Doug Evans
2010-09-01 23:19 ` Doug Evans
2010-09-01 23:19 ` Doug Evans
2010-09-02 15:43 ` sami wagiaalla
2010-09-02 20:25 ` Doug Evans
2010-09-03 15:59 ` Doug Evans
2010-09-04 14:29 ` sami wagiaalla
2010-09-06 9:46 ` Daniel Jacobowitz
2010-08-16 19:14 ` [RFC] Use custom hash function with bcache Daniel Jacobowitz
2010-08-16 19:50 ` sami wagiaalla
2010-08-16 20:04 ` Daniel Jacobowitz
2010-08-16 20:11 ` sami wagiaalla
2010-08-16 20:49 ` Daniel Jacobowitz
2010-08-17 17:02 ` sami wagiaalla
2010-08-17 17:40 ` Daniel Jacobowitz
2010-08-17 23:26 ` Tom Tromey
2010-08-18 15:13 ` sami wagiaalla
2010-08-18 15:24 ` Tom Tromey
2010-08-19 16:33 ` sami wagiaalla
2010-08-19 16:37 ` [patch 2/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-19 20:32 ` [RFC] Use custom hash function with bcache Tom Tromey
2010-08-25 18:32 ` [patch 2/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-30 20:58 ` Tom Tromey
2010-08-30 21:13 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimsOWkmm-n08E5d-kZNDvjhmhzNZ65w1cxTiffq@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=swagiaal@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).