From: Arnd Bergmann <arnd@arndb•de>
To: Paul Mackerras <paulus@samba•org>
Cc: linuxppc-dev@ozlabs•org, Gunnar von Boehn <VONBOEHN@de•ibm.com>,
Michael Ellerman <ellerman@au1•ibm.com>,
cbe-oss-dev@ozlabs•org
Subject: Re: [Cbe-oss-dev] [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell
Date: Sat, 21 Jun 2008 04:00:20 +0200 [thread overview]
Message-ID: <200806210400.20794.arnd@arndb.de> (raw)
In-Reply-To: <18523.1109.809247.646816@cargo.ozlabs.ibm.com>
On Friday 20 June 2008, Paul Mackerras wrote:
> Transferring data over loopback is possibly an exception to that.
> However, it's very rare to transfer large amounts of data over
> loopback, unless you're running a benchmark like iperf or netperf. :-/
Well, it is the exact case that came up in a real world scenario
for cell: On a network intensive application where the SPUs are
supposed to do all the work, we ended up not getting enough
data in and out through gbit ethernet because the PPU spent
much of its time in copy_to_user.
Going to 10gbit will make the problem even more apparent.
I understand that optimizing for this case will cost extra
branches for the other cases, but maybe we can find a better
compromise than before. Can you name a test case that you
consider important to optimize for for what you consider
real-life tests?
Doing some static compile-time analysis, I found that most
of the call sites (which are not necessarily most of
the run time calls) pass either a small constant size of
less than a few cache lines, or have a variable size but are
not at all performance critical.
Since the prefetching and cache line size awareness was
most of the improvement for cell (AFAIU), maybe we can
annotate the few interesting cases, say by introducing a
new copy_from_user_large() function that can be easily
optimized for large transfers on a given CPU, while
the remaining code keeps optmizing for small transfers
and may even get rid of the full page copy optimization
in order to save a branch.
Arnd <><
next prev parent reply other threads:[~2008-06-21 2:00 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
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 [this message]
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=200806210400.20794.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=VONBOEHN@de$(echo .)ibm.com \
--cc=cbe-oss-dev@ozlabs$(echo .)org \
--cc=ellerman@au1$(echo .)ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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