Although I've already mentioned there are absolutely no problems with a
VIPT mmu/cache design under the cache-size assumption Sebastien worked
with, there is *also* no problem with exceeding this cache-size
restriction for an operating system like linux. I'll explain why below.
On 25/04/11 07:18 PM, Norman Feske wrote:
In general, this is a rather unwelcome restriction. E.g., look at the
mmap syscall on Linux, which enables each process to map (potentially
different parts of) the same file at (potentially multiple) virtual
address regions. Of course, multiple processes may do so for the same
file.
Linux does *not* allow you map pages wherever you like. The mmap syscall
is free to reject every proposed location you suggest. Just try any
unaligned address; they will all fail. To ensure that file-backed mmap
doesn't lead to inconsistent caching, linux just has to increase the
required alignment.
For example, suppose a 64k cache 4-way associative cache with a 4k page
size. Now, linux just has to make sure that every mapping of that
file-backed page match on bits 13 and 14. This can be achieved by mmap
requiring 16k alignment to the file offset, a perfectly permissible
restriction according to POSIX.
I acknowledge your reservations against a physically indexed cache.
A physically indexed cache would require us to add a new pipeline stage
in the LM32. That would require a complete redesign of the CPU.
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com
