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/
next prev parent 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).