On Jul 7, 2011, at 8:29 PM, Nathan Binkert wrote: > 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. I think you're correct that it's amazingly confusing. We have threadId, contextId, and cpuId and as far as I know there is no real consistency about what is used where. Some devices check the contextId when they want to know what cpu # made the request, while others check the cpuId. A big issue with SMT is if we ever want it to work (at least the way products work today) in full system, these devices are going to need to see each thread as a context/cpu not as a thread. Interrupt controllers sometimes do different things depending on which cpu is currently accessing them so they need to know which one is.
> > 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? I think we should take the somewhat reverse approach and just make everything a contextId (including the threads). Two threads on 1 cpu would each have a different context ID. Along those same lines, do we really want a cpuId, and a contextId. Why not just use the contextId everywhere and completely get rid of cpuId. There is already some code that tries to make them the same in register thread contexts. Ali _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
