[PATCH 3/6] 8xx: invalidate non present TLBs
dan at embeddedalley.com
Fri Oct 9 09:08:29 EST 2009
On Oct 8, 2009, at 1:28 PM, Benjamin Herrenschmidt wrote:
> While you are around ... I have a question :-)
I'll try. Many brain cells have been replaced or lost
over the years :-)
> Do you happen to remember what the story is with the invalidation of
> "unpopulated" (aka invalid) entries ?
> IE. We create those in the 8xx TLB miss when the PTE is !present
> (or the
> PMD is absent). Those then cause a TLB error on the next access which
> allows us to process the page fault. But when/how are those invalid
> entries supposed to be invalidated ?
I thought we did a tlbie() (or whatever the equivalent is today)
when the PTE was updated in the table. An optimization was to
load the TLB with the entry at that time to avoid a subsequent miss.
In any case, the TLB entry has to be modified by the software.
> The doco seems to hint that at least in the case of an entry with the
> wrong C bit (store to an entry with C=0), the HW automatically
> invalidates it before taking the TLB Error but that's all I found.
I don't remember how C was used in the past, but I suspect
it just mirrored the Linux VM state. I'm quite certain the MMU
HW would never change a TLB entry. Where did you read this?
For most of the 8xx "early days," I used to just mark all write
pages as dirty. For some reason I just overloaded the write/changed
into one bit, it avoided TLB Error overhead and I think even some
silicon bugs. Since they were tiny and fairly static embedded
systems, it didn't have any effect on the way VM was managed.
> Is there a general HW policy on 8xx to invalidate TLB entries that
> TLB errors ? Or is the kernel expected to do it most of the time ?
The MMU HW on the 8xx is just a translator. I'm now really
certain it won't ever change a TLB entry. It's completely up to
software to make all TLB changes.
Just make it simple :-)
More information about the Linuxppc-dev