Hi, On Fri, 2011-04-15 at 11:55 +0200, Norman Feske wrote: > Indeed. For the scenario of piping data through a memory page shared > between producer and consumer, a physically indexed D-cache would > provide the best performance.
Remember that each physically indexed cache increases the CPU pipeline length by one stage... which in turn adds one cycle at each mispredicted jump (and leads to more complex pipeline control logic). > The data between producer and consumer > could then travel directly through the cache regardless at where the > shared memory is mapped in each process. If I understand correctly, when > using a virtually-indexed physically-tagged cache (or task IDs for that > matter), each physical address would end up in the cache twice (one copy > for each process). Would the cache be designed to associate those cache > lines with each other? How is the consistency between both copies > maintained? I.e., is the cache line of the consumer invalidated when the > producer writes data to his respective cache line? Hmm, can we make the OS try to put every shared memory area at the same virtual address in all processes that uses it (and flush the caches if it can't)? Or is that too strict of a constraint? There would be a full 4GB virtual address space so this leaves some freedom for such things... > > BTW, we are using 4KB I and D caches in the Milkymist SoC, so if we fix > > the page size to 4KB as well we'd avoid aliasing problems entirely (the > > L2 cache would be physically indexed and tagged). > > Are you speaking about the MMU page size? Yes. > In our experience, the use of > different page sizes makes a huge difference for performance when using > a software-loaded TLB because each TLB miss must be resolved in > software. If the TLB has 64 entries and you pin the page size to 4K, a > massive amount of page-faults will be generated as soon as the working > set exceeds 256K of memory. Only decreasing the page size causes cache aliasing problems - increasing it does not. So you would still be free to use pages of any size above 4K. S. _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
