Re: [gem5-users] Garnet 2.0: Invariable Injection Rate for Different Vnets

2017-07-28 Thread Krishna, Tushar 
The mesh in garnet is deadlock free since it uses xy routing (if u use mesh_xy 
topology) which eliminates cyclic dependences. And unlike Torus, u cannot don't 
have a ring in each dimension so there cannot be a cyclic dependence there 
either. If you are seeing a deadlock then something else is wrong.

Cheers,
Tushar

On Jul 28, 2017, at 11:28 PM, F. A. Faisal 
> wrote:

Dear Professor,

Thanks for the reply.

However, I think there is no deadlock prevention mechanism is also implemented 
in garnet.
Such case, a simple mesh network can also create the deadlocks with the side by 
side nodes.

It is required to make the Deadlock prevention like- hold and wait.

To do this we definitely need to know the out VC condition for next router/node 
and check his status.
If that node is free for next outport with correct VC number, only then We can 
send the packet to the outport of the current Node.
However, I think garnet does not have this checking on the port status of the 
next node and its outport VC.

This is a very important issue for garnet.

Please help me.

Thanks and regards,

F. A. Faisal


On Fri, Jul 28, 2017 at 11:28 PM, Krishna, Tushar 
> wrote:
Hi Faisal,
I would try testing the design with one vnet (--inj-vnet=0). And within each 
vnet you need to vc partitioning scheme - you basically need to ensure that 
there is no potential cyclic dependence between the VCs. I'll reply to your 
query in your earlier email next week.

Cheers,
Tushar

> On Jul 28, 2017, at 6:57 PM, F. A. Faisal 
> > wrote:
>
> Dear All,
>
> I found that using high simulation cycle and large network like- 256 nodes 
> the flit injection rate for different Vnets are different. Hence, networks 
> like Torus are becoming deadlocked very soon, even I implement the VC 
> partitioning.
>
> Now, the question is can I use the different VC of Different Vnets for 
> reducing this conjection
> or can I distribute the flits evenly between all the vnets to make sure the 
> network is not in deadlock.
>
> I will appreciate your earliest reply.
>
> Thanks and best regards,
>
> F. A. Faisal
> ___
> 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

Re: [gem5-users] Garnet 2.0: Invariable Injection Rate for Different Vnets

2017-07-28 Thread F. A. Faisal 
Dear Professor,

Thanks for the reply.

However, I think there is no deadlock prevention mechanism is also
implemented in garnet.
Such case, a simple mesh network can also create the deadlocks with the
side by side nodes.

It is required to make the Deadlock prevention like- hold and wait.

To do this we definitely need to know the out VC condition for next
router/node and check his status.
If that node is free for next outport with correct VC number, only then We
can send the packet to the outport of the current Node.
However, I think garnet does not have this checking on the port status of
the next node and its outport VC.

This is a very important issue for garnet.

Please help me.

Thanks and regards,

F. A. Faisal


On Fri, Jul 28, 2017 at 11:28 PM, Krishna, Tushar 
wrote:

> Hi Faisal,
> I would try testing the design with one vnet (--inj-vnet=0). And within
> each vnet you need to vc partitioning scheme - you basically need to ensure
> that there is no potential cyclic dependence between the VCs. I'll reply to
> your query in your earlier email next week.
>
> Cheers,
> Tushar
>
> > On Jul 28, 2017, at 6:57 PM, F. A. Faisal  wrote:
> >
> > Dear All,
> >
> > I found that using high simulation cycle and large network like- 256
> nodes the flit injection rate for different Vnets are different. Hence,
> networks like Torus are becoming deadlocked very soon, even I implement the
> VC partitioning.
> >
> > Now, the question is can I use the different VC of Different Vnets for
> reducing this conjection
> > or can I distribute the flits evenly between all the vnets to make sure
> the network is not in deadlock.
> >
> > I will appreciate your earliest reply.
> >
> > Thanks and best regards,
> >
> > F. A. Faisal
> > ___
> > 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

Re: [gem5-users] Garnet 2.0: Invariable Injection Rate for Different Vnets

2017-07-28 Thread Krishna, Tushar 
Hi Faisal,
I would try testing the design with one vnet (--inj-vnet=0). And within each 
vnet you need to vc partitioning scheme - you basically need to ensure that 
there is no potential cyclic dependence between the VCs. I'll reply to your 
query in your earlier email next week.

Cheers,
Tushar

> On Jul 28, 2017, at 6:57 PM, F. A. Faisal  wrote:
> 
> Dear All,
> 
> I found that using high simulation cycle and large network like- 256 nodes 
> the flit injection rate for different Vnets are different. Hence, networks 
> like Torus are becoming deadlocked very soon, even I implement the VC 
> partitioning. 
> 
> Now, the question is can I use the different VC of Different Vnets for 
> reducing this conjection
> or can I distribute the flits evenly between all the vnets to make sure the 
> network is not in deadlock.
> 
> I will appreciate your earliest reply.
> 
> Thanks and best regards,
> 
> F. A. Faisal 
> ___
> 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] Garnet 2.0: Invariable Injection Rate for Different Vnets

2017-07-28 Thread F. A. Faisal 
Dear All,

I found that using high simulation cycle and large network like- 256 nodes
the flit injection rate for different Vnets are different. Hence, networks
like Torus are becoming deadlocked very soon, even I implement the VC
partitioning.

Now, the question is can I use the different VC of Different Vnets for
reducing this conjection
or can I distribute the flits evenly between all the vnets to make sure the
network is not in deadlock.

I will appreciate your earliest reply.

Thanks and best regards,

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

[gem5-users] Question about increasing the size of physical memory and stack size

2017-07-28 Thread Zeynab Mohseni 
Dear friends,
I ran the bzip2 benchmark in GEM5 with RISCV and there are few messages related 
to the size of physical memory and stack as you can see below. I checked the 
pagePtr in the /GEM5_RISCV/gem5/src/sim/system.cc which is caused the "Out of 
memory, please increase size of physical memory" message. Also I increased the 
device size in /GEM5_RISCV/gem5/src/mem/DRAMCtrl.py to change the size of 
physical memory file, but the result was the same. I want to know how should I 
do exactly  in order to solve the problem. It should be note that the stats.txt 
is empty after running the run_gem5_riscv_spec06_benchmark.sh in Gem5 with 
RISCV.
It would be perfect if you guide me.

aries@aries-HP-Z600-Workstation:~/GEM5_RISCV/gem5$ 
./run_gem5_riscv_spec06_benchmark.sh bzip2 
/home/aries/GEM5_RISCV/gem5/output_dir
Command line:
./run_gem5_riscv_spec06_benchmark.sh bzip2 
/home/aries/GEM5_RISCV/gem5/output_dir
= Hardcoded directories ==
GEM5_DIR: /home/aries/GEM5_RISCV/gem5
SPEC_DIR: /home/aries/cpu2006
 Script inputs ===
BENCHMARK:bzip2
OUTPUT_DIR:   
/home/aries/GEM5_RISCV/gem5/output_dir
==

Changing to SPEC benchmark runtime directory: 
/home/aries/cpu2006/benchspec/CPU2006/401.bzip2/run/run_base_ref_riscv.


- Here goes nothing! Starting gem5! 


warn: DRAM device capacity (8192 Mbytes) does not match the address range 
assigned (512 Mbytes)
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Jul 28 2017 11:14:51
gem5 started Jul 28 2017 11:15:11
gem5 executing on aries-HP-Z600-Workstation, pid 22450
command line: /home/aries/GEM5_RISCV/gem5/build/RISCV/gem5.opt 
--outdir=/home/aries/GEM5_RISCV/gem5/output_dir 
/home/aries/GEM5_RISCV/gem5/configs/example/spec06_config.py --benchmark=bzip2 
--benchmark_stdout=/home/aries/GEM5_RISCV/gem5/output_dir/bzip2.out 
--benchmark_stderr=/home/aries/GEM5_RISCV/gem5/output_dir/bzip2.err

Selected SPEC_CPU2006 benchmark
--> bzip2
Process stdout file: /home/aries/GEM5_RISCV/gem5/output_dir/bzip2.out
Process stderr file: /home/aries/GEM5_RISCV/gem5/output_dir/bzip2.err
['/home/aries/GEM5_RISCV/binaries_riscv/benchspec/CPU2006/401.bzip2/exe/bzip2_base.riscv',
 'input.source', '280']
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
info: Entering event queue @ 0.  Starting simulation...
 REAL SIMULATION 
warn: readlink() called on '/proc/self/exe' may yield unexpected results in 
various settings.
  Returning 
'/home/aries/GEM5_RISCV/binaries_riscv/benchspec/CPU2006/401.bzip2/exe/bzip2_base.riscv'
info: Increasing stack size by one page.
fatal: Out of memory, please increase size of physical memory.
Memory Usage: 644128 KBytes


Sincerely,
Artemis


[1484656507333_OutlookEmoji-1484656219114_image001.png.png]
Zeynab (Artemis) Mohseni
Researcher / PhD Candidate

ARIES RESEARCH CENTER
http://www.nebrija.es/aries

La Dehesa de La Villa Campus
55, Prineos Street, Madrid, 28040
Spain

(+34) 91 452 11 00 (ext. 2807)
zmohs...@nebrija.es
www.nebrija.com


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