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
