Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Linux I-cache aliasing problem | From | Amit Bhor <> | Date | Thu, 29 Sep 2005 20:35:52 +0530 |
| |
Hi all,
I am working on linux(2.4) port to a 32 bit RISC core. The question I have is about cache aliasing. The architecture has virtually indexed and physically tagged cache. The I-cache is a 2 way 32K cache and the page size is 8K. Since the way size (16) is greater than the page size (8K) it would suffer from I-cache aliasing. I am talking about the aliasing case where 2 different virtual addresses can be indexed into the same cache line and physical tag will also match. Basically 1 bit used for virtual indexing which is also translated by the MMU. This is case is different from the kernel-user aliasing where the same phys address is mapped at two different virtual addresses.
eg :
31 14|13 5|4 0 ----------------------------------------- |Phys tag |Set index |line offset| -----------------------------------------
0-4 i.e. 5 bits for line offset into a 32 byte line 5-13 i.e. 9 bits for indexing into a 32K 2 way cache (16K/512 sets per way) 14-31 i.e. remaining 18 bits as a physical tag in the virt indexed phys tagged cache
V->0x0000_0000 P->0x0000_0000 V->0x0001_0000 P->0x0000_2000
First lets say the program accesses address 0x0, the cache will be indexed using the 9 index bits in the virt addr (0x0) and the phys tag will be the top 18 bits in the translated addr (again 0x0). Now say the program accesses 0x0001_0000. The cache will be indexed using the index bits which turn out to be 0x0 and the phys tag will also match(top 18 bits) thus causing an incorrect cache lookup.
One way of looking at the problem is that there are insufficient phys tag bits and another is that one bit (bit 13) from virt addr is used to index and it is also translated.
I have take a look at the cache and tlb flush architecture with the help of your documentation. I have also studied sparc64's page coloring to avoid cache aliasing(pte_alloc* in pgalloc.h). But it seems to me that this page colouring can only handle D-cache aliasing and not I-cache aliasing (the above case) since Instruction/code pages mapped from filesystem and not allocated using the pte_alloc* functions.
Is my understanding correct ? Do you have any comments on this issue and how, if at all, I can solve it. Any help would be greatly appreciated.
Regards, Amit
- 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/
| ![\](/images/icornerr.gif) |