From: Ralf Baechle <ralf@linux-mips.org>
To: Markos Chandras <Markos.Chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 1/2] MIPS: lib: csum_partial: more instruction paral
Date: Mon, 19 May 2014 18:36:02 +0200 [thread overview]
Message-ID: <20140519163602.GZ17197@linux-mips.org> (raw)
In-Reply-To: <537478D7.2000403@imgtec.com>
On Thu, May 15, 2014 at 09:20:39AM +0100, Markos Chandras wrote:
> On 05/15/2014 08:09 AM, chenj wrote:
> > This will bring at most 50% performance gain on loongson3a.
> > See
> > http://dev.lemote.com/files/upload/software/csum-opti/csum-opti-benchmark.html
> >
> > The benchmark is done in userspace through
> > http://dev.lemote.com/files/upload/software/csum-opti/csum-test.tar.gz
> > ---
> > arch/mips/lib/csum_partial.S | 38 +++++++++++++++++++-------------------
> > 1 file changed, 19 insertions(+), 19 deletions(-)
>
> Hi chenj,
>
> My opinion is that the commit message is not ideal. If the http links
> ever go away, the commit message will be mostly useless for someone
> trying to understand the reason for this patch. I would suggest to
> explain the reason for the optimizations in the commit message and put
> the http links as a comment to this patch which will still be visible in
> the mailing list archives. Or you can keep them in the commit message
> but I think the reason for the patch should be explained as well.
I can certainly offer a FTP space for such things. Or alternatively,
post the archive's content as a shar archive (GNU sharutils) which will
end up in the mailing list archives itself and which provides the best
guarantee for a stable URL.
That said, tinkering with the checksum code shouldn't be done lightly.
The results on some CPUs are quite surprising and the current
impleemntation which is working well on R4000 or Sibyte class cores
has worked reasonably well for most more modern cores and some of the
attempted tweaks have benefited a few but hurt many cores.
But time progresses and we optimize the kernel for modern hardware so
I'm open to reevaluate things, including runtime generation.
Ralf
next prev parent reply other threads:[~2014-05-19 16:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 7:09 [PATCH 1/2] MIPS: lib: csum_partial: more instruction paral chenj
2014-05-15 7:09 ` [PATCH 2/2] MIPS: lib: csum_partial: use wsbh/movn on ls3 chenj
2014-05-15 11:40 ` Paul Burton
2014-05-15 11:40 ` Paul Burton
2014-05-16 13:29 ` Chen Jie
2014-05-16 15:21 ` Paul Burton
2014-06-03 11:03 ` Ralf Baechle
2014-06-03 15:03 ` Chen Jie
2014-06-03 18:44 ` Ralf Baechle
2014-06-04 7:57 ` Chen Jie
2014-05-15 8:20 ` [PATCH 1/2] MIPS: lib: csum_partial: more instruction paral Markos Chandras
2014-05-15 8:20 ` Markos Chandras
2014-05-19 16:36 ` Ralf Baechle [this message]
2014-05-19 3:14 ` [PATCH, v2] " chenj
2014-05-19 6:59 ` James Hogan
2014-05-19 15:32 ` Chen Jie
2014-08-15 20:15 ` Chen Jie
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=20140519163602.GZ17197@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=Markos.Chandras@imgtec.com \
--cc=linux-mips@linux-mips.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.