The OS interface to that doesn't work that way. Linux for example treats all threads and cores and such as different CPUs, it just knows that certain CPUs share certain resources. i.e. it uses one global id and just has extra knowledge about how things interact in the scheduler.
So, each global context ID should be reported as a separate CPU to linux. Any actual coreID (maybe that's a better name) or cpuID or threadID would be only used in the simulator Nate On Fri, Oct 24, 2008 at 2:50 PM, Korey Sewell <[EMAIL PROTECTED]> wrote: > I do think a thread ID per core is necessary as you need to give OS's > the ability to assign to a specific thread in a core and not treat all > SMT cores as a separate CPU in every case. > > On Fri, Oct 24, 2008 at 5:47 PM, nathan binkert <[EMAIL PROTECTED]> wrote: >> 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 >> > > > > -- > ---------- > 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
