Re: [gem5-users] Sources of In-determinism in Full System Simulators

[Steve Reinhardt]

Even with x86 you should be seeing deterministic results.  If you are
regularly seeing inconsistencies, you can try running two copies with debug
tracing (I suggest Exec,ExecMacro,Cache as a starting set of flags) and
comparing their output with util/tracdiff to see where they diverge.

Steve

On Thu, Aug 13, 2015 at 9:44 AM Andreas Hansson 
wrote:

> Hi Prathap,
>
> That sounds very odd and should not happen unless the workload itself is
> somehow random. What is it you are running? Are you sure you’re running
> exactly the same thing?
>
> If it does indeed vary then it would be good if you can track down why by
> running two simulations in lock-step and determining where they diverge.
>
> We regularly run the ARM regressions with UBSan to ensure there is no
> undefined behaviour in the simulator. I know that for X86 there are quite a
> few warnings from UBSan, so that could be a reason if you’re using x86.
>
> Andreas
>
> From: gem5-users  on behalf of Prathap
> Kolakkampadath 
> Reply-To: gem5 users mailing list 
> Date: Thursday, 13 August 2015 09:11
> To: gem5 users mailing list 
> Subject: [gem5-users] Sources of In-determinism in Full System Simulators
>
> Hello User,
>
> I am running a benchmark in gem5 full system mode. Checkpoint is created
> in atomic mode and then switches to detailed mode before starting the
> benchmark. On repeated  runs of the benchmark from same checkpoint, the
> number of memory requests arriving at DRAM banks differs; up-to 5%
> variation.  Can someone point out, what could be the sources of
> in-determinism?
>
>
> Thanks,
> Prathap
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
> ___
> 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

Re: [gem5-users] Sources of In-determinism in Full System Simulators

[Andreas Hansson]

Hi Prathap,

That sounds very odd and should not happen unless the workload itself is 
somehow random. What is it you are running? Are you sure you’re running exactly 
the same thing?

If it does indeed vary then it would be good if you can track down why by 
running two simulations in lock-step and determining where they diverge.

We regularly run the ARM regressions with UBSan to ensure there is no undefined 
behaviour in the simulator. I know that for X86 there are quite a few warnings 
from UBSan, so that could be a reason if you’re using x86.

Andreas

From: gem5-users 
mailto:gem5-users-boun...@gem5.org>> on behalf of 
Prathap Kolakkampadath mailto:kvprat...@gmail.com>>
Reply-To: gem5 users mailing list 
mailto:gem5-users@gem5.org>>
Date: Thursday, 13 August 2015 09:11
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Subject: [gem5-users] Sources of In-determinism in Full System Simulators

Hello User,

I am running a benchmark in gem5 full system mode. Checkpoint is created in 
atomic mode and then switches to detailed mode before starting the benchmark. 
On repeated  runs of the benchmark from same checkpoint, the number of memory 
requests arriving at DRAM banks differs; up-to 5% variation.  Can someone point 
out, what could be the sources of in-determinism?


Thanks,
Prathap

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] Sources of In-determinism in Full System Simulators

[Prathap Kolakkampadath]

Hello User,

I am running a benchmark in gem5 full system mode. Checkpoint is created in
atomic mode and then switches to detailed mode before starting the
benchmark. On repeated  runs of the benchmark from same checkpoint, the
number of memory requests arriving at DRAM banks differs; up-to 5%
variation.  Can someone point out, what could be the sources of
in-determinism?


Thanks,
Prathap
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] CPU and L1-d Cache Trace

[Andreas Hansson]

Hi Hamed,

If you change the py files in src you need to recompile gem5 before running. 
You do not need the debug flag to get the trace.

Hope that helps.

Andreas

From: gem5-users 
mailto:gem5-users-boun...@gem5.org>> on behalf of 
Hamed Ghadimi mailto:hamed_ghad...@yahoo.com>>
Reply-To: Hamed Ghadimi 
mailto:hamed_ghad...@yahoo.com>>, gem5 users mailing 
list mailto:gem5-users@gem5.org>>
Date: Thursday, 13 August 2015 07:04
To: "gem5-users@gem5.org" 
mailto:gem5-users@gem5.org>>
Subject: [gem5-users] CPU and L1-d Cache Trace


Hi,
I want to add the CommMonitor between CPU and L1d-cache in SE mode to trace all 
the memory operation requests in the system.

I added following lines in the /src/cpu/BaseCPU.py file:

cpu.monitor = CommMonitor(trace_file='cpu.ptrc',trace_enable=True)
cpu.dcache_port = cpu.monitor.slave
cpu.monitor.master = cache.cpu_side


Then I run: ./build/ALPHA/gem5.opt --debug-flags=CommMonitor 
configs/example/se.py -c tests/test-progs/hello/bin/alpha/linux/hello

The code executes but the trace file does not get generated. The CommMonitor 
also does not get recorded in config.ini.

How to generate this trace?

Best Regards,
Hamed

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] CPU and L1-d Cache Trace

[Hamed Ghadimi]

Hi,
I want to add the CommMonitor between CPU and L1d-cache in SE mode to trace all 
the memory operation requests in the system.

I added following lines in the /src/cpu/BaseCPU.py file:

cpu.monitor = CommMonitor(trace_file='cpu.ptrc',trace_enable=True)
cpu.dcache_port = cpu.monitor.slave
cpu.monitor.master = cache.cpu_side

Then I run: ./build/ALPHA/gem5.opt --debug-flags=CommMonitor 
configs/example/se.py -c tests/test-progs/hello/bin/alpha/linux/helloThe code 
executes but the trace file does not get generated. The CommMonitor also does 
not get recorded in config.ini.

How to generate this trace?Best Regards,
Hamed___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] Problem when runing FS + RUBY + Detailed in Alpha

[sukarn]

Hi All,

I am trying to run gem5 in FS mode in ALPHA configuration with disk image
downloaded from m5 parsec website and compile the kernel by own by
following instruction on m5 website with git.

The command line I use is as follows:
build/ALPHA/gem5.opt configs/example/fs.py --ruby --cpu-type=detailed
--script=/home/sukarn/rs/bodytrack_2c_simsmall.rcS

But when i run it shows error which are as follows:

...

0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
 REAL SIMULATION 
info: Entering event queue @ 0.  Starting simulation...
warn: Prefetch instructions in Alpha do not do anything
3834744000: system.terminal: attach terminal 0
warn: Prefetch instructions in Alpha do not do anything
fatal: Unable to find destination for addr 0x41f00606c on system.iobus
 @ tick 30728494500
[findPort:build/ALPHA/mem/xbar.cc, line 358]
Memory Usage: 877280 KBytes
Program aborted at cycle 30728494500
Aborted (core dumped)

...

how can i fix this ??

I really appreciate if anyone can help me on this issue.

Thanks in advance


Regards

Sukarn Agarwal





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