Re: 8xx: Work around CPU15 erratum.

Re: 8xx: Work around CPU15 erratum.

[Ben Gardiner]

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

Re: 8xx: Work around CPU15 erratum.

[Dan Malek]

On May 14, 2008, at 10:52 AM, Ben Gardiner wrote:

> So there likely are reasons why the following is not possible:

That's way too much code for a tlb exception handler.
 From a system resource perspective, you are much better
off with a small and efficient piece of tlb loading code,
always invalidating pages on both ends and taking the
tlb exception fault.   Unfortunately, this could cause some
thrashing edge cases, so a little intelligence would be
needed.   Exception processing isn't free, and it quickly
destroys the cache footprint of your application, further
slowing down the entire system.  The tlb reload handler
goal should be maximum of 8 instructions and 4 memory
accesses, not 4K of elaborate conditional testing.  :-)

Thanks.

	-- Dan

Re: 8xx: Work around CPU15 erratum.

[Ben Gardiner]

Dan Malek wrote:
>
> On May 14, 2008, at 10:52 AM, Ben Gardiner wrote:
>
>> So there likely are reasons why the following is not possible:
>
> That's way too much code for a tlb exception handler.
> From a system resource perspective, you are much better
> off with a small and efficient piece of tlb loading code,
> always invalidating pages on both ends and taking the
> tlb exception fault.   Unfortunately, this could cause some
> thrashing edge cases, so a little intelligence would be
> needed.   Exception processing isn't free, and it quickly
> destroys the cache footprint of your application, further
> slowing down the entire system.  The tlb reload handler
> goal should be maximum of 8 instructions and 4 memory
> accesses, not 4K of elaborate conditional testing.  :-)
>
> Thanks.
>
>     -- Dan
>
Hi Dan,
Thanks for the rapid reply :) I really appreciate you giving me an 
answer "from the horse's mouth." I would still like to experiment a 
little and I'm not really sure it is safe to use any bits in a PTE.

Assuming I was crazy enough to ruin my cache footprint; are there any 
three bits in the PTE that are safe to use for some page status 
information?

Best Regards,
Ben