You need to flush the private caches of that processor. In an actual
system, you would have to write back all dirty data to memory. In
Simics+Ruby, you could possibly cheat because Ruby doesn't keep track of
data. However even that isn't so simple because if you do have shared
data that is owned by the processor being shutdown, then you really do
need to initiate replacement operations so that the directory would not
generate forward messages to your shutdown processor.
So I think first you need to make sure all outstanding requests finish
at that processor, then you need to walk the cache and initiate
replacement operations for every cached line.
In other words, I don't think shutting down a processor is as easy as
just wiping the CacheMemory objects, TBEs (transaction buffer
entry...otherwise known as MSHRs), etc.
--Mike
Mladen Nikitovic wrote:
Hi,
right, that makes sense. I didn't shutdown the processor at that time,
so I can imagine the scenario that you described.
I have a follow up-question: If I want to simulate the side-effects of a
processor shutdown by flushing the context of all buffers and memories
on that particular processor, which structures do I need to consider?
So far, I am only flushing the i- and d-cache. I know there is a
store-buffer somewhere, a directory for the cache, and I guess there is
a TLB also, but I cannot find the structure name for it. By the way,
what does TBE stand for?
Are there any other structures I have forgotten?
Thanks for your help.
/Mladen
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}