From: Dominik Bozek <domino@mikroswiat.pl>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
Subject: Re: performance: memcpy vs. __copy_tofrom_user
Date: Thu, 09 Oct 2008 12:12:21 +0200 [thread overview]
Message-ID: <48EDD905.6070609@mikroswiat.pl> (raw)
In-Reply-To: <18669.28058.495259.72182@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> When I looked at this last (which was a few years ago, I'll admit), I
> found that the vast majority of memcpy calls were for small copies,
> i.e. less than 128 bytes, whereas __copy_tofrom_user was often used
> for larger copies (usually 1 page). So with memcpy the focus was more
> on keeping the startup costs low, while __copy_tofrom_user was
> optimized more for bandwidth.
>
> The other point is that the kernel memcpy doesn't consume a noticeable
> amount of CPU time (at least not on any workload I've seen), so it
> hasn't been a target for aggressive optimization.
>
Actually I made couple of other tests on that mpc8313. Most of them are
to ugly to publish them, but... My problem is that I have to boost the
gigabit interface on the mpc8313. I made simple substitution and
__copy_tofrom_user was used instead of memcpy. I know, it's wrong, but I
speedup that way the network interface for about 10%.
I made also some calculation based on the results I had send. One
__copy_tofrom_user of 1500B compensate profit from 258 memcpy of 8B. But
of course this is the case of mpc8313 (333MHz core, DDR2 at 266MHz). On
other hardware it may work differently and to make any binding
conclusion we need to see some results done on other cpus.
Unfortunately, right now, I don't have any other ppc to make such test
and compare it.
Other hand my test do not cover all cases. I believe most of small
transfer involve data already cached. This is big point for current memcpy.
Maybe there is another solution. Method, agressive or "low cost setup",
will be chosen depend on the size of the copied block and fixed limit.
Limit shall be known at compile time and related to the chosen cpu/platfrom.
If someone ask for other tests. I had optimized memcpy for cases when
transfer size is known at compile time and... hard to say if the system
was "faster", but for sure I didn't notice any boost at network
interface. Maybe my optimization was bad. It's possible with me.
Dominik
next prev parent reply other threads:[~2008-10-09 10:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 14:39 performance: memcpy vs. __copy_tofrom_user Dominik Bozek
2008-10-08 15:31 ` Minh Tuan Duong
2008-10-08 15:39 ` Bill Gatliff
2008-10-08 15:42 ` Grant Likely
2008-10-09 2:34 ` Paul Mackerras
2008-10-09 10:12 ` Dominik Bozek [this message]
2008-10-09 11:06 ` Paul Mackerras
2008-10-09 11:41 ` Dominik Bozek
2008-10-09 12:04 ` Leon Woestenberg
2008-10-09 15:37 ` Matt Sealey
2008-10-11 22:30 ` Benjamin Herrenschmidt
2008-10-12 2:05 ` Matt Sealey
2008-10-12 4:05 ` Benjamin Herrenschmidt
2008-10-13 15:20 ` Scott Wood
2008-10-13 20:50 ` Benjamin Herrenschmidt
2008-10-13 21:03 ` Scott Wood
2008-10-14 2:14 ` Matt Sealey
2008-10-14 2:39 ` Benjamin Herrenschmidt
2008-10-14 15:10 ` Scott Wood
2008-10-15 1:37 ` Matt Sealey
2008-10-10 17:17 ` Dominik Bozek
2008-10-08 17:40 ` Scott Wood
2008-10-09 2:36 ` Paul Mackerras
2008-10-11 22:32 ` Benjamin Herrenschmidt
2008-10-13 15:06 ` Scott Wood
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=48EDD905.6070609@mikroswiat.pl \
--to=domino@mikroswiat.pl \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=paulus@samba.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 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).