Linux I-cache aliasing problem

From: Amit Bhor
Date: Thu Sep 29 2005 - 10:07:41 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/