public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@systemhalted.org>
To: Steve Ellcey <sellcey@mips.com>
Cc: Maxim Kuvyrkov <maxim@codesourcery.com>,
	libc-ports@sourceware.org, pinskia@gmail.com
Subject: Re: [patch, mips] More mips memcpy improvements
Date: Wed, 28 Nov 2012 19:03:00 -0000	[thread overview]
Message-ID: <CAE2sS1iuD6yCUKS2XhPtNsoRSTTJDrFBzujiLEi=CmHF5D5O5A@mail.gmail.com> (raw)
In-Reply-To: <1354128832.22862.223.camel@ubuntu-sellcey>

On Wed, Nov 28, 2012 at 1:53 PM, Steve Ellcey <sellcey@mips.com> wrote:
> On Wed, 2012-11-28 at 09:46 -0500, Carlos O'Donell wrote:
>> On Wed, Nov 28, 2012 at 2:43 AM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
>> > On 28/11/2012, at 9:37 AM, Steve Ellcey wrote:
>> >
>> > ...
>> >> Andrew and Maxim, could you take a look at this new version and see if it
>> >> works OK for you?
>> >
>> > Correctness-wise, the patch does not trigger any faults on the benchmark that I'm using, so that's good.  Performance-wise, I didn't see any significant difference.  It may be that XLP's cache doesn't benefit from using prepare-for-store hints.  In any case, the patch doesn't regress performance, so I'm OK with it.
>> >
>> > Steve, did you run normal glibc testsuite on this patch with no failures?
>>
>> I will note that I'm not comfortable pushing a patch like this so
>> close to the 2.17 freeze.
>>
>> My preference would be that 2.17 goes out the door, then once the
>> freeze is over we put this patch into trunk and then everyone can test
>> it and ensure that what we get is continual incremental improvement.
>>
>> Cheers,
>> Carlos.
>
> I can wait to do the checkin if you want.  I would point out that the
> current MIPS memcpy was only checked in a month ago so it doesn't have
> much more testing then this version.  I haven't run the glibc testsuite
> with this memcpy, I used a combination of memcpy specific tests I wrote
> plus GCC testing for verification.  I will run the glibc testsuite
> today, it hasn't been clean in the past for me (before I made any
> changes) and I don't expect it to be so now but I will report on my
> results when I have them.

Please wait to check this in. Thank you for your patience and
understanding with the upcoming freeze.

Please don't wait to keep talking about it and getting concensus and
testing done by everyone else interested in MIPS performance. Feel
free to keep your own freature branch and carry the patch there,
asking for testing and review.

Cheers,
Carlos.

      parent reply	other threads:[~2012-11-28 19:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 20:37 Steve Ellcey 
2012-11-28  7:43 ` Maxim Kuvyrkov
2012-11-28 14:46   ` Carlos O'Donell
2012-11-28 18:54     ` Steve Ellcey
2012-11-28 18:59       ` Maxim Kuvyrkov
2012-11-28 19:03       ` Carlos O'Donell [this message]

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='CAE2sS1iuD6yCUKS2XhPtNsoRSTTJDrFBzujiLEi=CmHF5D5O5A@mail.gmail.com' \
    --to=carlos@systemhalted.org \
    --cc=libc-ports@sourceware.org \
    --cc=maxim@codesourcery.com \
    --cc=pinskia@gmail.com \
    --cc=sellcey@mips.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).