I just skimmed that paper (not surprised to see Gernot Heiser's name there!) and I think that, while it would be a little bit of work, it might not be *too* hard to implement something like fence.t for the caches. It would be substantially different from wbinvd. The latter speaks to the whole cache system, and I implemented it by a request that flows all the way up to the Point of Coherence (memory bus) and back down as a new kind of snoop to all the caches that talk through one or more levels to memory. Then each cache essentially has a little engine for writing dirty lines back. It's that part that would be useful here - I guess we'd be looking at a variation on it, triggered in a slightly different way (not by a snoop, but by a different kind of request). To get sensible timings you'd need to decide what hardware mechanisms are available for finding dirty lines. I assumed they were indexed in some way that finding at least a set with one or more dirty lines had no substantial overhead. L1 cache is small enough that we might get by with that assumption. Alternatively, assuming each set provides an "at least one dirty line" bit, and that 64 of the these set bits can be examined by a priority encoder to give you a set to work on - or indicate that all 64 sets are clean - then a typical L1 cache would not need many cycles of reading those bits out to find the relevant sets.
For 64 KB cache, 64 B lines, associativity 2, there are 512 sets, meaning we'd need to read 8 groups of 64 of these "dirty set" bits. The actual writing back would usually take most of the time. Presumably you would need to wait until all the dirty lines make it to L2, since if the writeback buffers are clogged there might still be a communication channel there. Still, by the time a context switch is complete, those buffers may be guaranteed to have cleared - provided we can make an argument that there is a fixed maximum amount of time needed for that to happen. Anyway, I hope this helps. Eliot Moss _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
