>> 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.
That's more or less what I meant. For each CPU, there'd be a map<ContextID, ThreadID>. The point of the mapping is that there are several arrays of things that are per-thread in the CPU object and they need some sort of linearized index. That's essentially what the threadID is. Instead of arrays, I could do a map<ContextID, Foo> for each Foo that is per context, but that seems like a major pain in the butt to be honest. As for CpuId (which I didn't consider because it's not in the request object and not seen in the memory system code), I agree that we should eventually just get to ContextId being the only thing that is passed around, but I'd prefer to save that change for later (unless it turns out to be trivial which at first glance, I doubt). Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
