linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Cox <apc@agelectronics.co.uk>
To: Dan Malek <dan@netx4.com>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Help with string.S
Date: Tue, 11 Jul 2000 11:06:48 +0100	[thread overview]
Message-ID: <396AF1B8.6FB1401C@agelectronics.co.uk> (raw)
In-Reply-To: 396A5162.411F49EF@embeddededge.com


Dan Malek wrote:
> > What gives me trouble is the fact that dcbz instruction in function
> > arch/ppc/lib/string.S:__copy_tofrom_user does not seem to work for me.
> These are becoming a pain in the ass instructions.  Has anyone ever
> done some performance analysis to see what we really gain here in
> real life?  Sure, locally and logically you can make an intuitive
> argument, but we are sure fetching lots of instructions just to get
> this aligned, and further to actually move the data.

The 7xx(x) processors don't have the alignment handler set up to cover
this problem in 2.2, so they just get an oops when somebody writes to
uncached memory, like a framebuffer device. This could probably be
solved by starting the function with a test of the address, and using a
version without cache operations for target addresses above the kernel
image of memory.

Or by removing the cache operations. Even if they stay, could they be a
compilation time optimisation for particular processors?

> You know, we could make this even faster by using the Altivec and the
> new cache streaming modes on the 7400 processors :-).  I've tested this
> in applications.  It really works.

The 7400 certainly doesn't need the dcbz, as it will perform an implicit
allocation if the entire cache line is written by store instructions.

- Adrian Cox, AG Electronics

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

  parent reply	other threads:[~2000-07-11 10:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-08 22:57 Help with string.S Dan Malek
2000-07-08 23:57 ` Dan Malek
2000-07-10  6:14 ` Daniel Marmier
2000-07-10 15:17   ` David Edelsohn
2000-07-10 22:42   ` Dan Malek
2000-07-11  5:50     ` Daniel Marmier
2000-07-13 18:52       ` Dan Malek
2000-07-11 10:06     ` Adrian Cox [this message]
2000-07-11 15:53       ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2000-08-16  7:26 Graham Stoney
2000-08-16 16:22 ` tom_gall
2000-08-17  0:50   ` Graham Stoney
2000-08-17 19:28 ` Dan Malek

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=396AF1B8.6FB1401C@agelectronics.co.uk \
    --to=apc@agelectronics.co.uk \
    --cc=dan@netx4.com \
    --cc=linuxppc-dev@lists.linuxppc.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).