Ah, it is likely that you may have problems with pending interruptions and the like, if you want to restore the checkpoint later.
-- Fernando A. Endo, Post-doc INRIA Rennes-Bretagne Atlantique France 2016-02-28 13:34 GMT+01:00 Fernando Endo <[email protected]>: > Hi again, > > Sorry, I misunderstood your initial question. So, if you want to take a > checkpoint without draining the O3 pipe, then you need to get the > architectural state (committed information). Context 0 is ok for > single-core simulation. It seems that readIntReg reads the physical > registers, so be sure to get the already committed ones. It may also > increment the reg file stats. > > Regards, > > -- > Fernando A. Endo, Post-doc > > INRIA Rennes-Bretagne Atlantique > France > > > 2016-02-23 17:56 GMT+01:00 Felipe Rocha da Rosa < > [email protected]>: > >> Hi, >> To surpass this problem, I create my context saver functions by accessing >> the C++ objects using this method to access one integer register. >> >> *getContext(0)->context->readIntReg(faultRegister)* >> >> I`m assuming that if I use only one core will be only the context 0 >> (zero), that`s correct? >> Also, I suppose that the registers that I`m reading are the same on >> */src/arch/arm/intregs.hh. * >> >> enum IntRegIndex >> { >> /* All the unique register indices. */ >> INTREG_R0, >> INTREG_R1, >> INTREG_R2, >> INTREG_R3, >> INTREG_R4, >> INTREG_R5, >> INTREG_R6, >> INTREG_R7, >> INTREG_R8, >> INTREG_R9, >> INTREG_R10, >> INTREG_R11, >> INTREG_R12, >> INTREG_R13, >> INTREG_SP = INTREG_R13, >> INTREG_R14, >> INTREG_LR = INTREG_R14, >> INTREG_R15, >> INTREG_PC = INTREG_R15, >> ... >> >> >> About the switch, I will work on that in the next days thank you for the >> possible solution. >> >> Thanks every one. >> >> ------------------------------ >> >> Best regards, >> >> Felipe Rocha da Rosa, >> >> PhD Student - PGMICRO - UFRGS, >> >> frdarosa.com <http://www.frdarosa.com/> >> >> >> >> ------------------------------ >> Date: Thu, 18 Feb 2016 18:01:53 +0100 >> From: [email protected] >> >> To: [email protected] >> Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error >> >> Hello, >> >> Maybe this workaround could work for you: simulate until the bench ends, >> switch to the atomic CPU and take a checkpoint. >> >> The switch from detailed to atomic works (my gem5 version: >> 11153:20bbfe5b2b86). You'll probably need to modify >> configs/common/Simulation.py to do that. >> >> Hope it helps and boa sorte, >> >> -- >> Fernando A. Endo, Post-doc >> >> INRIA Rennes-Bretagne Atlantique >> France >> >> >> 2016-02-12 1:27 GMT+01:00 Felipe Rocha da Rosa < >> [email protected]>: >> >> Hello, >> Thank you for replying. >> I saw a old email about that, but I didn't know if was fixed or not. >> My idea is not fast forward the execution of a given application. >> Instead, I will change slightly some parameters for each one. Then >> comparing the two executions (using the OoOmodel) using the checkpoints >> information at the end to capture the behavior though some scripts I have. >> I don't want to restore this checkpoints only collect the data, like >> register state, PC and mainly the memory dump. The checkpoint could be at >> any moment during the simulation, and I'm just considering at the end of >> the execution to simplify the question. >> >> At the current moment, I'm trying to use the checkpoint without the drain >> function and appears to work for my purposes. But I still wondering I it >> never drains out. I change some parameters into the drain function without >> success. >> >> ------------------------------ >> >> Best regards, >> >> Felipe Rocha da Rosa >> >> >> >> >> ------------------------------ >> Date: Thu, 11 Feb 2016 08:34:37 -0500 >> From: [email protected] >> >> To: [email protected] >> Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error >> >> Hello Felipe, >> >> I am not sure if I understand your use case completely. I had similar >> problem with creating checkpoints with detailed mode CPU right after >> boot. From the discussion on the mailing list, IIRC checkpoint >> functionality is not tested for ARM detailed CPU as part of Gem5 regression >> tests, so I think I can say that it's not guaranteed to work. In my case, I >> just create checkpoint with atomic boot and restore with detailed CPU. >> >> I am curious, how does creating checkpoint at the end of application >> execution helps? >> >> Thank you >> Rizwana >> >> On Wednesday, February 10, 2016, Timothy Chong <[email protected]> wrote: >> >> Hi, >> >> For me personally, it took me a couple days before I realized that gem5 >> system does not end whatsoever when there is a scheduled event. In other >> words, if you keep on scheduling things, (calling schedule inside your >> wakeup function without any condition), the system never ends. >> >> Not sure if that’s your case. >> >> Best, >> Timothy Chong >> Boston University >> >> Le Feb 10, 2016 à 3:07 PM, Felipe Rocha da Rosa < >> [email protected]> a écrit : >> >> Hi, >> Yes I`m adding a new module (but I schedule events by the number of >> instructions using self.system.cpu[0].scheduleInstStop for exemple), >> however this problem is occurring in the "clean" gem5 from the repository >> (stable or not). The checkpoint never returns from the drain call. >> >> >> Best regards, >> Felipe Rocha da Rosa >> >> ------------------------------ >> >> Best regards, >> >> Felipe Rocha da Rosa, >> >> PhD Student - PGMICRO - UFRGS, >> >> frdarosa.com <http://www.frdarosa.com/> >> >> >> >> ------------------------------ >> From: [email protected] >> Date: Wed, 10 Feb 2016 13:44:57 -0500 >> To: [email protected] >> Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error >> >> Hi, >> >> I had problems that sound very similar to your case just a couple days >> ago. Did you happen to have to write a module yourself? or did you have to >> call « schedule » inside your module in order to tick your own clock? >> >> Thanks, >> Timothy Chong >> Boston University >> >> >> Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa < >> [email protected]> a écrit : >> >> Hi! >> >> I'm trying to execute several slightly different executions of the same >> application using the Detailed (DerivO3CPU) CPU mode and compare then. For >> the purpose, my idea was executing the application and create a checkpoint >> at the end. However, the checkpoint is never complete. I trace the cause to >> the drain function in gem5-stable/src/python/m5/simulate.py, where the >> simulator is called again and so remaining in the loop forever. My question >> is if I can comment/change this line and do not perform the drain() without >> changing the final results. >> >> >> def drain(root): >> # Try to drain all objects. Draining might not be completed unless >> # all objects return that they are drained on the first call. This >> # is because as objects drain they may cause other objects to no >> # longer be drained. >> def _drain(): >> all_drained = False >> dm = internal.drain.createDrainManager() >> unready_objs = sum(obj.drain(dm) for obj in root.descendants()) >> # If we've got some objects that can't drain immediately, then >> simulate >> if unready_objs > 0: >> dm.setCount(unready_objs) >> #WARNING: if a valid exit event occurs while draining, it >> will not >> # get returned to the user script >> exit_event = simulate() >> while exit_event.getCause() != 'Finished drain': >> exit_event = simulate() >> else: >> all_drained = True >> internal.drain.cleanupDrainManager(dm) >> return all_drained >> >> all_drained = _drain() >> while (not all_drained): >> all_drained = _drain() >> >> def checkpoint(dir): >> root = objects.Root.getInstance() >> if not isinstance(root, objects.Root): >> raise TypeError, "Checkpoint must be called on a root object." >> drain(root) >> memWriteback(root) >> print "Writing checkpoint" >> internal.core.serializeAll(dir) >> resume(root) >> >> >> Command: >> ./build/ARM/gem5.opt ./configs/example/se.py -c queens -o 10 >> --cpu-type=detailed --caches --l1i_size=32kB --l1i_assoc=4 --l1d_size=32kB >> --l1d_assoc=4 --l2_size=512kB --l2_assoc=8 --checkpoint-at-end >> >> Thanks in advance! >> >> ------------------------------ >> >> Best regards, >> >> Felipe Rocha da Rosa >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ gem5-users mailing list >> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ gem5-users mailing list >> [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ gem5-users mailing list >> [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
