linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Eugene Surovegin <ebs@ebshome.net>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Copy prefetch optimizations and non-coherent caches
Date: Tue, 09 Sep 2003 22:54:10 -0700	[thread overview]
Message-ID: <5.1.0.14.2.20030909221313.00b13008@mail.ebshome.net> (raw)
In-Reply-To: <16217.57099.255798.871698@cargo.ozlabs.ibm.com>


At 06:20 AM 9/6/2003, Paul Mackerras wrote:
> > I think we should disable prefetch if CONFIG_NONCOHERENT_CACHE is defined.
> > Other more complex solutions are possible, e.g. we can still prefetch our
> > own buffer but don't touch anything outside (I'll try to do some
> > performance testing to determine whether it's worth the effort :).

I did some simple testing on Ebony, and it turns out that read prefetching
gives significant performance boost (~30%).

>The measurements I did on a ppc64 kernel indicated that most
>copy_tofrom_user calls were either for relatively small buffers
>(i.e. less than 256 bytes) or were page-sized and page-aligned.
>Therefore I did two routines, one optimized for small copies that
>didn't use any prefetching or dcbz's, and one optimized for page-sized
>copies.
>
>We could do something similar on ppc32 - we could do the small copy
>case with no prefetching (or maybe we could just prefetch on the first
>cache line), plus a page-copy case that does prefetching.  If you know
>you are doing exactly one page, it shouldn't be hard to set up the
>prefetching so you don't prefetch past the end of the source buffer.
>In fact it should be possible to code up a relatively simple optimized
>copy loop that avoids prefetching outside the source region if we just
>assume that the source and destination addresses are
>cacheline-aligned, and the size is a multiple of the cacheline size
>and is at least 8 (say) cache lines.

Frankly, I don't feel to be qualified to do such significant changes to
__copy_tofrom_user :).

So, I tried to modify copy_page and __copy_tofrom_user as little as
possible and make them non-coherent cache safe while still using read
prefetching. Idea is simple, we prefetch as before but only till the end of
the source buffer.

Updated patches:

  - against linuxppc-2.4: http://kernel.ebshome.net/read_prefetch-2.4-2.diff

  - against linuxppc-2.5 (not tested, but compiles):
http://kernel.ebshome.net/read_prefetch-2.6-2.diff

Eugene.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-09-10  5:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-06  6:07 Copy prefetch optimizations and non-coherent caches Eugene Surovegin
2003-09-06 13:20 ` Paul Mackerras
2003-09-10  5:54   ` Eugene Surovegin [this message]
2003-10-08 21:51   ` Matt Porter

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=5.1.0.14.2.20030909221313.00b13008@mail.ebshome.net \
    --to=ebs@ebshome.net \
    --cc=linuxppc-embedded@lists.linuxppc.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).