Microblaze caches + tlb handling

Microblaze caches + tlb handling

[Michal Simek]

Hi David and others,

I am working on support write-back caches for Microblaze.
I have working implementation but I would like to be sure that I don't miss anything.

I read David's cachetlb.txt in Documentation folder.

Ok. First of all some information about hw implementation.
Cache is between MMU and main memory and I have to use only physical addresses for
flush/invalidation.
This caused first problem for invalidation icache and flushing dcache for signal trampoline.
I took part of this code from sparc where is flushed whole page I think.
David: Am I right?
I need physical address of trampoline that's why there is adding with page offset.


	pmd_t *pmdp;
	pte_t *ptep;
		address = ((unsigned long)frame->tramp);
		pmdp = pmd_offset(pud_offset(
				pgd_offset(current->mm, address),
						address), address);

		preempt_disable();
		ptep = pte_offset_map(pmdp, address);
		if (pte_present(*ptep)) {
			address = (unsigned long) page_address(pte_page(*ptep));
			/* MS: I need add offset in page */
			address += ((unsigned long)frame->tramp) & ~PAGE_MASK;
			/* MS address is virtual */
			address = virt_to_phys(address);
			invalidate_icache_range(address, address + 8);
			flush_dcache_range(address, address + 8);
		}
		pte_unmap(ptep);
		preempt_enable();


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


I am not sure about cache aliasing problem but I think that can't happen for Microblaze.
That's why flush_dcache_page is empty too.

flush_icache_user_range call flush_icache. FRV and PowerPC export it and some archs do nothing.
What is the correct behavior.

The rest of functions call corresponding implementations.



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?

Thanks for you comments,
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

Re: Microblaze caches + tlb handling

[Paul Mundt]

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.

Re: Microblaze caches + tlb handling

[Michal Simek]

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