i think the convention is any acronym should be all caps, but I'm not sure.
2008/10/24 Lisa Hsu <[EMAIL PROTECTED]>: > what do we all like better, cpuID/contextID, or cpuId/contextId? > > lisa > > On Fri, Oct 24, 2008 at 6:07 PM, nathan binkert <[EMAIL PROTECTED]> wrote: >> >> 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 >> > > > _______________________________________________ > 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
