Discussion:
Checkpoint in detailed cpu causing error
(too old to reply)
Felipe Rocha da Rosa
2016-02-10 18:31:58 UTC
Permalink
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
Timothy Chong
2016-02-10 18:44:57 UTC
Permalink
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 <***@gmail.com> 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
> gem5-***@gem5.org <mailto:gem5-***@gem5.org>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users <http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
Felipe Rocha da Rosa
2016-02-10 20:07:27 UTC
Permalink
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

From: ***@bu.edu
Date: Wed, 10 Feb 2016 13:44:57 -0500
To: gem5-***@gem5.org
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 ChongBoston University

Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa <***@gmail.com> 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 listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Timothy Chong
2016-02-10 23:29:16 UTC
Permalink
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 <***@gmail.com> 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: ***@bu.edu
> Date: Wed, 10 Feb 2016 13:44:57 -0500
> To: gem5-***@gem5.org
> 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 <***@gmail.com <mailto:***@gmail.com>> 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
> gem5-***@gem5.org <mailto:gem5-***@gem5.org>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users <http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>
> _______________________________________________ gem5-users mailing list gem5-***@gem5.org <mailto:gem5-***@gem5.org>http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users <http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>_______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org <mailto:gem5-***@gem5.org>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users <http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
Rizwana Begum
2016-02-11 13:34:37 UTC
Permalink
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 <***@bu.edu> 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 <
> ***@gmail.com
> <javascript:_e(%7B%7D,'cvml','***@gmail.com');>> 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: ***@bu.edu <javascript:_e(%7B%7D,'cvml','***@bu.edu');>
> Date: Wed, 10 Feb 2016 13:44:57 -0500
> To: gem5-***@gem5.org
> <javascript:_e(%7B%7D,'cvml','gem5-***@gem5.org');>
> 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 <
> ***@gmail.com
> <javascript:_e(%7B%7D,'cvml','***@gmail.com');>> 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
> gem5-***@gem5.org <javascript:_e(%7B%7D,'cvml','gem5-***@gem5.org');>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.org <javascript:_e(%7B%7D,'cvml','gem5-***@gem5.org');>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org <javascript:_e(%7B%7D,'cvml','gem5-***@gem5.org');>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
Felipe Rocha da Rosa
2016-02-12 00:27:41 UTC
Permalink
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: ***@gmail.com
To: gem5-***@gem5.org
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 youRizwana

On Wednesday, February 10, 2016, Timothy Chong <***@bu.edu> 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 ChongBoston University
Le Feb 10, 2016 à 3:07 PM, Felipe Rocha da Rosa <***@gmail.com> 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

From: ***@bu.edu
Date: Wed, 10 Feb 2016 13:44:57 -0500
To: gem5-***@gem5.org
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 ChongBoston University

Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa <***@gmail.com> 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 listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________ gem5-users mailing list gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users_______________________________________________gem5-users mailing listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Fernando Endo
2016-02-18 17:01:53 UTC
Permalink
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 <***@gmail.com>
:

> 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: ***@gmail.com
>
> To: gem5-***@gem5.org
> 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 <***@bu.edu> 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 <
> ***@gmail.com> 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: ***@bu.edu
> Date: Wed, 10 Feb 2016 13:44:57 -0500
> To: gem5-***@gem5.org
> 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 <
> ***@gmail.com> 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
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
Felipe Rocha da Rosa
2016-02-23 16:56:23 UTC
Permalink
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

Date: Thu, 18 Feb 2016 18:01:53 +0100
From: ***@gmail.com
To: gem5-***@gem5.org
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 <***@gmail.com>:



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: ***@gmail.com
To: gem5-***@gem5.org
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 youRizwana

On Wednesday, February 10, 2016, Timothy Chong <***@bu.edu> 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 ChongBoston University
Le Feb 10, 2016 à 3:07 PM, Felipe Rocha da Rosa <***@gmail.com> 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

From: ***@bu.edu
Date: Wed, 10 Feb 2016 13:44:57 -0500
To: gem5-***@gem5.org
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 ChongBoston University

Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa <***@gmail.com> 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 listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________ gem5-users mailing list gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users_______________________________________________gem5-users mailing listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-***@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________

gem5-users mailing list

gem5-***@gem5.org

http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Fernando Endo
2016-02-28 12:34:23 UTC
Permalink
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 <***@gmail.com
>:

> 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: ***@gmail.com
>
> To: gem5-***@gem5.org
> 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 <
> ***@gmail.com>:
>
> 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: ***@gmail.com
>
> To: gem5-***@gem5.org
> 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 <***@bu.edu> 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 <
> ***@gmail.com> 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: ***@bu.edu
> Date: Wed, 10 Feb 2016 13:44:57 -0500
> To: gem5-***@gem5.org
> 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 <
> ***@gmail.com> 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
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________ gem5-users mailing list
> gem5-***@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
Fernando Endo
2016-02-28 12:38:32 UTC
Permalink
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 <***@gmail.com>:

> 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 <
> ***@gmail.com>:
>
>> 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: ***@gmail.com
>>
>> To: gem5-***@gem5.org
>> 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 <
>> ***@gmail.com>:
>>
>> 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: ***@gmail.com
>>
>> To: gem5-***@gem5.org
>> 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 <***@bu.edu> 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 <
>> ***@gmail.com> 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: ***@bu.edu
>> Date: Wed, 10 Feb 2016 13:44:57 -0500
>> To: gem5-***@gem5.org
>> 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 <
>> ***@gmail.com> 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
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> _______________________________________________ gem5-users mailing list
>> gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> _______________________________________________ gem5-users mailing list
>> gem5-***@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> _______________________________________________ gem5-users mailing list
>> gem5-***@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
Felipe Rocha da Rosa
2016-03-01 22:26:29 UTC
Permalink
Hello,
The checkpoint without drain where not intended to be restored in any way, this was only a way to access quickly the final processor context. For this now I`m accessing the thread context through the C++ objects but I still using the checkpoint to get the memory dump files. Any way, the switching of processor works and is possible get atomic checkpoints during a detailed execution and later restore as detailed without problems.
Thank you,
Best regards, Felipe Rocha da Rosa,PhD Student - PGMICRO - UFRGS

Date: Sun, 28 Feb 2016 13:38:32 +0100
From: ***@gmail.com
To: gem5-***@gem5.org
Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error

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 <***@gmail.com>:
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 <***@gmail.com>:



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

Date: Thu, 18 Feb 2016 18:01:53 +0100
From: ***@gmail.com
To: gem5-***@gem5.org
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 <***@gmail.com>:



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: ***@gmail.com
To: gem5-***@gem5.org
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 youRizwana

On Wednesday, February 10, 2016, Timothy Chong <***@bu.edu> 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 ChongBoston University
Le Feb 10, 2016 à 3:07 PM, Felipe Rocha da Rosa <***@gmail.com> 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

From: ***@bu.edu
Date: Wed, 10 Feb 2016 13:44:57 -0500
To: gem5-***@gem5.org
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 ChongBoston University

Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa <***@gmail.com> 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 listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________ gem5-users mailing list gem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users_______________________________________________gem5-users mailing listgem5-***@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-***@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________

gem5-users mailing list

gem5-***@gem5.org

http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users



_______________________________________________
gem5-users mailing list
gem5-***@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________

gem5-users mailing list

gem5-***@gem5.org

http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Continue reading on narkive:
Loading...