All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: joakim.tjernlund@lumentis.se
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: dc* (Data Cache)  instructions in mem*() and *_page() functions not used on 8xx
Date: Fri, 01 Nov 2002 12:33:13 -0500	[thread overview]
Message-ID: <3DC2BAD9.5020907@embeddededge.com> (raw)
In-Reply-To: IGEFJKJNHJDCBKALBJLLAEIPFHAA.joakim.tjernlund@lumentis.se


Joakim Tjernlund wrote:

> Dan, could you add the missing code for 8xx to detect the exception conditions when
> the cache instructions faulted? I would like to give it a try.

It's not very high on my list of things to do.  As I recall, the VM fault
handler may need knowledge of a dcbz fault and use a different method to
determine the address.  I also have this funny feeling that it isn't a
restartable operation, so we may have to emulate the instruction when
the fault occurs.

I know you can write a test that would show this to be a performance
benefit, which would just copy/zero lots of data, but that's not a real
world application.

IMHO, it's lots of work for little, if any, gain.  It has some specific
uses in specialized applications, but I don't think it's a general speed up
solution.

 > Maybe add a new CONFIG option to allow 8xx to use these optimizations when
> explicitly enabled.

How would you know when to do this?  It seldom appeared in any errata
so you couldn't know for certain if a particular chip version would
allow this.  I suspect people (like I have chosen to do) will just never
use the optimization because the software will always work in this case.
I don't like solutions that depend on luck or trial and error.

I'll do some research into this again, it's been many years since I
thought about it.

	-- Dan


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

  reply	other threads:[~2002-11-01 17:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23  7:51 [PATCH] arch/ppc/8xx_io/enet.c Joakim Tjernlund
2002-10-23 15:32 ` Ricardo Scop
2002-10-23 15:44   ` Ricardo Scop
2002-10-25 16:02     ` dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx Joakim Tjernlund
2002-10-27 23:23       ` Joakim Tjernlund
2002-10-29 15:27         ` Dan Malek
2002-10-29 16:02           ` Joakim Tjernlund
2002-10-29 16:23             ` Dan Malek
2002-10-29 18:07               ` Joakim Tjernlund
2002-11-01 11:14                 ` Joakim Tjernlund
2002-11-01 17:33                   ` Dan Malek [this message]
2002-11-01 19:27                     ` Joakim Tjernlund
2002-11-04  2:09                       ` Dan Malek
2002-11-04 10:25                         ` Joakim Tjernlund
2002-10-24  7:14   ` [PATCH] arch/ppc/8xx_io/enet.c Joakim Tjernlund
2002-10-24 10:12   ` Steven Scholz
2002-10-24 10:14     ` Joakim Tjernlund

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=3DC2BAD9.5020907@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=joakim.tjernlund@lumentis.se \
    --cc=linuxppc-embedded@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.