linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ben Gardiner <BenGardiner@nanometrics.ca>
To: linuxppc-embedded@ozlabs.org
Subject: Re: 8xx: Work around CPU15 erratum.
Date: Wed, 14 May 2008 10:52:53 -0400	[thread overview]
Message-ID: <482AFCC5.2070907@nanometrics.ca> (raw)

Hello,

This is my first post to the linuxppc-embedded list. Please forgive me 
for jumping in late onto the CPU15 workaround discussions, but my 
company is very interested in finding an efficient fix for this silicon 
errata on our devices.

I applied the patch submitted by Scott Wood to our patched denx 2.4.24 
tree and did some timing measurements to compare its effect on 
performance. We noted a worst case 37% slowdown -- this was during 
program load, where the PC is moving all over the place, so the penalty 
for all the tlbie's is felt heavily. This is solely anecdotal, I don't 
mean to imply that this fix will result in any particular slowdown on 
anyone else's systems.

I would like to start a discussion on the possibility of implementing a 
selective invalidation of pages on i-tlb miss. On July 20th, 2007 Scott 
Wood wrote:
 >The only lower-overhead workaround I know of requires compiler 
modifications (and I made it configurable to allow for that possibility).

So there likely are reasons why the following is not possible:
In the errata document from Freescale 
(http://www.freescale.com/files/32bit/doc/errata/MPC860CE.pdf?fpsp=1), 
they list an alternative to the "invalidate previous and next page" itlb 
miss handler (see pg 57), where they use the SPS/SH/CI bits of a L2 page 
entry to indicate whether: 1) a page is unchecked, 2) it does not 
contain a bad branch, 3) it does contain a bad branch, or 4) it has a 
previous page with a bad branch. These bits are zeroed before being 
written to MI_RPN. In loose terms the itlb miss handle does the 
following: If the page is unchecked, they check the last instruction the 
current page or the previous page and write the status bits to the L2 
entry accordingly. If the page has been checked the status bits are used 
to selectively invalidate the next or previous page as needed.

Since MI_RPN is always written with bits 24,25,26 and 27 set; could we 
use bits 24, 25 and 26 in memory to indicate the 4 possible page states 
and perform selective page invalidation as demonstrated in their example 
listing?

Regards,
Ben Gardiner

Nanometrics Inc.
250 Herzberg Rd.
Kanata ON
K2K 2A1
Telephone 613 592 6776 ext 239

             reply	other threads:[~2008-05-14 15:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 14:52 Ben Gardiner [this message]
2008-05-14 16:23 ` 8xx: Work around CPU15 erratum Dan Malek
2008-05-14 20:17   ` Ben Gardiner

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=482AFCC5.2070907@nanometrics.ca \
    --to=bengardiner@nanometrics.ca \
    --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).