The BIOS identifies all of the CPUs to the OS, but the arrangement is deduced by the OS I believe.
Nate 2008/10/24 Lisa Hsu <[EMAIL PROTECTED]>: > where does this reporting to linux happen? > > On Fri, Oct 24, 2008 at 5:53 PM, nathan binkert <[EMAIL PROTECTED]> wrote: >> >> 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 >> > > > _______________________________________________ > 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
