Re: Microblaze caches + tlb handling

[Paul Mundt <lethal@linux-sh.org>]

On Fri, Oct 16, 2009 at 03:39:29PM +0200, Michal Simek wrote:
> The second thing which I would like to check is number of functions which are empty.
> 
> flush_dcache_page, flush_dcache_mmap_lock, flush_dcache_mmap_unlock, flush_cache_dup_mm,
> flush_cache_vmap, flush_cache_vunmap, flush_cache_mm, flush_cache_page, flush_icache_page
> 
There is no generic answer regarding whether you need these or not, it
all depends on your cache architecture and you've left those details out.
If you are on a PIPT non-aliasing cache, then obviously you aren't going
to care about most of these.

flush_icache_page() likewise is something that these days is split up and
handled through flush_dcache_page() and update_mmu_cache(). If you're
doing a from scratch implementation, you probably want to avoid dealing
with it at all.

Having said that, all of ARM/MIPS/SH support a wide variety of cache
configurations, so it's fairly trivial to see which types of strategies
can be undertaken with different cache types just by reading through
those.

> The second part of this email but it is related. It is about tlb_start_vma and tlb_end_vma.
> arm, avr32, sh, sparc and xtensa implement it and mips implement only tlb_start_vma.
> Implementation is almost the same. My question is, if is any reason to implement(or not implement) them?
> 
That would be an optimization to reduce expensive TLB flushing for large
mappings. With these implemented it's possible to track the range and
work out whether to do a partial or full MM flush, which can offer
sizeable performance gains, especially if your platform supports ASID
tags and your full MM flush is just bumping up the ASID (MIPS and SH both
do this, for example).

You can look at c20351846efcb755ba849d9fb701fbd9a1ffb7c2 to see the SH
change that implemented this, which in turn was derived from an earlier
ARM one. That has some more background information and links to the
earlier discussion about it.