I'd say that a globally unique contextID is critical. A threadID that is per core can of course be created if necessary, but I bet that in most instances, we can just pass pointers around.
Nate > I mostly agree with this, except that it might be tricky to use the context > ID t > index into a vector of thread contexts when the numbering doesn't start over > for > each CPU. Other than that it looks like we're strictly getting closer to the > right answer at least. > > Gabe > > Quoting Lisa Hsu <[EMAIL PROTECTED]>: > >> yes, that's what i mean. >> >> believe it or not, right now if you run se.py -n4, all four cpus get cpuId = >> 0 (regardless of which cpu type you use). talk about broken. >> >> and from now on, getCpuId() should pretty much only be used for things like >> stats, or as a secondary identifier, the primary thing to care about is the >> HW context ID. >> >> On Fri, Oct 24, 2008 at 4:51 PM, Korey Sewell <[EMAIL PROTECTED]> wrote: >> >> > Are you saying make a distinction between the cpu ID and the actual >> > hardware context ID? This is something definitely needed. >> > >> > I think this is what you describe below... I'm seeing something where >> > there is a: >> > getCpuId() and a getContext() function. >> > >> > On a 2-way SMT system with 1 CPU... >> > process0->getCpuId() = 0 >> > process0->getContext() = 0 >> > process1->getCpuId() = 0 >> > process1->getContext() = 1 >> > >> > but with a 2-CPU system , No-SMT... >> > process0->getCpuId() = 0 >> > process0->getContext() = 0 >> > process1->getCpuId() = 1 >> > process1->getContext() = 1 >> > >> > and finally, a 2-way SMT, 2-cpu system... >> > process0->getCpuId() = 0 >> > process0->getContext() = 0 >> > process1->getCpuId() = 0 >> > process1->getContext() = 1 >> > process2->getCpuId() = 1 >> > process2->getContext() = 2 >> > process3->getCpuId() = 1 >> > process3->getContext() = 3 >> > >> > Is this what you describe, by all means all systems go! >> > >> > 2008/10/24 Lisa Hsu <[EMAIL PROTECTED]>: >> > > Hi All, >> > > >> > > In case you haven't guessed it, I'm hacking on M5 once again. I've >> > noticed >> > > recently that there is a big hot mess when it comes to identification >> > > mechanisms for CPUs, threads, and contexts. Alternately all contexts are >> > > assumed to be separate CPUs (which is wrong when there is SMT), vs times >> > > when CPUs are CPUs and threads are subsets of certain CPUs such that a >> > > system can have names like CPU0,T0; CPU,T1; CPU1,T0; CPU1,T1, etc. >> > > >> > > I talked about it with Steve today and here's what I propose, let me know >> > if >> > > you object. >> > > >> > > All CPUs with have an ID, but this will not be a primary context >> > > identification mechanism. In other words, in many places where >> > > tc->getCpuId() is used in order to index into a threadContexts vector, it >> > > will be changed so that tc->getIdentifier() will give back something >> > unique >> > > across the system. >> > > >> > > The primary context identification mechanism will be a system-wide >> > context >> > > id-value. That means in a 2 CPU 2 thread SMT system, you will have >> > > system-wide context IDs of 0-3. So the tc->getCpuId() mentioned above >> > will >> > > be changed to something like tc->getContextId(). >> > > >> > > Each context will still have a pointer to the CPU it belongs to, which in >> > > turn will have an ID value so you can always know which CPU you belong to >> > if >> > > you want. >> > > >> > > >> > > I'm going to start working on this now, so speak now or forever hold your >> > > peace. :) >> > > >> > > Lisa >> > > >> > > _______________________________________________ >> > > m5-dev mailing list >> > > m5-dev@m5sim.org >> > > http://m5sim.org/mailman/listinfo/m5-dev >> > > >> > > >> > >> > >> > >> > -- >> > ---------- >> > Korey L Sewell >> > Graduate Student - PhD Candidate >> > Computer Science & Engineering >> > University of Michigan >> > _______________________________________________ >> > m5-dev mailing list >> > m5-dev@m5sim.org >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> > > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
