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 <kon.b...@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:gem5-users-boun...@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 <kon.b...@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 > > > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
