linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Dominik Bozek <domino@mikroswiat.pl>
Cc: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
Subject: Re: performance: memcpy vs. __copy_tofrom_user
Date: Wed, 08 Oct 2008 12:40:31 -0500	[thread overview]
Message-ID: <48ECF08F.7000400@freescale.com> (raw)
In-Reply-To: <48ECC611.3030309@mikroswiat.pl>

Dominik Bozek wrote:
> I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313.
> And the major conclusion is that __copy_tofrom_user is more efficient
> than memcpy. Sometimes about 40%.
> 
> If I good understand, the memcpy() just copy the data, while
> __copy_tofrom_user() take care if the memory wasn't swapped out.

There's not much overhead in dealing with bad pointers; it's mostly 
fixup after the fault.

The performance difference most likely comes from the fact that copy 
to/from user can assume that the memory is cacheable, while memcpy is 
occasionally used on cache-inhibited memory -- so dcbz isn't used.  We 
may be better off handling the alignment fault on those occasions, and 
we should use dcba on chips that support it.

I'm not sure why we don't use dcbt in memcpy(), as it's just ignored if 
the memory is cache-inhibited.

> BTW. The memcpy() maybe optimized as it is on i32 when the size of block
> is known at compile time.

Yes, that would be nice.

-Scott

  parent reply	other threads:[~2008-10-08 17:40 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
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 [this message]
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=48ECF08F.7000400@freescale.com \
    --to=scottwood@freescale.com \
    --cc=domino@mikroswiat.pl \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.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).