Paul Mundt wrote: > 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. yep it is the first wb implementation - I'll do more test to see if I don't break anything. > > 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. Ok. I'll take a look at it. Thanks for information, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
