public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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?).

  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).