This seems right with the exception that ASIDs enumerate software contexts while contextIDs enumerate hardware contexts. The prior is visible to the OS while the latter is directly invisible. Beyond making virtual caching structures you can use it to create stats about which software thread did something.
It seems sensible to get rid of the threadID. Ali On 07.10.2013 04:14, Andreas Sandberg wrote: > On 10/04/2013 06:28 PM, Steve Reinhardt wrote: > >> On Fri, Oct 4, 2013 at 8:24 AM, Ali Saidi <[email protected]> wrote: >> >>> I think ThreadId is supposed to be the SMT thread, and context id is supposed to be the execution context number. These seems to not be very well defined and could certainly use some cleanup. >> I believe the primary purpose of these fields is for tracking statistics by hardware thread context in the memory system (i.e., they're not supposed to be functionally visible, they're just for analysis). IIRC, originally we had a CPU ID for this purpose, then when we added SMT we added a thread ID, then dealing with combination of the two became awkward so the CPU ID was replaced with a "context ID" that's supposed to enumerate HW thread contexts across all CPUs. Somehow when that happened though we did not (or were unable to) remove the thread ID, so it's still around too. > > Thanks for clarifying all of this. > > So, if I understand this correctly, what we have is this: > > * The ASI field is really just a bunch of architecture-specific bits. > Judging from Ali's response to RB2032, that seems to be the case on ARM > at least. > > * ASID enumerate threads across all CPUs in order to make VIVT caches > work. Currently unused or identical to Context ID. (ARM changes under way.) > > * Context IDs are global and enumerate threads across all CPUs. They > seem to be used mainly for presentation purposes. > > * Thread IDs are CPU-local and represent a thread in an SMT configuration. > > If I understand this correctly, we should really rename the ASI field to > something more appropriate like "architecture-dependent flags" since > that's how it is used. Additionally, it seems to be like thread IDs, > which are CPU-specific, should only be used inside CPU models and > context IDs, which are globally unique, should be used outside of CPU > modules. > > //Andreas > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev [1] Links: ------ [1] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
