Cache aliasing issues using 4K pages.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We are working with a 2.6.12 kernel on a dual-core mips architecture.
In this dual-core system, one core is running the linux kernel and the
other is used for some real-time handling (not directly controlled by
Linux)
We had different stability issues, which could be pinpointed to be
related with cache aliasing problems.
Cache aliasing happens when the same physical memory can be cached
twice as it is accessed by two different virtual addresses.
Indeed, for the index to select the correct cache line the virtual
address is used. If some bits of the virtual page address are used in
the cache index, aliasing can occur.


As there is no hardware solution in the mips to recover from this
(which would provide some cache coherency, even for one core), the
only intrinsic safe solution is to enlarge the page size, so that
cache indexing is only done by the offset address in the page (thus
the physical part of the address).
Another solution is to flush the cache if a page is being remapped to
an aliased address (but in our case linux does not has control on the
second core, which can cause issues with shared data between both
cores).
Currently the second solution is used in the kernel, but we found
different issues with it (for instance: we had to merge more recent
mips kernels, to get a reliable copy-on-write behaviour after
forks...).

Therefore some questions:
- Are there still some known issues with cache aliasing in the MIPS kernel?
- Are there known issues when using 16KB pages (8KB pages seems not be
possible due to tlb issues).

Thanks in advance,
Luc


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux