Re: [gem5-dev] Review Request: Ruby: Convert to M5 Stats

2011-05-31 Thread Korey Sewell

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/704/#review1292
---



src/mem/ruby/profiler/Profiler.hh
http://reviews.m5sim.org/r/704/#comment1760

In my recent Ruby experiences, I agree with Brad to keep most if not all of 
these. Can we just convert these to M5 with the same names?

Subsequent changesets could consider if somethign is unnnecessary.

Also missLatency is really accessLatency as previously discussed. Can 
we change that?



src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/704/#comment1759

We are going to call this access latency eventually right? Might as well 
change it now...


- Korey


On 2011-05-16 15:06:16, Derek Hower wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/704/
 ---
 
 (Updated 2011-05-16 15:06:16)
 
 
 Review request for Default, Nathan Binkert, Korey Sewell, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch contains changes to convert Ruby's stat handling to the M5-style 
 Stat class. The ultimate goal is to remove Profiler entirely, though this 
 patch only represents a (significant) step towards that goal. Some stats 
 remain in the Profiler, notably those that do not have an obvious object to 
 hold them (like Address Profiler) or those that I'm not sure what they do 
 (e.g., *wCC*). Also, this patch does not contain a Garnet stats conversion 
 (though the simple network is converted).
 
 
 Diffs
 -
 
   src/mem/ruby/network/simple/SimpleNetwork.hh UNKNOWN 
   src/mem/ruby/network/simple/SimpleNetwork.cc UNKNOWN 
   src/mem/ruby/network/simple/Throttle.hh UNKNOWN 
   src/mem/ruby/network/simple/Throttle.cc UNKNOWN 
   src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/CacheProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/CacheProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/MemCntrlProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/MemCntrlProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/Profiler.hh UNKNOWN 
   src/mem/ruby/profiler/Profiler.cc UNKNOWN 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.cc UNKNOWN 
   src/mem/ruby/system/CacheMemory.hh UNKNOWN 
   src/mem/ruby/system/MemoryControl.hh UNKNOWN 
   src/mem/ruby/system/Sequencer.hh UNKNOWN 
   src/mem/ruby/system/Sequencer.cc UNKNOWN 
   src/mem/ruby/system/System.cc UNKNOWN 
   src/mem/slicc/symbols/StateMachine.py UNKNOWN 
 
 Diff: http://reviews.m5sim.org/r/704/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Derek
 


___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in m5: garnet: added network ptr to links to be used b...

2011-05-31 Thread Tushar Krishna
changeset 24a00a6d5992 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=24a00a6d5992
description:
garnet: added network ptr to links to be used by orion

diffstat:

 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc |  7 +++
 src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh   |  7 ++-
 src/mem/ruby/network/orion/NetworkPower.cc|  8 ++--
 3 files changed, 15 insertions(+), 7 deletions(-)

diffs (58 lines):

diff -r 03cfd2ecf6bb -r 24a00a6d5992 
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc
--- a/src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc Sun May 
29 21:48:58 2011 -0700
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc Tue May 
31 02:55:14 2011 -0400
@@ -90,6 +90,13 @@
 }
 // false because this isn't a reconfiguration
 m_topology_ptr-createLinks(this, false);
+
+// initialize the link's network pointers
+   for (vectorNetworkLink_d*::const_iterator i = m_link_ptr_vector.begin();
+ i != m_link_ptr_vector.end(); ++i) {
+NetworkLink_d* net_link = safe_castNetworkLink_d*(*i);
+net_link-init_net_ptr(this);
+}
 }
 
 GarnetNetwork_d::~GarnetNetwork_d()
diff -r 03cfd2ecf6bb -r 24a00a6d5992 
src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh
--- a/src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh   Sun May 
29 21:48:58 2011 -0700
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh   Tue May 
31 02:55:14 2011 -0400
@@ -65,12 +65,17 @@
 inline bool isReady()   { return linkBuffer-isReady(); }
 inline flit_d* peekLink()   { return linkBuffer-peekTopFlit(); }
 inline flit_d* consumeLink(){ return linkBuffer-getTopFlit(); }
+void init_net_ptr(GarnetNetwork_d* net_ptr)
+{
+m_net_ptr = net_ptr;
+}
 
   protected:
 int m_id;
 int m_latency;
+int channel_width;
 
-int channel_width;
+GarnetNetwork_d *m_net_ptr;
 flitBuffer_d *linkBuffer;
 Consumer *link_consumer;
 flitBuffer_d *link_srcQueue;
diff -r 03cfd2ecf6bb -r 24a00a6d5992 src/mem/ruby/network/orion/NetworkPower.cc
--- a/src/mem/ruby/network/orion/NetworkPower.ccSun May 29 21:48:58 
2011 -0700
+++ b/src/mem/ruby/network/orion/NetworkPower.ccTue May 31 02:55:14 
2011 -0400
@@ -245,13 +245,9 @@
 channel_width/* channel width */,
 orion_cfg_ptr);
 
-//
-//  NOTE!  I believe this calculation will be moved to McPAT, thus this
-//  reference to the net_ptr can be removed
-//
 //// Dynamic Power
-double sim_cycles = 0.0;
-// (double)(g_eventQueue_ptr-getTime() - 
m_net_ptr-getRubyStartTime());
+double sim_cycles =
+(double)(g_eventQueue_ptr-getTime() - m_net_ptr-getRubyStartTime());
 
 double Plink_dyn = orion_link_ptr-calc_dynamic_energy(channel_width/2)*
 (m_link_utilized/ sim_cycles)*freq_Hz;
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in m5: orion: bug fix in link power, and some reorg

2011-05-31 Thread Tushar Krishna
changeset 681497e0356b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=681497e0356b
description:
orion: bug fix in link power, and some reorg

diffstat:

 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc |   3 +
 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh|   2 +
 src/mem/ruby/network/orion/NetworkPower.cc|  42 ++
 3 files changed, 29 insertions(+), 18 deletions(-)

diffs (183 lines):

diff -r 24a00a6d5992 -r 681497e0356b 
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc
--- a/src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc Tue May 
31 02:55:14 2011 -0400
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc Tue May 
31 02:56:22 2011 -0400
@@ -327,6 +327,7 @@
 double m_total_router_power = 0.0;
 double m_dynamic_router_power = 0.0;
 double m_static_router_power = 0.0;
+double m_clk_power = 0.0;
 
 for (int i = 0; i  m_link_ptr_vector.size(); i++) {
 m_total_link_power += m_link_ptr_vector[i]-calculate_power();
@@ -338,11 +339,13 @@
 m_total_router_power += m_router_ptr_vector[i]-calculate_power();
 m_dynamic_router_power += m_router_ptr_vector[i]-get_dynamic_power();
 m_static_router_power += m_router_ptr_vector[i]-get_static_power();
+m_clk_power += m_router_ptr_vector[i]-get_clk_power();
 }
 out  Link Dynamic Power =   m_dynamic_link_power   W  endl;
 out  Link Static Power =   m_static_link_power   W  endl;
 out  Total Link Power =   m_total_link_power   W   endl;
 out  Router Dynamic Power =   m_dynamic_router_power   W  endl;
+out  Router Clock Power =   m_clk_power   W  endl;
 out  Router Static Power =   m_static_router_power   W  endl;
 out  Total Router Power =   m_total_router_power   W  endl;
 out  -  endl;
diff -r 24a00a6d5992 -r 681497e0356b 
src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh
--- a/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hhTue May 31 
02:55:14 2011 -0400
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hhTue May 31 
02:56:22 2011 -0400
@@ -92,6 +92,7 @@
 
 double get_dynamic_power(){return m_power_dyn;}
 double get_static_power(){return m_power_sta;}
+double get_clk_power(){return m_clk_power;}
 
   private:
 int m_virtual_networks, m_num_vcs, m_vc_per_vnet;
@@ -113,6 +114,7 @@
 
 double m_power_dyn;
 double m_power_sta;
+double m_clk_power;
 };
 
 #endif // __MEM_RUBY_NETWORK_GARNET_FIXED_PIPELINE_ROUTER_D_HH__
diff -r 24a00a6d5992 -r 681497e0356b src/mem/ruby/network/orion/NetworkPower.cc
--- a/src/mem/ruby/network/orion/NetworkPower.ccTue May 31 02:55:14 
2011 -0400
+++ b/src/mem/ruby/network/orion/NetworkPower.ccTue May 31 02:56:22 
2011 -0400
@@ -40,7 +40,8 @@
 //Network Activities from garnet
 calculate_performance_numbers();
 double sim_cycles;
-sim_cycles = g_eventQueue_ptr-getTime() - 
m_network_ptr-getRubyStartTime();
+sim_cycles =
+g_eventQueue_ptr-getTime() - m_network_ptr-getRubyStartTime();
 
 // Number of virtual networks/message classes declared in Ruby
 // maybe greater than active virtual networks.
@@ -88,7 +89,8 @@
 for (int i = 0; i  m_virtual_networks; i++) {
 if (active_vclass_ary[i]) {
 int temp_vc = i*m_vc_per_vnet;
-vclass_type_ary.push_back((uint32_t) 
m_network_ptr-get_vnet_type(temp_vc));
+vclass_type_ary.push_back((uint32_t) 
+m_network_ptr-get_vnet_type(temp_vc));
 }
 }
 assert(vclass_type_ary.size() == num_active_vclass);
@@ -97,7 +99,7 @@
 uint32_t in_buf_per_data_vc = m_network_ptr-getBuffersPerDataVC();
 uint32_t in_buf_per_ctrl_vc = m_network_ptr-getBuffersPerCtrlVC();
 //flit width in bits
-uint32_t flit_width = m_network_ptr-getNiFlitSize() * 8; 
+uint32_t flit_width_bits = m_network_ptr-getNiFlitSize() * 8; 
 
 orion_rtr_ptr = new OrionRouter(
 num_in_port,
@@ -107,7 +109,7 @@
 num_vc_per_vclass,
 in_buf_per_data_vc,
 in_buf_per_ctrl_vc,
-flit_width,
+flit_width_bits,
 orion_cfg_ptr
 );
 
@@ -120,7 +122,6 @@
 double Psw_arb_local_dyn = 0.0;
 double Psw_arb_global_dyn = 0.0;
 double Pxbar_dyn = 0.0;
-double Pclk_dyn = 0.0;
 double Ptotal_dyn = 0.0;
 
 double Pbuf_sta = 0.0;
@@ -178,7 +179,7 @@
 // Switch Allocation Local
 // Each input port chooses one input VC as requestor
 // Arbiter size: num_vclass*num_vc_per_vclass:1
-Psw_arb_local_dyn +=
+Psw_arb_local_dyn =
 orion_rtr_ptr-calc_dynamic_energy_local_sw_arb(
 num_vclass*num_vc_per_vclass/2, false)*
 (sw_local_arbit_count/sim_cycles)*
@@ -187,28 +188,27 @@
 // Switch Allocation Global
 // Each output port chooses one input port as winner
 // Arbiter size: num_in_port:1
-

Re: [gem5-dev] Review Request: ISA parser: Simplify operand type handling.

2011-05-31 Thread Gabe Black
On 05/30/11 21:57, Steve Reinhardt wrote:
 On Mon, May 30, 2011 at 1:33 PM, Gabe Black gbl...@eecs.umich.edu wrote:
 On 05/30/11 09:47, Steve Reinhardt wrote:
 Anyway, it seems very odd to have to say (int8_t)Mem.ub when we already 
 have a .sb operand type defined as int8_t.  It seems like a weird 
 hidden restriction to say that there are operand types you can declare but 
 can't use on memory, and that you're pushing a somewhat arbitrary internal 
 implementation decision up to the level of language visibility, which is 
 going the wrong direction.  I'm not sure what the right solution is, but 
 even if it's the brute force one of creating a bunch more read/write 
 function templates in the CPU implementations, I think that's preferable.
 [...]

 The unsigned thing is sort of a weird gotcha. I'd like to avoid adding a
 lot of bulk to the CPU models since they're already fairly chunky and it
 makes them harder to reason about looking through the code, but it would
 be great to straighten this out. One possibility might be the technique
 I used with the endianness changing functions in src/sim/byteswap.hh.
 Things are built up in layers there:
 [...]
 I think some kind of additional set of template instantiations should
 do it.  I just noticed that we already have:

 template
 Fault
 AtomicSimpleCPU::read(Addr addr, int32_t data, unsigned flags)
 {
 return read(addr, (uint32_t)data, flags);
 }

 template
 Fault
 AtomicSimpleCPU::write(int32_t data, Addr addr, unsigned flags, uint64_t *res)
 {
 return write((uint32_t)data, addr, flags, res);
 }

 .. and similar for TimingSimpleCPU; do we just need to extend these to
 int8_t and int16_t, and maybe add similar sets in
 base_dynamic_inst.hh?

 Steve
 ___
 gem5-dev mailing list
 gem5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/gem5-dev

Oh yeah, I guess we're already doing something like that, and that glob
of code was just instantiating different versions of the function. Could
we reduce the amount of text by moving it into the header? There isn't a
lot of actual information there in all that text, and we're talking
about doubling it. I don't have a better idea, though.

Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick

2011-05-31 Thread Cron Daemon
scons: `build/ALPHA_SE/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.debug' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.debug' is up to date.
scons: `build/ALPHA_FS/m5.debug' is up to date.
scons: `build/MIPS_SE/m5.debug' is up to date.
scons: `build/POWER_SE/m5.debug' is up to date.
scons: `build/SPARC_SE/m5.debug' is up to date.
scons: `build/SPARC_FS/m5.debug' is up to date.
scons: `build/X86_SE/m5.debug' is up to date.
scons: `build/X86_FS/m5.debug' is up to date.
scons: `build/ARM_SE/m5.debug' is up to date.
scons: `build/ARM_FS/m5.debug' is up to date.
scons: `build/ALPHA_SE/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.fast' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.fast' is up to date.
scons: `build/ALPHA_FS/m5.fast' is up to date.
scons: `build/MIPS_SE/m5.fast' is up to date.
scons: `build/POWER_SE/m5.fast' is up to date.
scons: `build/SPARC_SE/m5.fast' is up to date.
scons: `build/SPARC_FS/m5.fast' is up to date.
scons: `build/X86_SE/m5.fast' is up to date.
scons: `build/X86_FS/m5.fast' is up to date.
scons: `build/ARM_SE/m5.fast' is up to date.
scons: `build/ARM_FS/m5.fast' is up to date.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 

[gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Tushar Krishna

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Ali Saidi

Upload graphics using the repository not the wiki interface.

Thanks,
Ali


On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna 
tus...@csail.mit.edu wrote:

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Tushar Krishna

Thanks Ali.
This is the repo right?
h...@m5sim.org/web-graphics

And how do I point to the images in the repo from the wiki?

Thanks,
Tushar


On 5/31/2011 2:13 PM, Ali Saidi wrote:

Upload graphics using the repository not the wiki interface.

Thanks,
Ali


On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna 
tus...@csail.mit.edu wrote:

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Ali Saidi
On Tue, 31 May 2011 14:46:37 -0400, Tushar Krishna 
tus...@csail.mit.edu wrote:

Thanks Ali.
This is the repo right?
h...@m5sim.org/web-graphics


Yes


And how do I point to the images in the repo from the wiki?


http://www.gem5.org/graphics

Ali

___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in web-graphics: network: updated topology figure

2011-05-31 Thread Tushar Krishna
changeset 8b47475cd2b3 in /z/repo/web-graphics
details: web-graphics?cmd=changeset;node=8b47475cd2b3
description:
network: updated topology figure

diffstat:

 ruby/figures/Topology_overview.jpg |0 
 1 files changed, 0 insertions(+), 0 deletions(-)

diffs (2 lines):

diff -r 1f62f3ea6275 -r 8b47475cd2b3 ruby/figures/Topology_overview.jpg
Binary file ruby/figures/Topology_overview.jpg has changed
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in web-graphics: Resize topology figure

2011-05-31 Thread Tushar Krishna
changeset c1a85b596072 in /z/repo/web-graphics
details: web-graphics?cmd=changeset;node=c1a85b596072
description:
Resize topology figure

diffstat:

 ruby/figures/Topology_overview.jpg |0 
 1 files changed, 0 insertions(+), 0 deletions(-)

diffs (2 lines):

diff -r 8b47475cd2b3 -r c1a85b596072 ruby/figures/Topology_overview.jpg
Binary file ruby/figures/Topology_overview.jpg has changed
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Functional Memory Accesses in Ruby

2011-05-31 Thread Nilay Vaish

On Sat, 28 May 2011, Nilay Vaish wrote:


Hi Brad

I am trying to complete the patch on functional accesses in Ruby. I came 
across this problem while testing the patch for higher number of processors. 
I am working with MESI CMP directory protocol right now. So I will describe 
the problem in its context.


Assume we are trying to functionally write some thing to block A. It is in 
state S_I in the L2 cache. When a block moves to state S_I from state SS, 
then the cache block in the cache is deallocated. Therefore, when viewed from 
the CacheMemory's perpespective, since the cache does not have block A, 
therefore, the L2 cache is of no consequence for this access. But the 
controller has a TBE for this block. And this TBE will have this block with 
AccessPermission:Busy. Also, there are L1 caches in the system that hold this 
block in S state.


Now, as per the current condition for write functional accesses,

if((num_busy == 0  num_ro  0) || num_rw == 1)

this access would go ahead as num_busy would evaluate to 0 and num_ro would 
evaluate to some value greater than 0. But clearly we do not want this access 
to be performed since that state S_I is a busy state and no other cache holds 
the block in a read-write state.


It seems to me that the controller should supply the function for deciding 
the access permissions, since it is possible that one the TBE holds the 
block.


--
Nilay



Brad, I went over the discussion that we had this morning. I think the 
getState() function cannot be used for extracting access permissions. This 
is because the getState() function needs pouinters to transaction buffer 
and cache entries, apart from the address.


I think we should let the Controller provide a function for getting the 
access permissions. This function would be a virtual function declared in 
the AbstractController class, but would not be pure. The 
AbstractController implementation of the function would always return 
busy, so that functional accesses are not enabled at all for protocols 
that do not provide such a function.


--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] registerThreadContext

2011-05-31 Thread Steve Reinhardt
On Wed, May 25, 2011 at 10:57 AM, nathan binkert n...@binkert.org wrote:

 I see a few options for solving this problem:
 1) Separate out the contextId allocation from registerThreadContext so
 things like DMA controllers and memtesters can get allocated a
 contextID.
 2) Create a base class for ThreadContext that is far simpler than the
 current thread context and use that when registering.
 3) Figure out contextID not by registration, but instead by doing a
 traversal of the memory system.  This would require that we have some
 sort of indication differentiating memory objects that can generate
 requests and thus require a contextID and memory objects that can't
 (caches, dram, pio devices, etc.).  We add a constructor parameter to
 the MemObject base class.
 4) Add a separate registration function for non Thread Contexts.

While #3 sounds nice, it's a relatively big change, and would have to
be done in a way that works both for the m5 classic memory system and
for Ruby, and ideally is robust and predictable in assigning
contextIDs in the face of minor configuration changes.  My guess is
that it will end up being harder than it sounds... maybe Korey can
speak up if his experience indicates otherwise.

The others seem more reasonable, but possibly still overkill.

The idea I had, that's kind of a hack but combines #2 and #4 in a
degenerate sort of way, would be to allow non-ThreadContext objects to
call registerThreadContext, but they would pass in NULL for the
ThreadContext pointer.  This would allow something like a DMA device
or the memtester to reserve or allocate a context ID without being a
ThreadContext, but without creating an additional base class.  The
only down side I see is that error tracking would be harder; if two
non-ThreadContexts tried to claim the same ID, the System would not
have a pointer to be able to identify the first one.  Basically that's
the only case I can see where it would be useful for the System object
to hold on to some kind of pointer for something that's not an actual
ThreadContext.  Of course, the current ThreadContext pointers don't
have any real debug info either, so even now you just get Cannot have
two CPUs with the same id (%d)\n when you try to reuse a context ID,
so apparently it hasn't been a big problem.

If we cared about providing good error messages, we could extend
registerThreadContext to take both a SimObject* and a ThreadContext*
and track both of these, but make the latter optional.  This would
provide better error messages for everyone (though again, this hasn't
been a problem that I've seen).  registerThreadContext is only called
from one place (BaseCPU::registerThreadContexts()) so it wouldn't be
hard to change that.

Just some ideas...

Steve
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] registerThreadContext

2011-05-31 Thread Gabe Black
On 05/31/11 22:43, Steve Reinhardt wrote:
 On Wed, May 25, 2011 at 10:57 AM, nathan binkert n...@binkert.org wrote:
 I see a few options for solving this problem:
 1) Separate out the contextId allocation from registerThreadContext so
 things like DMA controllers and memtesters can get allocated a
 contextID.
 2) Create a base class for ThreadContext that is far simpler than the
 current thread context and use that when registering.
 3) Figure out contextID not by registration, but instead by doing a
 traversal of the memory system.  This would require that we have some
 sort of indication differentiating memory objects that can generate
 requests and thus require a contextID and memory objects that can't
 (caches, dram, pio devices, etc.).  We add a constructor parameter to
 the MemObject base class.
 4) Add a separate registration function for non Thread Contexts.
 While #3 sounds nice, it's a relatively big change, and would have to
 be done in a way that works both for the m5 classic memory system and
 for Ruby, and ideally is robust and predictable in assigning
 contextIDs in the face of minor configuration changes.  My guess is
 that it will end up being harder than it sounds... maybe Korey can
 speak up if his experience indicates otherwise.

 The others seem more reasonable, but possibly still overkill.

 The idea I had, that's kind of a hack but combines #2 and #4 in a
 degenerate sort of way, would be to allow non-ThreadContext objects to
 call registerThreadContext, but they would pass in NULL for the
 ThreadContext pointer.  This would allow something like a DMA device
 or the memtester to reserve or allocate a context ID without being a
 ThreadContext, but without creating an additional base class.  The
 only down side I see is that error tracking would be harder; if two
 non-ThreadContexts tried to claim the same ID, the System would not
 have a pointer to be able to identify the first one.  Basically that's
 the only case I can see where it would be useful for the System object
 to hold on to some kind of pointer for something that's not an actual
 ThreadContext.  Of course, the current ThreadContext pointers don't
 have any real debug info either, so even now you just get Cannot have
 two CPUs with the same id (%d)\n when you try to reuse a context ID,
 so apparently it hasn't been a big problem.

 If we cared about providing good error messages, we could extend
 registerThreadContext to take both a SimObject* and a ThreadContext*
 and track both of these, but make the latter optional.  This would
 provide better error messages for everyone (though again, this hasn't
 been a problem that I've seen).  registerThreadContext is only called
 from one place (BaseCPU::registerThreadContexts()) so it wouldn't be
 hard to change that.

 Just some ideas...

 Steve
 ___
 gem5-dev mailing list
 gem5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/gem5-dev

One drawback I see with this sort of approach is that you have to be
careful if you want to loop over all registered contexts and do
something with their thread contexts. You'd have to be careful to check
which ones were NULL, and if that's uncommon it might be easy to forget
to do.

Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev