As usual, I'm getting into another hairy mess when trying to fix something else (python stats).
We currently have context IDs and thread IDs. Lisa and I were trying to make it so that a context id was a system wide namespace with a unique ID assigned to anything that could generate a memory request. (Perhaps contextID is no longer the best name, but we can deal with that later). A threadID is a per-cpu namespace that refers to the threads within a CPU. I'm trying to make it so any cache stat that is per thread or per sharer is simply per context. Yes, there will be a lot of zeroes, but it will be way easier to fix things this way. So, the question in my mind becomes, should we have a threadID stored in the request? Part of me thinks that this is harmless. Another part of me thinks that the presence of the thread ID has lead to a lot of confusion in the past and that we should remove it. The only catch about removing the threadID is that the o3 CPU stashes the thread ID in the request and reads it back later to determine which LSQ_Unit should handle the read/write request. I could generate (and store) a per-cpu mapping of contextID to threadID to get it back, but this would mean extra lookups on every read/write request. My guess is that the impact of this is trivial. Any opinions? Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
