Re: [gem5-users] m5ops with RISCV

[Alec Roelke]

Hi Vanchinathan,

At the moment, there is not a patch for m5op support for RISC-V.  If you
want binaries to have access to performance counts, the best way to do that
would probably be to add CSRs for them and have those CSRs return the
values of the corresponding stats when read, like INSTRET, CYCLE, and TIME
do.

-Alec Roelke

On Tue, Dec 19, 2017 at 1:25 AM, Vanchinathan Venkataramani <
dcsv...@gmail.com> wrote:

> Dear all
>
> I would like to collect performance counters for a RISCV binary in gem5.
>
> Is there a util/m5 patch for generating m5ops for RISCV? Any help really
> appreciated.
>
> Best regards
> V Vanchinathan
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] m5ops with RISCV

[Vanchinathan Venkataramani]

Dear Alec

Thanks a lot for your prompt reply. I looked at the CSR counters and it
looks to me that I cannot find number of integer, load, store instructions
executed separately.

Ideally, if I can reset and dump stats using m5_dumpstats and
m5_resetstats, I can get detailed information on instruction executed per
type in one go. But now this is not available. Is there *any tutorial* that
can be used for *implementing* this?

Thanks a lot once again.

V Vanchinathan

On Wed, Dec 20, 2017 at 2:44 AM, Alec Roelke  wrote:

> Hi Vanchinathan,
>
> At the moment, there is not a patch for m5op support for RISC-V.  If you
> want binaries to have access to performance counts, the best way to do that
> would probably be to add CSRs for them and have those CSRs return the
> values of the corresponding stats when read, like INSTRET, CYCLE, and TIME
> do.
>
> -Alec Roelke
>
> On Tue, Dec 19, 2017 at 1:25 AM, Vanchinathan Venkataramani <
> dcsv...@gmail.com> wrote:
>
>> Dear all
>>
>> I would like to collect performance counters for a RISCV binary in gem5.
>>
>> Is there a util/m5 patch for generating m5ops for RISCV? Any help really
>> appreciated.
>>
>> Best regards
>> V Vanchinathan
>>
>
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] [EXT] Re: Running Dist-gem5

[Vitorio Cargnini (lcargnini)]

Thanks Mohammad,
I really appreciate all the help; I’ll work on dist-gem5 now, test some more, 
new kernel, new images, new DTBs in dist mode, new scripts and make some 
measures.

If I hit another wall, I’ll ping again, also, if I can help in anything let me 
know. In addition to that, if you finished your grad or near end, or just 
looking, ping me off-line.

Best Regards,
Luis Vitorio Cargnini.

From: gem5-users [mailto:gem5-users-boun...@gem5.org] On Behalf Of Mohammad 
Alian
Sent: Saturday, December 16, 2017 10:16 AM
To: gem5 users mailing list 
Subject: Re: [gem5-users] [EXT] Re: Running Dist-gem5



On Fri, Dec 15, 2017 at 2:20 PM, Vitorio Cargnini (lcargnini) 
> wrote:

Thanks Mohammad,



Everything it is working now.



However, a question, how do I can capture the ‘virtual terminal.’ because I the 
script I passed was supposed to run /bin/hostname and /bin/date, then call m5 
exit. So where can I observe the terminal output?

You can check terminal output from: m5out.*/system.terminal




Also, can I use checkpoints from my rcS script?

I already added. However, I’m not sure if that would work.



Sure- check $CKPT_DIR/m5out.* to see if you have successfully dumped a 
checkpoint. You can also check log.* and look for a checkpoint dump printout 
(e.g. "Writing checkpoint" and "info: m5 checkpoint called with non-zero delay 
=> triggering immediate checkpoint (at the next sync)")

Please note that in dist-gem5 you can take checkpoint in two flavors. You 
should choose one based on your need.
1- collaborative:

  When all nodes in the simulated cluster called "/sbin/m5 checkpoint" then 
dist-gem5 starts dumping a checkpoint

2- immediate

  Only one node call "/sbin/m5 checkpoint " and dist-gem5 
starts dumping a checkpoint at the beginning of next sync quantum.


Last thing, once it is up and running can I conenct using mterm?


It should be possible (although not useful, you should try to work with rcS 
scripts as its the most efficient way for communicating with gem5). But I guess 
when you redirect the output of gem5 to a file (which is the case for 
dist-gem5) then gem5 automatically disables all listeners, including sockets 
for connecting m5term. If that's the case (most likely), you should first find 
a way to re enable listeners before you try to connect m5term.


Regards,

Vitorio.







From: gem5-users 
[mailto:gem5-users-boun...@gem5.org] On 
Behalf Of Mohammad Alian
Sent: Monday, December 11, 2017 6:03 PM

To: gem5 users mailing list >
Subject: Re: [gem5-users] [EXT] Re: Running Dist-gem5



add a "t" at the end of tick number:



--dist-sync-start=1t



On Mon, Dec 11, 2017 at 12:40 PM, Vitorio Cargnini (lcargnini) 
> wrote:

Thanks Mohammad,



I tried and got the following in the log(log.switch) (below), I also did try 
using different orders in the parameters, what should I look for now?



Log:

gem5 Simulator System.  http://gem5.org

gem5 is copyrighted software; use the --copyright option for details.



gem5 compiled Dec  6 2017 14:35:43

gem5 started Dec 11 2017 11:16:10

gem5 executing on rndarch11, pid 9841

command line: /wada/gem5/build/ARM/gem5.opt -d /wada/gem5/m5out.switch 
--debug-flags=DistEthernet /wada/gem5/configs/dist/sw.py 
--dist-sync-start=1 --checkpoint-dir=/wada/gem5/m5out.switch 
--is-switch --dist-size=8 --dist-server-port=2200



info: Standard input is not a terminal, disabling listeners.

Global frequency set at 1 ticks per second

Traceback (most recent call last):

  File "", line 1, in 

  File /wada/gem5/src/python/m5/main.py", line 433, in main

exec filecode in scope

  File /wada/gem5/configs/dist/sw.py", line 79, in 

main()

  File /wada/gem5/configs/dist/sw.py", line 76, in main

Simulation.run(options, root, None, None)

  File /wada/gem5/configs/common/Simulation.py", line 589, in run

m5.instantiate(checkpoint_dir)

  File /wada/gem5/src/python/m5/simulate.py", line 115, in instantiate

for obj in root.descendants(): obj.createCCObject()

  File /wada/gem5/src/python/m5/SimObject.py", line 1484, in createCCObject

self.getCCParams()

  File /wada/gem5/src/python/m5/SimObject.py", line 1439, in getCCParams

setattr(cc_params, param, value)

TypeError: (): incompatible function arguments. The following argument types 
are supported:

1. (self: _m5.param_DistEtherLink.DistEtherLinkParams, arg0: int) -> None



Invoked with: <_m5.param_DistEtherLink.DistEtherLinkParams object at 
0x7f9a37b8fd80>, 83222784L



From: gem5-users 
[mailto:gem5-users-boun...@gem5.org] On 
Behalf Of Mohammad Alian
Sent: Sunday, December 10, 2017 7:54 PM

To: gem5 users mailing list >
Subject: Re: 

Re: [gem5-users] About multiple cache copies and a related comment called "on the same path to memory"

[Timon Evenblij]

Hi gjins,

To the best of my knowledge, your reasoning is correct. If a packet goes
from cpu to the memory, it passes the local caches and then the shared
caches on its way to memory. Local caches from other cpu's are not passed,
thus meaning they are not on the path to memory.
It could be interesting to look a little further into the MOESI cache
coherence protocol, since that is the coherence protocol used by default by
the classic cache system in gem5.

Regards,

Timon

On Tue, Dec 19, 2017 at 1:23 AM, Gongjin Sun  wrote:

> Hi All,
>
> I noticed that there are some useful comments in the file cache.cc as like
> these:
>
> "// if a cache is responding, and it had the line in Owned
> // rather than Modified state, we need to invalidate any
> // copies that are not on the same path to memory
> "
> "// we get away with multiple caches (on
> // the same path to memory) considering
> // the block writeable as we always enter
> // the cache hierarchy through a cache,
> // and first snoop upwards in all other
> // branches"
>
> What is the meaning of "on the same path to memory"?
>
> Assume we have two cpus and 3 cache levels. The third level is shared by
> these two cpus. And packet is in the level 2 (L2) of cpu1 currently. If I
> understand it correctly, taking the first comment for example,
>
> the cache which is responding is L1 of cpu1, the "on the same path to
> memory" means the path from current L2 of cpu1 to to L3 to memory and the
> copies which need to be invalidated should be the ones from L1, L2 of cpu2
> (not including the copies of L3) . Is my understanding correct? Please
> correct me and clarify it if not.
>
> Thanks in advance!
>
> gjins
>
>
> ___
> 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] About multiple cache copies and a related comment called "on the same path to memory"

[Nikos Nikoleris]

Hi Gjins,

In your example, for any of the two cores, the path to the memory
includes its private caches and the shared cache and it does not include
the private caches of other core.

gem5's classic memory model implements a MOESI-like snooping protocol
and the cache that has the block with the dirty bit set (block in either
M state or O state) is the cache that responds. In this case, the
comment clarifies that if the block is additionally marked as shared (a
block marked as shared and dirty is in O state) and we need a writable
copy, this cache is responding but there are copies of the block in
other caches (not in the core's path to the memory) that we need to
invalidate.

In an example system with 4 cores, each having a private L1 and a shared
L2, this means that if core0 needs a writable copy of block A and
core1's L1 had the block in O state, core1's L1 will respond to the
request, but we need to snoop and invalidate copies that might exist in
core2's L1 or core3's L1. The L2 might also have a copy of the block but
we don't need to invalidate it.

Hope this helps.

Nikos

On 12/19/17 00:23, Gongjin Sun wrote:

Hi All,

I noticed that there are some useful comments in the file cache.cc as
like these:

"// if a cache is responding, and it had the line in Owned
// rather than Modified state, we need to invalidate any
// copies that are not on the same path to memory
"
"// we get away with multiple caches (on
// the same path to memory) considering
// the block writeable as we always enter
// the cache hierarchy through a cache,
// and first snoop upwards in all other
// branches"

What is the meaning of "on the same path to memory"?

Assume we have two cpus and 3 cache levels. The third level is shared by
these two cpus. And packet is in the level 2 (L2) of cpu1 currently. If
I understand it correctly, taking the first comment for example,

the cache which is responding is L1 of cpu1, the "on the same path to
memory" means the path from current L2 of cpu1 to to L3 to memory and
the copies which need to be invalidated should be the ones from L1, L2
of cpu2 (not including the copies of L3) . Is my understanding correct?
Please correct me and clarify it if not.

Thanks in advance!

gjins



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


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

[gem5-users] M5thread support on 32 bit system

[Nidhi Kamath]

Hello,

I do understand that for multithreading in gem5 SE x86, I need to use
m5threads. Correct me if I am wrong.

Are m5threads supported on a 32 bit system ?

I found an old mail archive which says that it does not support.

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