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

[Steve Reinhardt]

One possible source is if your benchmark interacts with the host through a
system call that returns a non-deterministic result.  You could try running
with the SyscallVerbose debug flag to see what syscalls it is making.

Steve


On Sat, Aug 15, 2015 at 6:53 PM Prathap Kolakkampadath 
wrote:

>
> I am observing this behaviour with a synthetic benchmark(Nonlinear
> Predictive Control). I am not sure if this benchmark is adding any kind of
> randomness.
> I need to look in to this.
>
> I tested with eembc benchmarks, where i don't see any variations with the
> repeated runs.
> So as andreas mentioned this must be introduced by this specific benchmark.
>
> Thanks Andreas and Steve.
>
> On Thu, Aug 13, 2015 at 1:22 PM, Steve Reinhardt  wrote:
>
>> 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
>>
>
> ___
> 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] Cache Flush in SE mode

[Ahmed Abulila]

Dear All,

I am running Spec06 on ARM SE mode with classic memory model. I am trying
to flush all the contents of the caches and TLB at some point during my
simulation.

I am doing that as following(Note: tc is the current ThreadContext):
1- I am getting pointers to the icache and dcacha ports
 tc->getCpuPtr()->getDataPort()
 tc->getCpuPtr()->getInstPort()
2- Then, I use the following methods inside src/mem/cache/cache_impl.hh to
flush the caches
 memWriteback();
 memInvalidate();
3- To flush TLBs:
  tc->getITBPtr()->flushAll();
  tc->getDTBPtr()->flushAll();

However, I notice there is no effect on the timing (I get the same number
of Ticks with and without flushing caches and TLBs). I know that those
methods are functional methods, but at least flushing caches will generate
more cache misses. Also, I think TLB is not really working on SE mode
because I print all the contents of TLB before flushing and there is
nothing there.

Could anyone help me with this issue?

Thank you

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