Discussion:
Duplicated execution of m5ops
(too old to reply)
kon.bick
2018-08-07 02:33:34 UTC
Permalink
Jason Lowe-Power
2018-08-13 16:32:41 UTC
Permalink
Hi Kon,

The PARSEC patch file modifies the parsec ROI library so when you run an
application like blackscholes, at the beginning of the ROI and at the end
of the ROI the stats will be dumped/reset *in the execution of the
benchmark!*

You are adding in extra dump/reset stats by calling `m5 dumpresetstats`
manually in your rcs file. You should remove these from your rcs file.

You should see the following output in the stats.txt with you current rcs
file:

Kernel boot through source env.sh
-----
Beginning of blackscholes to the beginning of the ROI
-----
The blackscholes ROI
-----
The end of blackscholes ROI until blackscholes exits.
-----
The beginning of canneal until the start of canneal's ROI
----
Canneal's ROI
-----
The cleanup phase of canneal.
----
Some stats for sleep

I hope this answers your question.

Jason
Dear all,
I followed the guide posted over here
https://github.com/arm-university/arm-gem5-rsk/wiki step by step.
*However, I encounter some errors with the m5ops like dumpstats and
resestats.*
In the PARSEC patch file provided by the ARM people (qemu-patch.diff),
+static __attribute__((optimize("O0"))) void m5_dump_stats(uint64_t x,
uint64_t y)
+{
+ register uint64_t x0 asm("x0") = x;
+ register uint64_t x1 asm("x1") = y;
+ asm volatile (".inst 0xff410110;":: "r" (x0), "r" (x1));
+};
However, running several simulations, with varying num-cores (1 or 2,
mainly), the *problem that occurs is that sometimes dumpstats seems to be
executed twice.*
1) At first I thought the problem is related to running PARSEC on
dual core with two threads and the thread management is not perfect in gem5
so dumpstats is called twice.
Ú It turns out that the problem also occurs on single core when running
PARSEC single-threaded
2) My second thought was that the misbehavior had to do with the
assembly implementation and I tried executing m5ops only in the .rcS file
(like using “m5 dumpstats” etc) running a “m5op-free version” of PARSEC
à Unfortunately, sometimes even the commands executed from the rcS file
cause a duplicated execution of dumpstats
Now I am out of ideas what could be the problem and what would be a good
way of debugging it. Could it be related to compiler optimization settings
(in other words, should I try -O0?)
*This is my run command:*
./build/ARM/gem5.opt -d fs_results/20180806_clean/custom_simsmall_1
configs/example/arm/starter_fs.py --cpu=hpi --num-cores=1
--disk-image=/home/kon/aarch-system-20180409/disks/parsec_qcompiled_64_clean.img
--dtb=/home/kon/aarch-system-20180409/binaries/armv8_gem5_v1_1cpu.dtb
--script=/home/kon/arm-gem5-rsk/parsec_rcs/custom.rcS
*This is my custom.rcS:*
#!/bin/bash
PARSEC_DIR="/home/root/parsec-3.0"
cd $PARSEC_DIR
pwd
source ./env.sh
m5 dumpstats
parsecmgmt -a run -p blackscholes -c gcc-hooks -i simmedium -n 1
m5 dumpresetstats
parsecmgmt -a run -p canneal -c gcc-hooks -i simsmall -n 1
m5 dumpstats
sleep 10
m5 exit
First, from booting the system until sourcing env.sh
Second, the execution of blackscholes
Third, the execution of canneal
Fourth, sleep to exit
However, stats.txt indicates that shortly after the first dumpstats
2.02). This duplicated execution is observed at later stages as well.
Did anyone else experience this problem?
On a side note: m5 resestats does not reset all counters? For example I
noticed that sim_insts is not reset while sim_seconds is.
Best regards
Kon
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
kon.bick
2018-08-13 20:50:46 UTC
Permalink
Hi Jason,



Thanks a lot for getting back to me!



Sorry if my explanation in the last mail was somewhat unclear: my tests later were made without applying the qemu-patch.diff to the hooks library in PARSEC. So, the PARSEC benchmark itself did not include any assembly m5 op code functions.



Strangely, though, both ways of dumping stats (either as m5 dumpstats in the rcS file or as assembly code on the hooks library) led to duplicated execution of dumpstats.



I don't know exactly why this happens, but I believe the rcS file (or more precisely: the parsing of it) to be the culprit.



Because if I have PARSEC version with assembly m5 op functions and I start its execution manually in the terminal, it dumps stats once, like expected. However, if I start it by calling parsecmgmt in the rcS file, those dumpstats are executed twice...



Another observation:



If my rcS file includes only two lines of code like this:



pwd

m5 dumpstats



Without calling m5 exit, the rcS file is being executed over and over again. Is this how it is supposed to be? I would have thought those commands in the rcS file are executed once and the system goes into an idle mode (not executing anything but also not stopping because no m5 exit is called). Do you know where m5 readfile is called (where the rcS is parsed in FS mode?)







Best regards

Kon





From: gem5-users [mailto:gem5-users-***@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Tuesday, August 14, 2018 1:33 AM
To: gem5 users mailing list
Subject: Re: [gem5-users] Duplicated execution of m5ops



Hi Kon,



The PARSEC patch file modifies the parsec ROI library so when you run an application like blackscholes, at the beginning of the ROI and at the end of the ROI the stats will be dumped/reset *in the execution of the benchmark!*



You are adding in extra dump/reset stats by calling `m5 dumpresetstats` manually in your rcs file. You should remove these from your rcs file.



You should see the following output in the stats.txt with you current rcs file:



Kernel boot through source env.sh

-----

Beginning of blackscholes to the beginning of the ROI

-----

The blackscholes ROI

-----

The end of blackscholes ROI until blackscholes exits.

-----

The beginning of canneal until the start of canneal's ROI

----

Canneal's ROI

-----

The cleanup phase of canneal.

----

Some stats for sleep



I hope this answers your question.



Jason



On Mon, Aug 6, 2018 at 7:33 PM kon.bick <***@capp.snu.ac.kr> wrote:

Dear all,



I followed the guide posted over here https://github.com/arm-university/arm-gem5-rsk/wiki step by step.

However, I encounter some errors with the m5ops like dumpstats and resestats.

In the PARSEC patch file provided by the ARM people (qemu-patch.diff), they implemented some m5ops in assembly like this:



+static __attribute__((optimize("O0"))) void m5_dump_stats(uint64_t x, uint64_t y)

+{

+ register uint64_t x0 asm("x0") = x;

+ register uint64_t x1 asm("x1") = y;

+ asm volatile (".inst 0xff410110;":: "r" (x0), "r" (x1));

+};



However, running several simulations, with varying num-cores (1 or 2, mainly), the problem that occurs is that sometimes dumpstats seems to be executed twice.



1) At first I thought the problem is related to running PARSEC on dual core with two threads and the thread management is not perfect in gem5 so dumpstats is called twice.

Ú It turns out that the problem also occurs on single core when running PARSEC single-threaded

2) My second thought was that the misbehavior had to do with the assembly implementation and I tried executing m5ops only in the .rcS file (like using “m5 dumpstats” etc) running a “m5op-free version” of PARSEC

à Unfortunately, sometimes even the commands executed from the rcS file cause a duplicated execution of dumpstats



Now I am out of ideas what could be the problem and what would be a good way of debugging it. Could it be related to compiler optimization settings (in other words, should I try -O0?)



Some additional information:



This is my run command:

./build/ARM/gem5.opt -d fs_results/20180806_clean/custom_simsmall_1 configs/example/arm/starter_fs.py --cpu=hpi --num-cores=1 --disk-image=/home/kon/aarch-system-20180409/disks/parsec_qcompiled_64_clean.img --dtb=/home/kon/aarch-system-20180409/binaries/armv8_gem5_v1_1cpu.dtb --script=/home/kon/arm-gem5-rsk/parsec_rcs/custom.rcS



This is my custom.rcS:

#!/bin/bash



PARSEC_DIR="/home/root/parsec-3.0"

cd $PARSEC_DIR

pwd

source ./env.sh

m5 dumpstats

parsecmgmt -a run -p blackscholes -c gcc-hooks -i simmedium -n 1

m5 dumpresetstats

parsecmgmt -a run -p canneal -c gcc-hooks -i simsmall -n 1

m5 dumpstats

sleep 10

m5 exit



I expected the stats.txt to have 4 chapters:

First, from booting the system until sourcing env.sh

Second, the execution of blackscholes

Third, the execution of canneal

Fourth, sleep to exit



However, stats.txt indicates that shortly after the first dumpstats command (at sim_seconds: 1.97) another one is executed (at sim_seconds: 2.02). This duplicated execution is observed at later stages as well.



Did anyone else experience this problem?



On a side note: m5 resestats does not reset all counters? For example I noticed that sim_insts is not reset while sim_seconds is.



Best regards

Kon
Jason Lowe-Power
2018-08-15 17:43:51 UTC
Permalink
Hi Kon,

m5 readfile is called in the init scripts on the disk image you're using
(usually). Or, if you're using the hackback script, it might be called from
there.

You might want to use debug flags to try to determine where these extra
calls are coming from. I would guess there's a psuedoinst flag or something
like that.

BTW, I've never seen this error before, so I'm betting that there's
something weird going on with your setup. Is it possible that when you
"unapplied" the parsec patch you didn't update the binary files?

Jason
Post by kon.bick
Hi Jason,
Thanks a lot for getting back to me!
Sorry if my explanation in the last mail was somewhat unclear: my tests
later were made without applying the qemu-patch.diff to the hooks library
in PARSEC. So, the PARSEC benchmark itself did not include any assembly m5
op code functions.
Strangely, though, both ways of dumping stats (either as m5 dumpstats in
the rcS file or as assembly code on the hooks library) led to duplicated
execution of dumpstats.
I don't know exactly why this happens, but I believe the rcS file (or more
precisely: the parsing of it) to be the culprit.
Because if I have PARSEC version with assembly m5 op functions and I start
its execution manually in the terminal, it dumps stats once, like expected.
However, if I start it by calling parsecmgmt in the rcS file, those
dumpstats are executed twice...
pwd
m5 dumpstats
Without calling m5 exit, the rcS file is being executed over and over
again. Is this how it is supposed to be? I would have thought those
commands in the rcS file are executed once and the system goes into an idle
mode (not executing anything but also not stopping because no m5 exit is
called). Do you know where m5 readfile is called (where the rcS is parsed
in FS mode?)
Best regards
Kon
Lowe-Power
*Sent:* Tuesday, August 14, 2018 1:33 AM
*To:* gem5 users mailing list
*Subject:* Re: [gem5-users] Duplicated execution of m5ops
Hi Kon,
The PARSEC patch file modifies the parsec ROI library so when you run an
application like blackscholes, at the beginning of the ROI and at the end
of the ROI the stats will be dumped/reset *in the execution of the
benchmark!*
You are adding in extra dump/reset stats by calling `m5 dumpresetstats`
manually in your rcs file. You should remove these from your rcs file.
Kernel boot through source env.sh
-----
Beginning of blackscholes to the beginning of the ROI
-----
The blackscholes ROI
-----
The end of blackscholes ROI until blackscholes exits.
-----
The beginning of canneal until the start of canneal's ROI
----
Canneal's ROI
-----
The cleanup phase of canneal.
----
Some stats for sleep
I hope this answers your question.
Jason
Dear all,
I followed the guide posted over here
https://github.com/arm-university/arm-gem5-rsk/wiki step by step.
*However, I encounter some errors with the m5ops like dumpstats and
resestats.*
In the PARSEC patch file provided by the ARM people (qemu-patch.diff),
+static __attribute__((optimize("O0"))) void m5_dump_stats(uint64_t x, uint64_t y)
+{
+ register uint64_t x0 asm("x0") = x;
+ register uint64_t x1 asm("x1") = y;
+ asm volatile (".inst 0xff410110;":: "r" (x0), "r" (x1));
+};
However, running several simulations, with varying num-cores (1 or 2,
mainly), the *problem that occurs is that sometimes dumpstats seems to be
executed twice.*
1) At first I thought the problem is related to running PARSEC on
dual core with two threads and the thread management is not perfect in gem5
so dumpstats is called twice.
Ú It turns out that the problem also occurs on single core when running
PARSEC single-threaded
2) My second thought was that the misbehavior had to do with the
assembly implementation and I tried executing m5ops only in the .rcS file
(like using “m5 dumpstats” etc) running a “m5op-free version” of PARSEC
à Unfortunately, sometimes even the commands executed from the rcS file
cause a duplicated execution of dumpstats
Now I am out of ideas what could be the problem and what would be a good
way of debugging it. Could it be related to compiler optimization settings
(in other words, should I try -O0?)
*This is my run command:*
./build/ARM/gem5.opt -d fs_results/20180806_clean/custom_simsmall_1
configs/example/arm/starter_fs.py --cpu=hpi --num-cores=1
--disk-image=/home/kon/aarch-system-20180409/disks/parsec_qcompiled_64_clean.img
--dtb=/home/kon/aarch-system-20180409/binaries/armv8_gem5_v1_1cpu.dtb
--script=/home/kon/arm-gem5-rsk/parsec_rcs/custom.rcS
*This is my custom.rcS:*
#!/bin/bash
PARSEC_DIR="/home/root/parsec-3.0"
cd $PARSEC_DIR
pwd
source ./env.sh
m5 dumpstats
parsecmgmt -a run -p blackscholes -c gcc-hooks -i simmedium -n 1
m5 dumpresetstats
parsecmgmt -a run -p canneal -c gcc-hooks -i simsmall -n 1
m5 dumpstats
sleep 10
m5 exit
First, from booting the system until sourcing env.sh
Second, the execution of blackscholes
Third, the execution of canneal
Fourth, sleep to exit
However, stats.txt indicates that shortly after the first dumpstats
2.02). This duplicated execution is observed at later stages as well.
Did anyone else experience this problem?
On a side note: m5 resestats does not reset all counters? For example I
noticed that sim_insts is not reset while sim_seconds is.
Best regards
Kon
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
kon.bick
2018-08-16 02:45:08 UTC
Permalink
Hi Jason,



Thanks a lot for your patience for me and this issue.



Meanwhile I have done the following:



1. As you said, I enabled the PseudoInst debug flag. I slightly changed the name of it to enable only debug information for “m5 readfile” and “m5 dumpstats” commands. I ran the system (I am not using the hackback script, afaik) and attached a rcS that included “m5 dumpstats” as the first line, so that it will be executed once the system fully booted.

2. The result was as expected. The script seems to be read twice. Let me copy some of the terminal debug information here:



1275350767698: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)

1275354938886: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x172)

1299729119598: global: PseudoInst::dumpstats(0, 0)

1299729119598: global: cpu is 0

1311840638052: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)

1311844180206: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x172)

1328159372946: global: PseudoInst::dumpstats(0, 0)

1328159372946: global: cpu is 0





(CPU: ATOMIC)

(Please ignore the “cpu is 0” information here, I extended the debug information to also output what cpu id caused the dumpstats command as I previously thought duplicated execution are due to multiple cores.)



3. Another thing I tried is to just to include the commands “pwd” and “m5 dumpstats” in the rcS file, without calling “m5 exit”. This resulted also in the expected execution, calling pwd and dumping stats in an infinite loop
 I am not sure if that is the expected behavior?

4. Unfortunately, I couldn’t identify where m5 readfile was called (I now know, thanks!). Thus I had a closer look at the pseudo_inst.cc file.

5. At first I tried the following: set a flag to true when the readfile function was called for the first time. When it’s called again I would just return “0”. This didn’t work as the system probably thought “there is no script file” and opened the terminal for manual execution, throwing my out of the script.

6. In a next step I tried it in a different way: as I knew the script would be read twice, I return “1” for the first read and the second time I let the function execute properly. And this solved the problem! I unfortunately didn’t save the log of my previous test (executing dumpstats as soon as the system booted) but anyway, now the debug information looks like that (also note that the script is slightly longer in this run):



1923284588316: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)

1923314386392: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x1)

1923318721800: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x280)

1968461076204: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)

1968483300882: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x280)

3331861562064: global: PseudoInst::dumpstats(0, 0)

3331861562064: global: cpu is 0



(CPU: HPI)

(Here, dumpstats is executed before the ROI, thus the gap in the ticks).



7. With my more than dirty workaround it works now as expected and dumpstats are not called twice but once per occurrence. I unfortunately lack a good coding style to implement a better patch but I will look at where m5 readfile is called on the disk image (I am using the “aarch-system-20180409” “linaro-minimal-aarch64.img”, I just extended the disk for PARSEC installation, just like in the ARM Research Starter Kit.)



I can understand your skepticism about my binary file, but rest assured, this is not the problem. I am working on this issue for several month now and I fully understand how the assembly code is calling the m5 ops. I actually have three disk images, each with a PARSEC installation: one without any assembly m5 ops, another with checkpoint, resestats and dumpstats, and one calling dumpstats before and after the ROI (I thought this is the best since resetstats didn’t reset the instruction count, but this is another issue
). To further prove my point: this duplicated m5 ops were occurring when I just called “m5 dumpstats” in the rcS file (like the experiment above) without even running PARSEC.



Even though you didn’t encounter this problem, other people have: http://gem5-users.gem5.narkive.com/bQ8pOq6I/arm64-pseudo-instructions This was an unanswered mail(?) 3 years ago. The setup is the same: same disk image and executing a script




Could I forward this problem to the dev mailing list, or do you want me to run more tests?



As always, thanks for your assistance



Best regards

Kon







From: gem5-users [mailto:gem5-users-***@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Thursday, August 16, 2018 2:44 AM
To: gem5 users mailing list <gem5-***@gem5.org>
Subject: Re: [gem5-users] Duplicated execution of m5ops



Hi Kon,



m5 readfile is called in the init scripts on the disk image you're using (usually). Or, if you're using the hackback script, it might be called from there.



You might want to use debug flags to try to determine where these extra calls are coming from. I would guess there's a psuedoinst flag or something like that.



BTW, I've never seen this error before, so I'm betting that there's something weird going on with your setup. Is it possible that when you "unapplied" the parsec patch you didn't update the binary files?



Jason



On Mon, Aug 13, 2018 at 1:50 PM kon.bick <***@capp.snu.ac.kr <mailto:***@capp.snu.ac.kr> > wrote:

Hi Jason,



Thanks a lot for getting back to me!



Sorry if my explanation in the last mail was somewhat unclear: my tests later were made without applying the qemu-patch.diff to the hooks library in PARSEC. So, the PARSEC benchmark itself did not include any assembly m5 op code functions.



Strangely, though, both ways of dumping stats (either as m5 dumpstats in the rcS file or as assembly code on the hooks library) led to duplicated execution of dumpstats.



I don't know exactly why this happens, but I believe the rcS file (or more precisely: the parsing of it) to be the culprit.



Because if I have PARSEC version with assembly m5 op functions and I start its execution manually in the terminal, it dumps stats once, like expected. However, if I start it by calling parsecmgmt in the rcS file, those dumpstats are executed twice...



Another observation:



If my rcS file includes only two lines of code like this:



pwd

m5 dumpstats



Without calling m5 exit, the rcS file is being executed over and over again. Is this how it is supposed to be? I would have thought those commands in the rcS file are executed once and the system goes into an idle mode (not executing anything but also not stopping because no m5 exit is called). Do you know where m5 readfile is called (where the rcS is parsed in FS mode?)







Best regards

Kon





From: gem5-users [mailto: <mailto:gem5-users-***@gem5.org> gem5-users-***@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Tuesday, August 14, 2018 1:33 AM
To: gem5 users mailing list
Subject: Re: [gem5-users] Duplicated execution of m5ops



Hi Kon,



The PARSEC patch file modifies the parsec ROI library so when you run an application like blackscholes, at the beginning of the ROI and at the end of the ROI the stats will be dumped/reset *in the execution of the benchmark!*



You are adding in extra dump/reset stats by calling `m5 dumpresetstats` manually in your rcs file. You should remove these from your rcs file.



You should see the following output in the stats.txt with you current rcs file:



Kernel boot through source env.sh

-----

Beginning of blackscholes to the beginning of the ROI

-----

The blackscholes ROI

-----

The end of blackscholes ROI until blackscholes exits.

-----

The beginning of canneal until the start of canneal's ROI

----

Canneal's ROI

-----

The cleanup phase of canneal.

----

Some stats for sleep



I hope this answers your question.



Jason



On Mon, Aug 6, 2018 at 7:33 PM kon.bick <***@capp.snu.ac.kr <mailto:***@capp.snu.ac.kr> > wrote:

Dear all,



I followed the guide posted over here https://github.com/arm-university/arm-gem5-rsk/wiki step by step.

However, I encounter some errors with the m5ops like dumpstats and resestats.

In the PARSEC patch file provided by the ARM people (qemu-patch.diff), they implemented some m5ops in assembly like this:



+static __attribute__((optimize("O0"))) void m5_dump_stats(uint64_t x, uint64_t y)

+{

+ register uint64_t x0 asm("x0") = x;

+ register uint64_t x1 asm("x1") = y;

+ asm volatile (".inst 0xff410110;":: "r" (x0), "r" (x1));

+};



However, running several simulations, with varying num-cores (1 or 2, mainly), the problem that occurs is that sometimes dumpstats seems to be executed twice.



1) At first I thought the problem is related to running PARSEC on dual core with two threads and the thread management is not perfect in gem5 so dumpstats is called twice.

Ú It turns out that the problem also occurs on single core when running PARSEC single-threaded

2) My second thought was that the misbehavior had to do with the assembly implementation and I tried executing m5ops only in the .rcS file (like using “m5 dumpstats” etc) running a “m5op-free version” of PARSEC

à Unfortunately, sometimes even the commands executed from the rcS file cause a duplicated execution of dumpstats



Now I am out of ideas what could be the problem and what would be a good way of debugging it. Could it be related to compiler optimization settings (in other words, should I try -O0?)



Some additional information:



This is my run command:

./build/ARM/gem5.opt -d fs_results/20180806_clean/custom_simsmall_1 configs/example/arm/starter_fs.py --cpu=hpi --num-cores=1 --disk-image=/home/kon/aarch-system-20180409/disks/parsec_qcompiled_64_clean.img --dtb=/home/kon/aarch-system-20180409/binaries/armv8_gem5_v1_1cpu.dtb --script=/home/kon/arm-gem5-rsk/parsec_rcs/custom.rcS



This is my custom.rcS:

#!/bin/bash



PARSEC_DIR="/home/root/parsec-3.0"

cd $PARSEC_DIR

pwd

source ./env.sh

m5 dumpstats

parsecmgmt -a run -p blackscholes -c gcc-hooks -i simmedium -n 1

m5 dumpresetstats

parsecmgmt -a run -p canneal -c gcc-hooks -i simsmall -n 1

m5 dumpstats

sleep 10

m5 exit



I expected the stats.txt to have 4 chapters:

First, from booting the system until sourcing env.sh

Second, the execution of blackscholes

Third, the execution of canneal

Fourth, sleep to exit



However, stats.txt indicates that shortly after the first dumpstats command (at sim_seconds: 1.97) another one is executed (at sim_seconds: 2.02). This duplicated execution is observed at later stages as well.



Did anyone else experience this problem?



On a side note: m5 resestats does not reset all counters? For example I noticed that sim_insts is not reset while sim_seconds is.



Best regards

Kon
Jason Lowe-Power
2018-08-17 16:44:55 UTC
Permalink
Hi Kon,

I have a new hypothesis: There's a problem with the init logic on your disk
image. I'm not sure exactly how that disk image is set up, but usually
during boot there's a special init script (e.g., in /etc/init.d/) that runs
and tries to load the runscript. There could be a problem with that script,
or the script could be duplicated. You could try with the most recent disk
image (see http://www.gem5.org/dist/current/arm/) if you're using the one
from June '17.

To confirm this, you can mount the disk image on your host machine and
search for "m5 readfile" on the disk to see where it's called.

I believe this is a problem with the arm gem5 starter kit, not a problem
with gem5. But, I could be wrong :). You might have more luck contacting
the people at arm that put together the starter kit.

Cheers,
Jason
Post by kon.bick
Hi Jason,
Thanks a lot for your patience for me and this issue.
1. As you said, I enabled the PseudoInst debug flag. I slightly
changed the name of it to enable only debug information for “m5 readfile”
and “m5 dumpstats” commands. I ran the system (I am not using the hackback
script, afaik) and attached a rcS that included “m5 dumpstats” as the first
line, so that it will be executed once the system fully booted.
2. The result was as expected. The script seems to be read twice.
1275350767698: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)
1275354938886: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x172)
1299729119598: global: PseudoInst::dumpstats(0, 0)
1299729119598: global: cpu is 0
1311840638052: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)
1311844180206: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x172)
1328159372946: global: PseudoInst::dumpstats(0, 0)
1328159372946: global: cpu is 0
(CPU: ATOMIC)
(Please ignore the “cpu is 0” information here, I extended the debug
information to also output what cpu id caused the dumpstats command as I
previously thought duplicated execution are due to multiple cores.)
3. Another thing I tried is to just to include the commands “pwd”
and “m5 dumpstats” in the rcS file, without calling “m5 exit”. This
resulted also in the expected execution, calling pwd and dumping stats in
an infinite loop
 I am not sure if that is the expected behavior?
4. Unfortunately, I couldn’t identify where m5 readfile was called
(I now know, thanks!). Thus I had a closer look at the pseudo_inst.cc file.
5. At first I tried the following: set a flag to true when the
readfile function was called for the first time. When it’s called again I
would just return “0”. This didn’t work as the system probably thought
“there is no script file” and opened the terminal for manual execution,
throwing my out of the script.
6. In a next step I tried it in a different way: as I knew the
script would be read twice, I return “1” for the first read and the second
time I let the function execute properly. And this solved the problem! I
unfortunately didn’t save the log of my previous test (executing dumpstats
as soon as the system booted) but anyway, now the debug information looks
1923284588316: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)
1923314386392: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x1)
1923318721800: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x280)
1968461076204: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x0)
1968483300882: global: PseudoInst::readfile(0x7ffffbfb88, 0x40000, 0x280)
3331861562064: global: PseudoInst::dumpstats(0, 0)
3331861562064: global: cpu is 0
(CPU: HPI)
(Here, dumpstats is executed before the ROI, thus the gap in the ticks).
7. With my more than dirty workaround it works now as expected and
dumpstats are not called twice but once per occurrence. I unfortunately
lack a good coding style to implement a better patch but I will look at
where m5 readfile is called on the disk image (I am using the
“aarch-system-20180409” “linaro-minimal-aarch64.img”, I just extended the
disk for PARSEC installation, just like in the ARM Research Starter Kit.)
I can understand your skepticism about my binary file, but rest assured,
this is not the problem. I am working on this issue for several month now
and I fully understand how the assembly code is calling the m5 ops. I
actually have three disk images, each with a PARSEC installation: one
without any assembly m5 ops, another with checkpoint, resestats and
dumpstats, and one calling dumpstats before and after the ROI (I thought
this is the best since resetstats didn’t reset the instruction count, but
this is another issue
). To further prove my point: this duplicated m5 ops
were occurring when I just called “m5 dumpstats” in the rcS file (like the
experiment above) without even running PARSEC.
http://gem5-users.gem5.narkive.com/bQ8pOq6I/arm64-pseudo-instructions
This was an unanswered mail(?) 3 years ago. The setup is the same: same
disk image and executing a script

Could I forward this problem to the dev mailing list, or do you want me to run more tests?
As always, thanks for your assistance
Best regards
Kon
Lowe-Power
*Sent:* Thursday, August 16, 2018 2:44 AM
*Subject:* Re: [gem5-users] Duplicated execution of m5ops
Hi Kon,
m5 readfile is called in the init scripts on the disk image you're using
(usually). Or, if you're using the hackback script, it might be called from
there.
You might want to use debug flags to try to determine where these extra
calls are coming from. I would guess there's a psuedoinst flag or something
like that.
BTW, I've never seen this error before, so I'm betting that there's
something weird going on with your setup. Is it possible that when you
"unapplied" the parsec patch you didn't update the binary files?
Jason
Hi Jason,
Thanks a lot for getting back to me!
Sorry if my explanation in the last mail was somewhat unclear: my tests
later were made without applying the qemu-patch.diff to the hooks library
in PARSEC. So, the PARSEC benchmark itself did not include any assembly m5
op code functions.
Strangely, though, both ways of dumping stats (either as m5 dumpstats in
the rcS file or as assembly code on the hooks library) led to duplicated
execution of dumpstats.
I don't know exactly why this happens, but I believe the rcS file (or more
precisely: the parsing of it) to be the culprit.
Because if I have PARSEC version with assembly m5 op functions and I start
its execution manually in the terminal, it dumps stats once, like expected.
However, if I start it by calling parsecmgmt in the rcS file, those
dumpstats are executed twice...
pwd
m5 dumpstats
Without calling m5 exit, the rcS file is being executed over and over
again. Is this how it is supposed to be? I would have thought those
commands in the rcS file are executed once and the system goes into an idle
mode (not executing anything but also not stopping because no m5 exit is
called). Do you know where m5 readfile is called (where the rcS is parsed
in FS mode?)
Best regards
Kon
Lowe-Power
*Sent:* Tuesday, August 14, 2018 1:33 AM
*To:* gem5 users mailing list
*Subject:* Re: [gem5-users] Duplicated execution of m5ops
Hi Kon,
The PARSEC patch file modifies the parsec ROI library so when you run an
application like blackscholes, at the beginning of the ROI and at the end
of the ROI the stats will be dumped/reset *in the execution of the
benchmark!*
You are adding in extra dump/reset stats by calling `m5 dumpresetstats`
manually in your rcs file. You should remove these from your rcs file.
Kernel boot through source env.sh
-----
Beginning of blackscholes to the beginning of the ROI
-----
The blackscholes ROI
-----
The end of blackscholes ROI until blackscholes exits.
-----
The beginning of canneal until the start of canneal's ROI
----
Canneal's ROI
-----
The cleanup phase of canneal.
----
Some stats for sleep
I hope this answers your question.
Jason
Dear all,
I followed the guide posted over here
https://github.com/arm-university/arm-gem5-rsk/wiki step by step.
*However, I encounter some errors with the m5ops like dumpstats and
resestats.*
In the PARSEC patch file provided by the ARM people (qemu-patch.diff),
+static __attribute__((optimize("O0"))) void m5_dump_stats(uint64_t x, uint64_t y)
+{
+ register uint64_t x0 asm("x0") = x;
+ register uint64_t x1 asm("x1") = y;
+ asm volatile (".inst 0xff410110;":: "r" (x0), "r" (x1));
+};
However, running several simulations, with varying num-cores (1 or 2,
mainly), the *problem that occurs is that sometimes dumpstats seems to be
executed twice.*
1) At first I thought the problem is related to running PARSEC on
dual core with two threads and the thread management is not perfect in gem5
so dumpstats is called twice.
Ú It turns out that the problem also occurs on single core when running
PARSEC single-threaded
2) My second thought was that the misbehavior had to do with the
assembly implementation and I tried executing m5ops only in the .rcS file
(like using “m5 dumpstats” etc) running a “m5op-free version” of PARSEC
à Unfortunately, sometimes even the commands executed from the rcS file
cause a duplicated execution of dumpstats
Now I am out of ideas what could be the problem and what would be a good
way of debugging it. Could it be related to compiler optimization settings
(in other words, should I try -O0?)
*This is my run command:*
./build/ARM/gem5.opt -d fs_results/20180806_clean/custom_simsmall_1
configs/example/arm/starter_fs.py --cpu=hpi --num-cores=1
--disk-image=/home/kon/aarch-system-20180409/disks/parsec_qcompiled_64_clean.img
--dtb=/home/kon/aarch-system-20180409/binaries/armv8_gem5_v1_1cpu.dtb
--script=/home/kon/arm-gem5-rsk/parsec_rcs/custom.rcS
*This is my custom.rcS:*
#!/bin/bash
PARSEC_DIR="/home/root/parsec-3.0"
cd $PARSEC_DIR
pwd
source ./env.sh
m5 dumpstats
parsecmgmt -a run -p blackscholes -c gcc-hooks -i simmedium -n 1
m5 dumpresetstats
parsecmgmt -a run -p canneal -c gcc-hooks -i simsmall -n 1
m5 dumpstats
sleep 10
m5 exit
First, from booting the system until sourcing env.sh
Second, the execution of blackscholes
Third, the execution of canneal
Fourth, sleep to exit
However, stats.txt indicates that shortly after the first dumpstats
2.02). This duplicated execution is observed at later stages as well.
Did anyone else experience this problem?
On a side note: m5 resestats does not reset all counters? For example I
noticed that sim_insts is not reset while sim_seconds is.
Best regards
Kon
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Loading...