I've looked into how sampling/switchover currently works. basically you have timing cpus[0,1] and during the handoff, the new cpus's ID values get set to timing cpus[0,1], such the new and old cpus and contexts match. there are a few asserts to make sure this is so. I don't think this will change anything, in this regard I think i'ts more of a semantic cleanup rather than anything functionally different.
On Fri, Oct 24, 2008 at 6:23 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > cpuId/contextId.... > > Some other comments to throw in the mix: > How does this affect switch-over and sampling? Does each unique cpu in > the system have a different id? (e.g. If you start with two timing > cpus (0,1) and then switch to two details cpus (2,3) would you have > statistics for cpus 2,3?) I think the answer is you would. Are we ok > with that? > > > One other point, while cpuid 0 is specified by the python, when the > thread contexts are created I believe that each cpu is given a unique > id in registerContext(). > it's not, it's broken. it works in FS, but not in SE, necessarily. for SE, registerContexts registers a tc with a process, so for all the cpus pointing to the same process, they get a unique cpuId only within that process. Lisa > > Ali > > On Oct 24, 2008, at 6:20 PM, Lisa Hsu wrote: > > > 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 > > _______________________________________________ > 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
