The Engineer wrote: > 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). With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12 kernel however you'll have to backport a serious amount of bugfixes before 16k pages can work. Upgrading the kernel is probably less work. Thiemo
