Hi Sebastien, > 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'm not familiar enough with how > OSes deal with virtual memory to know if this is a strong constraint or > not. Comments?
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. For this horror scenario, your proposed solution would be a bad fit. Even though I agree that such scenarios are rare, they are a nightmare to debug once they occur. If the OS API is as flexible as mmap (i.e., this is the case for the OS that we're developing), the OS must somehow deal with such situations, or at least detect them. That said, I acknowledge your reservations against a physically indexed cache. So I think it would be sensible to go for your proposal b) and see how far we get. At least for our custom OS, I have a few ideas in mind about how to handle the aliasing problems. For Linux, I don't know. In my experience, there are cases when user-level software knows about the shared-memory nature of memory mappings and can take precautions about potential aliasing problems by itself. E.g., an application painting onto the surface of a virtual framebuffer provided by a GUI service. For such cases, an instruction in the line of 'clflush' (as provided by the x86 architecture) would be good to have. It enables the program to explicitly flush cache lines by specifying a virtual address. Cheers Norman _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
