From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: sanjay3000@yahoo.com
Cc: Mark Nelson <markn@au1.ibm.com>,
Gunnar von Boehn <VONBOEHN@de.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
linuxppc-dev@ozlabs.org, Michael Ellerman <ellerman@au1.ibm.com>,
cbe-oss-dev@ozlabs.org
Subject: Re: [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell
Date: Sat, 21 Jun 2008 09:20:27 +1000 [thread overview]
Message-ID: <1214004027.8011.182.camel@pasglop> (raw)
In-Reply-To: <247666.12345.qm@web33104.mail.mud.yahoo.com>
On Fri, 2008-06-20 at 10:46 -0700, Sanjay Patel wrote:
> --- On Fri, 6/20/08, Gunnar von Boehn <VONBOEHN@de.ibm.com> wrote:
> > How important is best performance for the unaligned copy
> > to/from uncacheable memory?
> > The challenge of the CELL chip is that X-form of the shift
> > instructions are microcoded.
> > The shifts are needed to implement a copy that reads and
> > writes always aligned.
>
> Hi Gunnar,
>
> I have no idea how important unaligned or uncacheable copy perf is for
> Cell Linux. My experience is from Mac OS X for PPC, where we used dcbz
> in a general-purpose memcpy but were forced to pull that optimization
> because of the detrimental perf effect on important applications.
I though OS X had a trick with a CR bit that would disable the dcbz
optimization on the first alignment fault ? Or did they totally remove
it ?
> I may be missing something, but I don't see how Cell's microcoded
> shift is much of a factor here. The problem is that the dcbz will
> generate the alignment exception regardless of whether the data is
> actually unaligned or not. Once you're on that code path, performance
> can't be good, can it?
This is a concern. The problem is, do we want to lose all the benefit
of improved copy_to/from_user because of that ? Passing local store
addresses to/from read/write syscalls is supported, so I suppose it's a
real issue for reads.
On the other hand, how performant do we expect those to be ? That is, we
could have the alignment exception detect that it happened during
copy_to/from_user, and change the return address to a non-optimized
variant. Thus we would have at most one exception per read syscall.
Ben.
next prev parent reply other threads:[~2008-06-20 23:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 7:53 [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell Mark Nelson
2008-06-19 14:43 ` Arnd Bergmann
2008-06-19 15:17 ` Gunnar von Boehn
2008-06-19 16:13 ` Sanjay Patel
2008-06-20 11:36 ` Gunnar von Boehn
2008-06-20 17:46 ` Sanjay Patel
2008-06-20 23:20 ` Benjamin Herrenschmidt [this message]
2008-06-20 23:44 ` Sanjay Patel
2008-06-23 8:30 ` Gunnar von Boehn
2008-06-23 12:07 ` Geert Uytterhoeven
2008-06-23 23:49 ` Paul Mackerras
2008-06-27 13:30 ` Gunnar von Boehn
2008-06-20 1:13 ` [Cbe-oss-dev] " Paul Mackerras
2008-06-20 16:47 ` Gunnar von Boehn
2008-06-21 2:00 ` Arnd Bergmann
2008-06-21 4:30 ` Paul Mackerras
2008-06-21 4:49 ` David Miller
2008-06-21 21:06 ` Arnd Bergmann
2008-06-20 1:55 ` Mark Nelson
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=1214004027.8011.182.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=VONBOEHN@de.ibm.com \
--cc=arnd@arndb.de \
--cc=cbe-oss-dev@ozlabs.org \
--cc=ellerman@au1.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=markn@au1.ibm.com \
--cc=sanjay3000@yahoo.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 NNTP newsgroup(s).