> If it's timing, it will have to be event-driven and incremental. Even > if you bypass the local cache's write buffer, there will possibly be > other finite write buffers down the line (e.g. if you are flushing an > L1, the L2 could stall on you). So you might as well just use the > existing ports and buffers. That makes complete sense to me.
> Once you bite the bullet and set up the framework for an event-driven > incremental flush, it's not that bad. But it's still way harder than > just writing a simple loop like you could if you use functional > accesses. > > In what environment do you want to flush the cache and care about the > timing impact of actually performing the flush? I just know that there have been several times when I've thought of systems where you'd want to be able to flush all of the lines for a particular asid. This would be for non-coherent shared memory systems and process migration between non-coherent domains. I haven't done any work on this area yet, but I think it makes sense for manycore if you believe that server consolidation is one of the bigger workloads. I think that this sort of thing could also be used for a forced migration of lines from one cache to another. None of it is necessary for anything today, but would be interesting to investigate in the future. > Another (even more realistic) approach is to add some magic addresses > to flush individual lines, then do it in software on the CPU (just > like how you would do it on a real machine). That is something we definitely need, but that only works on addresses. It's certainly needed for the icache and self modifying code. (Since the icache is not coherent in many systems.) Nate _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
