> From : Ralf Baechle <[EMAIL PROTECTED]>
>
> All MIPS R4000 and better caches are virtual indexed
> and therefore affected by this problem.
I knew the older systems had virtual caches, but I assumed
that the newer systems were physically indexed since Linux
clearly ignored the problem.
> Can you give an example where this happens? While I know
> that we have this problem since '94 I've never seen a real
> world case of this problem.
We have a database being ported that has a shared memory
lock region at various alignments. I guess the lock manager
is a different executable than the database engine tasks, so
the auto-selected base addresses varied because of different
collections of dynamic libraries.
Locks were getting cached values that differed from the values
seen in other processes. This bothered the database. :-)
> This obviously is the simplest solution but I'm not really
> sure how this looks from the perspective from standards and
> real world application software. Let me verify this.
Well, the right solution would be for a shared map to contain
the base virtual address in the creating process, and the system
could then verify that the later alignment met any platform
specific requirements.
Of course if mmap() shares pages with the buffer cache, those
need to be kept aligned, too.
Things get really fun when physical addresses need to align
with virtual, eg block translation units.
> Linus _hates_ virtual indexed caches of the sucky kind like
> this ones and is not willing to accept patches which by his
> view clutter the kernel ...
Given the vast collection of brain dead hardware, virtually
tagged caches aren't anywhere near sucky on my list. There
are usually valid technical reasons for these cache designs,
such as saving delays on a critical timing path. Of course
you can avoid this problem with a simple solution: infinite
hardware design resources.
cj*
