8xx v2.6 TLB problems and suggested workaround
Dan Malek
dan at embeddededge.com
Sun Apr 24 07:55:10 EST 2005
On Apr 9, 2005, at 3:03 PM, Joakim Tjernlund wrote:
> yes, but I think these operates on physical addresses which makes it a
> bit harder.
> I still think this can be resolved in fault.c. Replace
> andis. r11, r10, 0x0200 /* If set, indicates store op */
> beq 2f
> in the DTLB Error handler with
> andis. r11, r10, 0x4800 /* If set, indicates invalid pte or
> protection violation */
> bne 2f
> In fault.c you can check if both store and invalid is set
> simultaneously. If it is, clear
> the store flag and continue as usual.
The purpose for the code in TLB Error is to create fast path for
tracking
writable pages as dirty. I think we should stop writing all of this
assembler
code and if we find anything that isn't simply updating the "dirty"
flags, we
should bail out to the fault.c and do whatever is necessary. This
includes
simulating any cache instructions that fail.
As a further performance enhancement, which used to be the standard
mode for 8xx, we should allow the option to mark all writable pages as
dirty when the PTE is created. This eliminates the TLB Error fault in
this
case completely. Since most 8xx systems don't do page swapping, this
has no other effect. If it does page swapping, it may swap more pages
than necessary, or the option can be disabled to do proper paging.
Thanks.
-- Dan
More information about the Linuxppc-embedded
mailing list