On 23/04/11 12:55 PM, Sebastien Bourdeauducq wrote:
b) Use a simple cache with cache associativity * page size = cache size.
Advantages: simple hardware, and solves above problems.
Half the point of the LM32 is the sweet-spot in speed/size that it hits. This approach to an MMU lives at a similar design sweet-spot. I am for it.

Problems: a bit
less flexible, and if we do not want to flush caches at context switches
we must ensure that shared memory areas are mapped at the same virtual
addresses in all processes that use it.

I don't believe you are correct. As long as:
   [associativity]*[page size] >= [cache size]
there should be no problem.

There are only two possible issues that can happen in the cache:

1) Multiple physical addresses map to one virtual address

This is solved by using physical tagging.

2) Multiple virtual addresses map to one physical address

This is solved by the above restriction on cache size.

To be concrete, imagine a shared page. The operating system will only ever map a page aligned (ie: a 4k page won't live offset at position 2k). Any access to the shared page will use the same low bits index into that page (12 bits in our example). Supposing a 16k cache, that means that the page can only have four aliasing locations (the highest 2 bits of the 16k cache's index). With an associativity of 4, that means the cache sees all aliasing when it issues an update/fetch. Thus, there is no problem.

Conclusion: you don't need to ever flush cache and there are no issues.

The approach you are proposing (using the OS to ensure the address match) is useful when you want to BREAK the assumption of [associativity]*[page size] >= [cache size]; ie: you want a bigger cache. Then you can use the OS to limit the number of potential aliases below the limit.

For example, 4-way associative 64k cache with a 4k page size. Now your address indexes into the cache use log(64k/4) = 14 bits compared to the page size of 12 bits. The OS can ensure there are no problems if it makes sure that all mappings of a shared page agree on bits 13 and 14. If the cache had only been 16k there would be no bits for the OS to enforce agreement on.

_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com

Reply via email to