Oh - wrt to that patch I don't think that matters. Since this is specific to the standard switch, every cpu you are simulating has an atomic, timing, and o3 version, and just setting cpu0 would mean setting one of the atomic cpus, which can't possibly be switched out because you're starting with it to run the sim.
Lisa On Tue, Dec 16, 2008 at 3:10 PM, Ali Saidi <[email protected]> wrote: > I mean the patch you committed a few weeks ago that cleaned up all the > tid/cpuid/etc stuff. My comment is that unless cpu 0 is always active > and not switched out, just setting it on cpu 0 won't work. > > Ali > > On Dec 16, 2008, at 2:52 PM, Lisa Hsu wrote: > > > The patch I sent does nothing but change the number of cycles the > > initial atomic CPUs run before switching to timing in the standard- > > switch scenario. > > > > Steve's suggestion is just that only atomicCPU0 has a limit set, all > > the rest run "forever" but of course, atomicCPU0 will always hit a > > short number of instructions quickly so it doesn't matter. Which I > > think is probably better for this particular case. > > > > Lisa > > > > On Tue, Dec 16, 2008 at 1:35 PM, Ali Saidi <[email protected]> wrote: > > > > Does Lisa's change always create a cpu 0? Is there a cpu 0 that is > > always running? Otherwise, the only issue I see is that CPU 0 might > > not be active at the moment and thus you would never hit the event > > (e.g. if you switched out cpu 0 for something else). > > > > Ali > > > > > > > > On Dec 16, 2008, at 12:22 PM, Lisa Hsu wrote: > > > > > Yes, that would work too. Probably a better solution for this > > > case. It feels not as "pretty", but I suppose that doesn't matter. > > > I guess I like symmetry too much. > > > > > > Lisa > > > > > > On Tue, Dec 16, 2008 at 11:59 AM, Steve Reinhardt <[email protected]> > > > wrote: > > > Is there a reason why we schedule an event on all the cpus? Would > > it > > > work just to schedule the event on cpu 0? > > > > > > Steve > > > > > > On Mon, Dec 15, 2008 at 2:39 PM, Lisa Hsu <[email protected]> > > wrote: > > > > Try the attached patch. > > > > > > > > To anyone interested: > > > > > > > > for the initial switch from atomic to timing is set at > > > > cpu[i].max_insts_any_thread = 1, for all cpu=i. the idea for > > > > max_insts_any_thread is that when the first cpu hits that value, > > > an exit > > > > event is scheduled - but since in this case all N cores hit 1 in > > > the exact > > > > same cycle, 4 exit events are scheduled. > > > > > > > > so after the switch to timing, the first exit event has been dealt > > > with but > > > > there are still 3 more, which essentially kill your attempts to > > > drain. > > > > > > > > this is a pretty silly fix, making the initial atomic phase last > > > 100 insts > > > > just to reduce the probability that this will never happen again, > > > but > > > > doesn't rigorously remove that possibility. if anyone has a > > > better idea of > > > > how to fix this let me know. > > > > > > > > Lisa > > > > > > > > On Mon, Dec 15, 2008 at 9:44 AM, Lisa Hsu <[email protected]> > > > wrote: > > > >> > > > >> I'm working on this. Stay tuned. > > > >> > > > >> Lisa > > > >> > > > >> On Fri, Dec 12, 2008 at 7:50 PM, Eduardo Olmedo Sanchez > > > >> <[email protected]> wrote: > > > >>> > > > >>> These are the changes that I did to the fs.py file: > > > >>> > > > >>> np = options.num_cpus = 4 > > > >>> > > > >>> test_sys.l2 = L2Cache(size = '4MB', assoc = 4, latency = '30ns') > > > >>> > > > >>> test_sys.cpu[i].addPrivateSplitL1Caches(L1Cache(size = '64kB', > > > assoc > > > >>> = 2, latency = '2ns'), > > > >>> L1Cache(size = > > > '64kB', > > > >>> assoc = 2, latency = '2ns')) > > > >>> > > > >>> I did not do any other changes to the source code. > > > >>> > > > >>> On Fri, Dec 12, 2008 at 4:21 PM, Ali Saidi <[email protected]> > > > wrote: > > > >>> > Have you changed the default configuration any? It appears > > > from your > > > >>> > command line that you would only get one cpu. > > > >>> > > > > >>> > Ali > > > >>> > > > > >>> > On Dec 12, 2008, at 11:50 AM, Bob Nagel wrote: > > > >>> > > > > >>> >> Hello Ali, > > > >>> >> > > > >>> >> What do you mean with devices?, if you are talking about if I > > > do any > > > >>> >> changes something in the code of the simulator, I have not > > > done any > > > >>> >> changes. The value of event->getCount() is 4. > > > >>> >> > > > >>> >> Thanks. > > > >>> >> > > > >>> >> 2008/12/11 Ali Saidi <[email protected]>: > > > >>> >>> It looks like a serialization bug to me. What devices are > > > you using? > > > >>> >>> Just the defaults? Can you print out event->getCount() to > > > see what > > > >>> >>> the > > > >>> >>> value is? i imagine that some object is double executing a > > > drain > > > >>> >>> event, but the count would say for sure. > > > >>> >>> > > > >>> >>> Ali > > > >>> >>> > > > >>> >>> > > > >>> >>> > > > >>> >>> On Dec 11, 2008, at 9:30 PM, Bob Nagel wrote: > > > >>> >>> > > > >>> >>>> Hello I am getting this error when I am running a > > > simulation in FS > > > >>> >>>> this is what I am doing: > > > >>> >>>> > > > >>> >>>> I start the simulation in atomic model to load linux and I > > > take a > > > >>> >>>> checkpoint to keep simulating in detail model when the > > > script starts > > > >>> >>>> running: > > > >>> >>>> > > > >>> >>>> This is the command to take the checkpoint > > > >>> >>>> ./build/ALPHA_FS/m5.opt -d ./tmp/output configs/example/ > > > fs.py -b > > > >>> >>>> MyBench --checkpoint-dir=./checkpoint/ > > > >>> >>>> > > > >>> >>>> This is my rcS file: > > > >>> >>>> > > > >>> >>>> #!/bin/sh > > > >>> >>>> /sbin/m5 checkpoint > > > >>> >>>> /sbin/m5 switchcpu > > > >>> >>>> /sbin/m5 dumpstats > > > >>> >>>> /sbin/m5 resetstats > > > >>> >>>> cd /parsec/install/bin > > > >>> >>>> ./freqmine /parsec/install/inputs/freqmine/kosarak_250k.dat > > > 220 > > > >>> >>>> echo "DONE :D" > > > >>> >>>> /sbin/m5 exit > > > >>> >>>> > > > >>> >>>> And when I restore from the checkpoint with this command I > > > get this > > > >>> >>>> error: > > > >>> >>>> > > > >>> >>>> ./build/ALPHA_FS/m5.opt -d ./tmp/output configs/example/ > > > fs.py -b > > > >>> >>>> MyBench --caches --l2cache -s -w 200000000000 -r 1 > > > >>> >>>> --checkpoint-dir=./checkpoint/ > > > >>> >>>> > > > >>> >>>> switching cpus > > > >>> >>>> Switch at instruction count:0 > > > >>> >>>> info: Entering event queue @ 1815525533500. Starting > > > simulation... > > > >>> >>>> Switching CPUS @ cycle = 1815525533500 > > > >>> >>>> Simulation ends instruction count:0 > > > >>> >>>> info: Entering event queue @ 1815525533500. Starting > > > simulation... > > > >>> >>>> m5.opt: build/ALPHA_FS/python/swig/pyevent.cc:84: void > > > >>> >>>> cleanupCountedDrain(Event*): Assertion `event->getCount() > > > == 0' > > > >>> >>>> failed. > > > >>> >>>> Program aborted at cycle 1815525533500 > > > >>> >>>> Aborted > > > >>> >>>> > > > >>> >>>> In my script I am running the simulation with 4 cpus, but > > the > > > >>> >>>> thing is > > > >>> >>>> that when I put only 1 cpu the simulation runs without any > > > >>> >>>> problem, is > > > >>> >>>> this a bug of the simulator?. I am using the latest stable > > > version > > > >>> >>>> from three weeks ago. And another thing when I restore from > > > the > > > >>> >>>> checkpoint I get many warns like this one: > > > >>> >>>> > > > >>> >>>> warn: Not unserializing > > > >>> >>>> 'system.switch_cpus_10.fuPool.FUList2.opList2': no section > > > found in > > > >>> >>>> checkpoint. > > > >>> >>>> > > > >>> >>>> Thanks. > > > >>> >>>> _______________________________________________ > > > >>> >>>> m5-users mailing list > > > >>> >>>> [email protected] > > > >>> >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > >>> >>>> > > > >>> >>> > > > >>> >>> _______________________________________________ > > > >>> >>> m5-users mailing list > > > >>> >>> [email protected] > > > >>> >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > >>> >>> > > > >>> >> _______________________________________________ > > > >>> >> m5-users mailing list > > > >>> >> [email protected] > > > >>> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > >>> >> > > > >>> > > > > >>> > _______________________________________________ > > > >>> > m5-users mailing list > > > >>> > [email protected] > > > >>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > >>> > > > > >>> _______________________________________________ > > > >>> m5-users mailing list > > > >>> [email protected] > > > >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > >>> > > > >> > > > > > > > > > > > > _______________________________________________ > > > > m5-users mailing list > > > > [email protected] > > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > > _______________________________________________ > > > m5-users mailing list > > > [email protected] > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > > > > _______________________________________________ > > > m5-users mailing list > > > [email protected] > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
