[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** [build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 See /z/m5/regression/regress-2011-01-13-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Style checker: Fix a couple bugs in style.py.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/424/#review725 --- Ship it! Looks good to me. I must not have tested whitespace after I refactored some diffs. - Nathan On 2011-01-13 02:05:53, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/424/ --- (Updated 2011-01-13 02:05:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Style checker: Fix a couple bugs in style.py. Diffs - util/style.py de7601e6e19d Diff: http://reviews.m5sim.org/r/424/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Style checker: Fix a couple bugs in style.py.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/424/#review726 --- Ship it! - Ali On 2011-01-13 02:05:53, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/424/ --- (Updated 2011-01-13 02:05:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Style checker: Fix a couple bugs in style.py. Diffs - util/style.py de7601e6e19d Diff: http://reviews.m5sim.org/r/424/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review727 --- I can't fully appreciate these latest changes without also seeing the updated .sm files, but overall this looks very inline with what we have been discussing over the past few days. I just have one basic question on why we need to overload doTransition, getState, and setState. Why can't we just have one version? Also a possibly related idea is can you insert asserts (!= NULL) for the tbe and cache_entry pointers before they are dereferenced in the generated code? src/mem/slicc/ast/FuncCallExprAST.py http://reviews.m5sim.org/r/358/#comment991 Why do we need four versions of doTransition? Can't we just pass in NULL/OOD for the tbe and cache_entry? src/mem/slicc/symbols/StateMachine.py http://reviews.m5sim.org/r/358/#comment990 After you make your change, why would getState ever be called without the address, tbe, and cache_entry? Wouldn't you just pass in NULL/OOD if the tbe or cache_entry didn't exist? src/mem/slicc/symbols/StateMachine.py http://reviews.m5sim.org/r/358/#comment989 After you make this change, why would setState ever be called without passing the address, tbe, and cache_entry? - Brad On 2011-01-12 22:45:22, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:45:22) Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/protocol/RubySlicc_Types.sm c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc c6bc8fe81e79 src/mem/ruby/system/CacheMemory.hh c6bc8fe81e79 src/mem/ruby/system/CacheMemory.cc c6bc8fe81e79 src/mem/ruby/system/TBETable.hh c6bc8fe81e79 src/mem/slicc/ast/ActionDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/FormalParamAST.py c6bc8fe81e79 src/mem/slicc/ast/FuncCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/IfStatementAST.py c6bc8fe81e79 src/mem/slicc/ast/InPortDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/IsValidPtrExprAST.py PRE-CREATION src/mem/slicc/ast/LocalVariableAST.py PRE-CREATION src/mem/slicc/ast/MethodCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/StaticCastAST.py c6bc8fe81e79 src/mem/slicc/ast/TypeDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/__init__.py c6bc8fe81e79 src/mem/slicc/parser.py c6bc8fe81e79 src/mem/slicc/symbols/Func.py c6bc8fe81e79 src/mem/slicc/symbols/StateMachine.py c6bc8fe81e79 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory and MI protocols. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
On 2011-01-13 08:33:49, Brad Beckmann wrote: I can't fully appreciate these latest changes without also seeing the updated .sm files, but overall this looks very inline with what we have been discussing over the past few days. I just have one basic question on why we need to overload doTransition, getState, and setState. Why can't we just have one version? Also a possibly related idea is can you insert asserts (!= NULL) for the tbe and cache_entry pointers before they are dereferenced in the generated code? Because Entry and/or TBE types might not be defined at all for particular controllers. Same holds true for the getState() and setState(). Also, getState() and setState() do not require the address, if the tbe and cache_entry have been properly set. On 2011-01-13 08:33:49, Brad Beckmann wrote: src/mem/slicc/ast/FuncCallExprAST.py, line 127 http://reviews.m5sim.org/r/358/diff/9/?file=9549#file9549line127 Why do we need four versions of doTransition? Can't we just pass in NULL/OOD for the tbe and cache_entry? Because Entry type might not be defined at all for that particular controller. Same holds true for the getState() and setState(). Also, getState() and setState() do not require the address, if the tbe and cache_entry have been properly set. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review727 --- On 2011-01-12 22:45:22, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:45:22) Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/protocol/RubySlicc_Types.sm c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc c6bc8fe81e79 src/mem/ruby/system/CacheMemory.hh c6bc8fe81e79 src/mem/ruby/system/CacheMemory.cc c6bc8fe81e79 src/mem/ruby/system/TBETable.hh c6bc8fe81e79 src/mem/slicc/ast/ActionDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/FormalParamAST.py c6bc8fe81e79 src/mem/slicc/ast/FuncCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/IfStatementAST.py c6bc8fe81e79 src/mem/slicc/ast/InPortDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/IsValidPtrExprAST.py PRE-CREATION src/mem/slicc/ast/LocalVariableAST.py PRE-CREATION src/mem/slicc/ast/MethodCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/StaticCastAST.py c6bc8fe81e79 src/mem/slicc/ast/TypeDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/__init__.py c6bc8fe81e79 src/mem/slicc/parser.py c6bc8fe81e79 src/mem/slicc/symbols/Func.py c6bc8fe81e79 src/mem/slicc/symbols/StateMachine.py c6bc8fe81e79 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory and MI protocols. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Updating MOESI CMP Directory protocol as per the new interface
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/#review728 --- Ship it! Well Done! I have a couple questions just to clarify my understanding of what is going on, but overall this looks great to me. src/mem/protocol/MOESI_CMP_directory-L1cache.sm http://reviews.m5sim.org/r/359/#comment992 So the assumption here is the L1IcacheMemory.lookup() call either returns the L1I cache entry or NULL/OOD, correct? Does SLICC also support explicitly passing back OOD? src/mem/protocol/MOESI_CMP_directory-L1cache.sm http://reviews.m5sim.org/r/359/#comment993 This seems like an unrelated change, correct. However it is pretty minor, so don't worry about it. - Brad On 2011-01-12 22:44:50, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/ --- (Updated 2011-01-12 22:44:50) Review request for Default. Summary --- This is a request for reviewing the proposed changes to the MOESI CMP directory cache coherence protocol to make it conform with the new cache memory interface and changes to SLICC. Diffs - src/mem/protocol/MOESI_CMP_directory-L1cache.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-L2cache.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-dir.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-dma.sm c6bc8fe81e79 Diff: http://reviews.m5sim.org/r/359/diff Testing --- These changes have been tested using the Ruby random tester. The tester was used with -l = 1048576 and -n = 2. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Updating MOESI CMP Directory protocol as per the new interface
On 2011-01-13 08:48:29, Brad Beckmann wrote: src/mem/protocol/MOESI_CMP_directory-L1cache.sm, line 159 http://reviews.m5sim.org/r/359/diff/8/?file=9537#file9537line159 So the assumption here is the L1IcacheMemory.lookup() call either returns the L1I cache entry or NULL/OOD, correct? Does SLICC also support explicitly passing back OOD? Currently, SLICC does not have support for Out Of Domain (OOD) token. But I can add that as I had done earlier. I am not sure if we actually need it. On 2011-01-13 08:48:29, Brad Beckmann wrote: src/mem/protocol/MOESI_CMP_directory-L1cache.sm, line 465 http://reviews.m5sim.org/r/359/diff/8/?file=9537#file9537line465 This seems like an unrelated change, correct. However it is pretty minor, so don't worry about it. IIRC, this is necessary or else a certain panic state is reached. I think I should separately make this change. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/#review728 --- On 2011-01-12 22:44:50, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/ --- (Updated 2011-01-12 22:44:50) Review request for Default. Summary --- This is a request for reviewing the proposed changes to the MOESI CMP directory cache coherence protocol to make it conform with the new cache memory interface and changes to SLICC. Diffs - src/mem/protocol/MOESI_CMP_directory-L1cache.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-L2cache.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-dir.sm c6bc8fe81e79 src/mem/protocol/MOESI_CMP_directory-dma.sm c6bc8fe81e79 Diff: http://reviews.m5sim.org/r/359/diff Testing --- These changes have been tested using the Ruby random tester. The tester was used with -l = 1048576 and -n = 2. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
On 2011-01-13 08:33:49, Brad Beckmann wrote: I can't fully appreciate these latest changes without also seeing the updated .sm files, but overall this looks very inline with what we have been discussing over the past few days. I just have one basic question on why we need to overload doTransition, getState, and setState. Why can't we just have one version? Also a possibly related idea is can you insert asserts (!= NULL) for the tbe and cache_entry pointers before they are dereferenced in the generated code? Nilay Vaish wrote: Because Entry and/or TBE types might not be defined at all for particular controllers. Same holds true for the getState() and setState(). Also, getState() and setState() do not require the address, if the tbe and cache_entry have been properly set. After reading your comment, I realized that there is __huge__ mistake in this patch, which will not show up unless I test the generated code. I will have to change some parts again. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review727 --- On 2011-01-12 22:45:22, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:45:22) Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/protocol/RubySlicc_Types.sm c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh c6bc8fe81e79 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc c6bc8fe81e79 src/mem/ruby/system/CacheMemory.hh c6bc8fe81e79 src/mem/ruby/system/CacheMemory.cc c6bc8fe81e79 src/mem/ruby/system/TBETable.hh c6bc8fe81e79 src/mem/slicc/ast/ActionDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/FormalParamAST.py c6bc8fe81e79 src/mem/slicc/ast/FuncCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/IfStatementAST.py c6bc8fe81e79 src/mem/slicc/ast/InPortDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/IsValidPtrExprAST.py PRE-CREATION src/mem/slicc/ast/LocalVariableAST.py PRE-CREATION src/mem/slicc/ast/MethodCallExprAST.py c6bc8fe81e79 src/mem/slicc/ast/StaticCastAST.py c6bc8fe81e79 src/mem/slicc/ast/TypeDeclAST.py c6bc8fe81e79 src/mem/slicc/ast/__init__.py c6bc8fe81e79 src/mem/slicc/parser.py c6bc8fe81e79 src/mem/slicc/symbols/Func.py c6bc8fe81e79 src/mem/slicc/symbols/StateMachine.py c6bc8fe81e79 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory and MI protocols. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Updating MOESI CMP Directory protocol as per the new interface
Hi Nilay,
Yes, please add the OOD token. I believe that will come in handy when
developing new protocols. Don’t worry about separating out that
RequestorMachine change. It seems like just a few extra lines. Also I believe
the MOESI_CMP_Directory protocol did work correctly before your change, right?
If so, the RequestorMachine lines are related to the rest of the patch.
Brad
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Thursday, January 13, 2011 8:57 AM
To: Nilay Vaish; Default; Beckmann, Brad
Subject: Re: Review Request: Updating MOESI CMP Directory protocol as per the
new interface
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/359/
On January 13th, 2011, 8:48 a.m., Brad Beckmann wrote:
src/mem/protocol/MOESI_CMP_directory-L1cache.smhttp://reviews.m5sim.org/r/359/diff/8/?file=9537#file9537line159
(Diff revision 8)
155
if (L1DcacheMemory.isTagPresent(addr)) {
157
return L1Icache_entry;
So the assumption here is the L1IcacheMemory.lookup() call either returns the
L1I cache entry or NULL/OOD, correct? Does SLICC also support explicitly
passing back OOD?
Currently, SLICC does not have support for Out Of Domain (OOD) token. But I can
add that as I had done earlier. I am not sure if we actually need it.
On January 13th, 2011, 8:48 a.m., Brad Beckmann wrote:
src/mem/protocol/MOESI_CMP_directory-L1cache.smhttp://reviews.m5sim.org/r/359/diff/8/?file=9537#file9537line465
(Diff revision 8)
430
out_msg.RequestorMachine := MachineType:L1Cache;
This seems like an unrelated change, correct. However it is pretty minor, so
don't worry about it.
IIRC, this is necessary or else a certain panic state is reached. I think I
should separately make this change.
- Nilay
On January 12th, 2011, 10:44 p.m., Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.
Updated 2011-01-12 22:44:50
Description
This is a request for reviewing the proposed changes to the MOESI CMP directory
cache coherence protocol to make it conform with the new cache memory interface
and changes to SLICC.
Testing
These changes have been tested using the Ruby random tester. The tester was
used with -l = 1048576 and -n = 2.
Diffs
* src/mem/protocol/MOESI_CMP_directory-L1cache.sm (c6bc8fe81e79)
* src/mem/protocol/MOESI_CMP_directory-L2cache.sm (c6bc8fe81e79)
* src/mem/protocol/MOESI_CMP_directory-dir.sm (c6bc8fe81e79)
* src/mem/protocol/MOESI_CMP_directory-dma.sm (c6bc8fe81e79)
View Diffhttp://reviews.m5sim.org/r/359/diff/
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Checkpoint Tester Problems
Well I just realized that I don't have permissions to add new bug reports to Flyspray. My Flyspray user id is beckmabd if anyone would like to grant me permissions. Thanks! The checkpoint tester is a script located in util/checkpoint_test.py that Ali recently pointed me to. The script is commented well and fully describes what it does and how to run it. When I run a small test using X86_FS, the script identifies the following mismatches: Cmd: util/checkpoint-tester.py -i 2000 -- build/ALPHA_FS_MOESI_hammer/m5.debug configs/example/fs.py --script test/halt.sh Diff output: --- checkpoint-test/m5out/cpt.1/m5.cpt Wed Jan 12 14:59:28 2011 +++ checkpoint-test/test.4/cpt.1/m5.cpt Wed Jan 12 15:00:42 2011 @@ -10,20 +10,20 @@ so_state=2 locked=false _status=1 -instCnt=10 +instCnt=9 [system.cpu.xc.0] _status=0 -funcExeInst=16 +funcExeInst=15 quiesceEndTick=0 iplLast=0 iplLastTick=0 floatRegs.i=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -intRegs=549755813888 0 2097152 0 0 0 590336 0 0 0 0 0 0 0 0 0 0 2097208 380 0 0 0 0 2097189 0 0 0 0 0 0 0 0 133 0 0 0 0 0 0 +intRegs=549755813888 0 2097152 0 0 0 590336 0 0 0 0 0 0 0 0 0 18446743523955834880 2097182 380 0 0 0 0 2097189 0 0 0 0 0 0 0 0 133 0 0 0 0 0 0 _pc=2097202 -_npc=2097208 -_upc=1 -_nupc=2 +_npc=2097210 +_upc=0 +_nupc=1 regVal=3758096401 0 0 458752 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4294905840 1024 2 243392 0 1288 0 0 0 260 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1974748653749254 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1280 0 0 0 0 0 0 0 0 0 0 0 0 0 0 132609 0 0 0 0 67108864 0 0 0 0 0 16 8 16 16 16 16 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 483328 0 0 0 0 0 0 0 0 0 0 0 0 483328 0 0 0 0 983295 983295 983295 983295 983295 983295 65535 65535 23 65535 65535 983295 655 35 45768 43728 45768 45768 45768 45768 45952 0 45952 45952 45952 43976 45952 0 0 0 0 0 0 0 0 0 0 0 4 276095232 0 [system.cpu.tickEvent] By the way, could we add this test to the regression tester? Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Gabe Black Sent: Wednesday, January 12, 2011 4:42 PM To: M5 Developer List Subject: Re: [m5-dev] Checkpoint Tester Problems Flyspray would be good. We don't use it like we should, but it's probably the most appropriate place. I'm not familiar with the checkpoint tester. How does it work (link to the wiki would be fine), and what were the differences? Gabe Beckmann, Brad wrote: Hi All, While using the checkpoint tester script, I noticed that at least X86_FS with the atomic + classic memory system encounters differences in the checkpoint state. The good news is that none of the patches I have out for review add any more checkpoint differences, but we still should track down the existing bugs at some point. Should I use flyspray to document the bugs, or would you prefer me to document these bugs some other way? Thanks, Brad -- -- ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Checkpoint Tester Problems
On Thu, 13 Jan 2011 11:11:37 -0600, Beckmann, Brad brad.beckm...@amd.com wrote: Well I just realized that I don't have permissions to add new bug reports to Flyspray. My Flyspray user id is beckmabd if anyone would like to grant me permissions. Thanks! Done. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Style checker: Fix a couple bugs in style.py.
changeset 7107a2f3e53a in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=7107a2f3e53a description: Style checker: Fix a couple bugs in style.py. diffstat: util/style.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diffs (21 lines): diff -r c6bc8fe81e79 -r 7107a2f3e53a util/style.py --- a/util/style.py Wed Jan 12 11:52:29 2011 -0500 +++ b/util/style.py Thu Jan 13 12:30:18 2011 -0800 @@ -103,7 +103,7 @@ for i,line in enumerate(lines): if fixonly is None or i in fixonly: -line = fixwhite_line(line, tabsize) +line = fixwhite_line(line) print f, line, @@ -309,7 +309,7 @@ fixonly.add(i) if fixonly: -if prompt(fname, fixonly): +if prompt(fname, fixwhite, fixonly): return True def do_check_format(ui, repo, **args): ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Notification from M5 Bugs
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this: - Brad Beckmann (beckmabd) Attached to Project - M5 Bugs Summary - Checkpoint Tester Identifies Mismatches (Bugs) for X86_FS Task Type - Bug Category - ISA Support Status - Unconfirmed Assigned To - Operating System - Linux Severity - High Priority - Normal Reported Version - 2.0beta5 Due in Version - Due Date - Undecided Details - While using the checkpoint tester script, I noticed that X86_FS encounters differences in the checkpoint state. This problem exists for both atomic and timing mode, as well as classic and Ruby memory systems. A short test with the checkpoint tester script, will identify the problem: % util/checkpoint-tester.py -i 2000 -- build/ALPHA_FS_MOESI_hammer/m5.debug configs/example/fs.py --script test/halt.sh Identified differences in the checkpoint: --- checkpoint-test/m5out/cpt.1/m5.cpt Wed Jan 12 14:59:28 2011 +++ checkpoint-test/test.4/cpt.1/m5.cpt Wed Jan 12 15:00:42 2011 @@ -10,20 +10,20 @@ so_state=2 locked=false _status=1 -instCnt=10 +instCnt=9 [system.cpu.xc.0] _status=0 -funcExeInst=16 +funcExeInst=15 quiesceEndTick=0 iplLast=0 iplLastTick=0 floatRegs.i=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -intRegs=549755813888 0 2097152 0 0 0 590336 0 0 0 0 0 0 0 0 0 0 2097208 380 0 0 0 0 2097189 0 0 0 0 0 0 0 0 133 0 0 0 0 0 0 +intRegs=549755813888 0 2097152 0 0 0 590336 0 0 0 0 0 0 0 0 0 +18446743523955834880 2097182 380 0 0 0 0 2097189 0 0 0 0 0 0 0 0 133 0 0 0 0 0 0 _pc=2097202 -_npc=2097208 -_upc=1 -_nupc=2 +_npc=2097210 +_upc=0 +_nupc=1 regVal=3758096401 0 0 458752 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4294905840 1024 2 243392 0 1288 0 0 0 260 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1974748653749254 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1280 0 0 0 0 0 0 0 0 0 0 0 0 0 0 132609 0 0 0 0 67108864 0 0 0 0 0 16 8 16 16 16 16 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 483328 0 0 0 0 0 0 0 0 0 0 0 0 483328 0 0 0 0 983295 983295 983295 983295 983295 983295 65535 65535 23 65535 65535 983295 655 35 45768 43728 45768 45768 45768 45768 45952 0 45952 45952 45952 43976 45952 0 0 0 0 0 0 0 0 0 0 0 4 276095232 0 [system.cpu.tickEvent] More information can be found at the following URL: http://www.m5sim.org/flyspray/task/337 You are receiving this message because you have requested it from the Flyspray bugtracking system. You can be removed from future notifications by visiting the URL shown above. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: time: improve time datastructure
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/425/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- time: improve time datastructure Use posix clock functions (and librt) if it is available. Inline a bunch of functions and implement more operators. I needed something like this for some timing code that I needed, so I just did it right since I assume that Gabe could use this to better his patch. Diffs - SConstruct de7601e6e19d src/base/time.hh de7601e6e19d src/base/time.cc de7601e6e19d src/sim/stat_control.cc de7601e6e19d Diff: http://reviews.m5sim.org/r/425/diff Testing --- quick regressions pass Thanks, Nathan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Fixes MESI CMP directory protocol
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/#review734 --- I am going to commit this patch soon. Along with the patch, I am also thinking of updating the reference outputs for the four regression tests done on MESI_CMP_directory. Currently, 60.rubytest fails on running the tests. - Nilay On 2011-01-10 11:48:16, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/ --- (Updated 2011-01-10 11:48:16) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Fixes MESI CMP directory protocol The current implementation of MESI CMP directory protocol is broken. This patch, from Arkaprava Basu, fixes the protocol. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm c06505ff551e src/mem/protocol/MESI_CMP_directory-L2cache.sm c06505ff551e Diff: http://reviews.m5sim.org/r/420/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Fixes MESI CMP directory protocol
changeset 8f37a23e02d7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8f37a23e02d7
description:
Ruby: Fixes MESI CMP directory protocol
The current implementation of MESI CMP directory protocol is broken.
This patch, from Arkaprava Basu, fixes the protocol.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 25 +++--
src/mem/protocol/MESI_CMP_directory-L2cache.sm | 25 -
2 files changed, 35 insertions(+), 15 deletions(-)
diffs (123 lines):
diff -r 7107a2f3e53a -r 8f37a23e02d7
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smThu Jan 13 12:30:18
2011 -0800
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smThu Jan 13 22:17:11
2011 -0600
@@ -70,6 +70,7 @@
M_I, desc=L1 replacing, waiting for ACK;
E_I, desc=L1 replacing, waiting for ACK;
+SINK_WB_ACK, desc=This is to sink WB_Acks from L2;
}
@@ -749,9 +750,8 @@
l_popRequestQueue;
}
- transition(M_I, Inv, I) {
+ transition(M_I, Inv, SINK_WB_ACK) {
ft_sendDataToL2_fromTBE;
-s_deallocateTBE;
l_popRequestQueue;
}
@@ -766,16 +766,14 @@
l_popRequestQueue;
}
- transition(M_I, Fwd_GETX, I) {
+ transition(M_I, Fwd_GETX, SINK_WB_ACK) {
dt_sendDataToRequestor_fromTBE;
-s_deallocateTBE;
l_popRequestQueue;
}
- transition(M_I, {Fwd_GETS, Fwd_GET_INSTR}, I) {
+ transition(M_I, {Fwd_GETS, Fwd_GET_INSTR}, SINK_WB_ACK) {
dt_sendDataToRequestor_fromTBE;
d2t_sendDataToL2_fromTBE;
-s_deallocateTBE;
l_popRequestQueue;
}
@@ -865,6 +863,21 @@
s_deallocateTBE;
o_popIncomingResponseQueue;
}
+
+ transition(SINK_WB_ACK, {Load, Store, Ifetch, L1_Replacement}){
+ z_recycleMandatoryQueue;
+
+ }
+
+ transition(SINK_WB_ACK, Inv){
+fi_sendInvAck;
+l_popRequestQueue;
+ }
+
+ transition(SINK_WB_ACK, WB_Ack){
+s_deallocateTBE;
+o_popIncomingResponseQueue;
+ }
}
diff -r 7107a2f3e53a -r 8f37a23e02d7
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smThu Jan 13 12:30:18
2011 -0800
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smThu Jan 13 22:17:11
2011 -0600
@@ -734,11 +734,13 @@
// BASE STATE - I
// Transitions from I (Idle)
- transition({NP, IS, ISS, IM, SS, M, M_I, MT_I, MCT_I, I_I, S_I, SS_MB, M_MB,
MT_IIB, MT_IB, MT_SB}, L1_PUTX) {
+ transition({NP, IS, ISS, IM, SS, M, M_I, I_I, S_I, M_MB, MT_IB, MT_SB},
L1_PUTX) {
+t_sendWBAck;
jj_popL1RequestQueue;
}
- transition({NP, SS, M, MT, M_I, MT_I, MCT_I, I_I, S_I, IS, ISS, IM, SS_MB,
M_MB, MT_IIB, MT_IB, MT_SB}, L1_PUTX_old) {
+ transition({NP, SS, M, MT, M_I, I_I, S_I, IS, ISS, IM, M_MB, MT_IB, MT_SB},
L1_PUTX_old) {
+t_sendWBAck;
jj_popL1RequestQueue;
}
@@ -968,6 +970,10 @@
mmu_markExclusiveFromUnblock;
k_popUnblockQueue;
}
+
+ transition(MT_IIB, {L1_PUTX, L1_PUTX_old}){
+zz_recycleL1RequestQueue;
+ }
transition(MT_IIB, Unblock, MT_IB) {
nnu_addSharerFromUnblock;
@@ -1015,21 +1021,22 @@
o_popIncomingResponseQueue;
}
+ transition(MCT_I, {L1_PUTX, L1_PUTX_old}){
+zz_recycleL1RequestQueue;
+ }
+
// L1 never changed Dirty data
transition(MT_I, Ack_all, M_I) {
ct_exclusiveReplacementFromTBE;
o_popIncomingResponseQueue;
}
-
- // drop this because L1 will send data again
- // the reason we don't accept is that the request virtual network may be
completely backed up
- // transition(MT_I, L1_PUTX) {
- // jj_popL1RequestQueue;
- //}
+ transition(MT_I, {L1_PUTX, L1_PUTX_old}){
+zz_recycleL1RequestQueue;
+ }
// possible race between unblock and immediate replacement
- transition(MT_MB, {L1_PUTX, L1_PUTX_old}) {
+ transition({MT_MB,SS_MB}, {L1_PUTX, L1_PUTX_old}) {
zz_recycleL1RequestQueue;
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Regression Tests: Update the output for MESI_CM...
changeset a82dcad2bc18 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=a82dcad2bc18 description: Regression Tests: Update the output for MESI_CMP_directory This patch updates the output for regression tests that are carried out on MESI_CMP_directory protocol. The changes made to the protocol in order to remove the bugs present result in regression failure for the 60.rubytest. Since the earlier protocol was incorrect, so we certainly cannot relay on the earlier reference output. Hence, the update. diffstat: tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/config.ini | 54 +- tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/ruby.stats | 63 +- tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/simout |8 +- tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/stats.txt |8 +- tests/quick/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/config.ini | 54 +- tests/quick/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/ruby.stats | 61 +- tests/quick/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/simout |8 +- tests/quick/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/stats.txt |8 +- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/config.ini | 11 +- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/ruby.stats | 37 +- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/simout |8 +- tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/stats.txt |6 +- tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/config.ini | 57 +- tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/ruby.stats | 399 + tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/simout | 10 +- tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/stats.txt | 10 +- 16 files changed, 399 insertions(+), 403 deletions(-) diffs (truncated from 1485 to 300 lines): diff -r 8f37a23e02d7 -r a82dcad2bc18 tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/config.ini --- a/tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/config.ini Thu Jan 13 22:17:11 2011 -0600 +++ b/tests/quick/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/config.ini Thu Jan 13 22:48:03 2011 -0600 @@ -32,8 +32,8 @@ system=system tracer=system.cpu.tracer workload=system.cpu.workload -dcache_port=system.l1_cntrl0.sequencer.port[1] -icache_port=system.l1_cntrl0.sequencer.port[0] +dcache_port=system.ruby.cpu_ruby_ports.port[1] +icache_port=system.ruby.cpu_ruby_ports.port[0] [system.cpu.dtb] type=AlphaTLB @@ -109,34 +109,21 @@ [system.l1_cntrl0] type=L1Cache_Controller -children=sequencer -L1DcacheMemory=system.l1_cntrl0.sequencer.dcache -L1IcacheMemory=system.l1_cntrl0.sequencer.icache +children=L1DcacheMemory L1IcacheMemory +L1DcacheMemory=system.l1_cntrl0.L1DcacheMemory +L1IcacheMemory=system.l1_cntrl0.L1IcacheMemory buffer_size=0 l1_request_latency=2 l1_response_latency=2 l2_select_num_bits=0 number_of_TBEs=256 recycle_latency=10 -sequencer=system.l1_cntrl0.sequencer +sequencer=system.ruby.cpu_ruby_ports to_l2_latency=1 transitions_per_cycle=32 version=0 -[system.l1_cntrl0.sequencer] -type=RubySequencer -children=dcache icache -dcache=system.l1_cntrl0.sequencer.dcache -deadlock_threshold=50 -icache=system.l1_cntrl0.sequencer.icache -max_outstanding_requests=16 -physmem=system.physmem -using_ruby_tester=false -version=0 -physMemPort=system.physmem.port[0] -port=system.cpu.icache_port system.cpu.dcache_port - -[system.l1_cntrl0.sequencer.dcache] +[system.l1_cntrl0.L1DcacheMemory] type=RubyCache assoc=2 latency=3 @@ -144,7 +131,7 @@ size=256 start_index_bit=6 -[system.l1_cntrl0.sequencer.icache] +[system.l1_cntrl0.L1IcacheMemory] type=RubyCache assoc=2 latency=3 @@ -181,14 +168,13 @@ null=false range=0:134217727 zero=false -port=system.l1_cntrl0.sequencer.physMemPort +port=system.ruby.cpu_ruby_ports.physMemPort [system.ruby] type=RubySystem -children=debug network profiler tracer +children=cpu_ruby_ports network profiler tracer block_size_bytes=64 clock=1 -debug=system.ruby.debug mem_size=134217728 network=system.ruby.network no_mem_vec=false @@ -198,13 +184,17 @@ stats_filename=ruby.stats tracer=system.ruby.tracer -[system.ruby.debug] -type=RubyDebug -filter_string=none -output_filename=none -protocol_trace=false -start_time=1 -verbosity_string=none +[system.ruby.cpu_ruby_ports] +type=RubySequencer +dcache=system.l1_cntrl0.L1DcacheMemory +deadlock_threshold=50 +icache=system.l1_cntrl0.L1IcacheMemory +max_outstanding_requests=16
Re: [m5-dev] Review Request: time: improve time datastructure
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/425/#review735 --- Looks pretty good, and thanks! src/base/time.hh http://reviews.m5sim.org/r/425/#comment997 Maybe define a constant for this? It's hard to count out that many zeros reliably. src/base/time.cc http://reviews.m5sim.org/r/425/#comment998 Are you sure you want to use CLOCK_MONOTONIC here? My book says this is in reference to an unspecified point in the past and is for a clock source that can't jump around if, for instance, somebody updates the system time. There isn't necessarily anything wrong with that, but I don't think that's what gettimeofday does. If you want to really have a gettimeofday substitute, I think you want to use CLOCK_REALTIME, although that's mostly just a relatively uninformed interpretation of what's in the book and may be wrong. - Gabe On 2011-01-13 19:43:31, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/425/ --- (Updated 2011-01-13 19:43:31) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- time: improve time datastructure Use posix clock functions (and librt) if it is available. Inline a bunch of functions and implement more operators. I needed something like this for some timing code that I needed, so I just did it right since I assume that Gabe could use this to better his patch. Diffs - SConstruct de7601e6e19d src/base/time.hh de7601e6e19d src/base/time.cc de7601e6e19d src/sim/stat_control.cc de7601e6e19d Diff: http://reviews.m5sim.org/r/425/diff Testing --- quick regressions pass Thanks, Nathan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Fixes MESI CMP directory protocol
On 2011-01-12 17:04:00, Nilay Vaish wrote: Nilay Vaish wrote: I don't know why the comment went missing. I'll post the question again. I think the states MT_SB and MT_IB are not required. In fact, I am not sure why unblock messages have to be sent out. Brad Beckmann wrote: I'm confused. I just asked for the commented out transition to be deleted. I'm not sure what comment you're referring to. When you say the unblock messages, I assume you are referring to the WB_acks, right? I believe the acks need to be sent out because you want to block the L1 until it receives the acks. Otherwise, sinking random writeback acks can be confusing and lead to several bugs, which currently this protocol definitely has. There may be further optimizations we can make, such as removing the MT_SM and MT_IB states, as well as possibly combining L1_PUTX and L1_PUTX_old events. However, I suggest making those optimizations in a separate patch. In my opinion, right now the number one priority is to fix this protocol as soon as possible. Otherwise when checked in, my series of patches will expose several bugs in the protocol and thus break the regression tester. Arkaprava Basu wrote: I am confused too. I think Nilay is talking about UNBLOCK messages that are sent when there is exclusive owner change for a cache block or a cache block is doing a M-S transition. In general, directory cache coherence protocols uses blocking states (in this protocol the states whose name ends with B) to constrain amount of races as blocking helps in serializing requests. In theory you can get rid of UNBLOCKS through more transient states and/or through NACKs. For this particular case that Nilay mentioned here, the MT_SB and MT_IB states are used to make sure modified data is not lost when there is coherence permission down-gradation at the exclusive owner's cache due to request from other cores. I also totally agree with Brad that the purpose of this patch is to fix a broken protocol not to do optimization. And unlike MOESI_CMP_directory, this protocol is targeted to work as simple baseline protocol than highly optimized one. Thanks Arka Arka's right, I was talking about those very 'UNBLOCK' messages. I agree this discussion is unrelated to the changes necessary for fixing the protocol. When I fixed the protocol, I was trying to reason why those states might have been added. I think the state MT_IIB makes sure that the L2 cache receives the modified data from the L1 cache. Once the data has been received, the L2 cache state should directly move to SS. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/#review723 --- On 2011-01-10 11:48:16, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/ --- (Updated 2011-01-10 11:48:16) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Fixes MESI CMP directory protocol The current implementation of MESI CMP directory protocol is broken. This patch, from Arkaprava Basu, fixes the protocol. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm c06505ff551e src/mem/protocol/MESI_CMP_directory-L2cache.sm c06505ff551e Diff: http://reviews.m5sim.org/r/420/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: time: improve time datastructure
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/425/#review737 --- src/base/time.hh http://reviews.m5sim.org/r/425/#comment1000 heh, but the constant will have that many zeroes too! I could use 1000*1000*1000 if you prefer. I'll figure something out. src/base/time.cc http://reviews.m5sim.org/r/425/#comment999 Oh, I used whatever you used. CLOCK_REALTIME is fine too, though I guess I never really cared about the fact that I could print the time as a string. I am generally more interested in using it for measuring how long things take. I hesitate to make this code more complex, but I guess I could create a set_wallclock() func that does one and a set_timer() that does the other. - Nathan On 2011-01-13 19:43:31, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/425/ --- (Updated 2011-01-13 19:43:31) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- time: improve time datastructure Use posix clock functions (and librt) if it is available. Inline a bunch of functions and implement more operators. I needed something like this for some timing code that I needed, so I just did it right since I assume that Gabe could use this to better his patch. Diffs - SConstruct de7601e6e19d src/base/time.hh de7601e6e19d src/base/time.cc de7601e6e19d src/sim/stat_control.cc de7601e6e19d Diff: http://reviews.m5sim.org/r/425/diff Testing --- quick regressions pass Thanks, Nathan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
