On Tue, 21 May 2002, Roman Zippel wrote:
>
> Basically I could agree with it, but something looks wrong. Why exactly
> is pte_free_tlb() needed in first place? Why does it call
> tlb_remove_page()?
That is a x86-specific thing, not aarchitected.
The _architected_ thing is
- pte_free() does the physical free of a pte pointer that was allocated
but never inserted into the page tables due to optimistic locking (see
pte_alloc_map() in mm/memory.c).
- pte_free_tlb() does the same BUT it is also an architecture-specific
hook to allow the architecture to also some way shoot down whatever TLB
contents that might depend on the pmd_page in question.
On x86, we do that by just adding it as another page to teh tlb flush
stuff, but other architectures might just make it be the same as
pte_free() if there are no TLB issues involved.
If you care, the reason we need to do this on x86 is that the TLB walker
is speculative and almost totally asynchronous wrt the rest of the CPU
core, so we may have a CPU "TLB lookup thread" goin on in parallel with
the TLB cleaning - and that TLB lookup may have looked up the pmd contents
already but not resolved the entry yet. Which is why we have to
synchronize the PMD freeing with the TLB flush - the same way we already
have to do it for the regular data pages.
Other architectures may not have this issue (or you can fix it with
alternative approaches, like using the pmd quicklists etc to avoid freeing
the pmd before the TLB flush, which is likely to be the fix in the 2.4.x
tree).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 23 2002 - 22:00:22 EST