Re: [gem5-dev] Review Request: O3: Create a pipeline activity viewer for the O3 CPU model.
That does look nice. It can be a lot of work slogging through O3 trace output to figure out what's going on, and I expect this to make that a lot easier. I glanced through the code and didn't see anything particularly objectionable, although I wouldn't necessarily consider that a thorough review :-P. Gabe On 05/26/11 22:20, Steve Reinhardt wrote: Cool! I haven't looked at the code yet, but the output looks nice. Steve On Thu, May 26, 2011 at 8:19 PM, Ali Saidi sa...@umich.edu wrote: Anyone that is curious what this looks like... lets try the picture again... Ali On May 26, 2011, at 9:19 PM, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/721/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- O3: Create a pipeline activity viewer for the O3 CPU model. Implement a pipeline activity viewer as a python script (util/o3-pipeview.py) and modified O3 code base to support an extra trace flag (O3PipeView) for generating traces to be used as inputs by the tool. Diffs - src/cpu/SConscript 3f37cc5d25bc src/cpu/o3/commit_impl.hh 3f37cc5d25bc src/cpu/o3/decode_impl.hh 3f37cc5d25bc src/cpu/o3/dyn_inst.hh 3f37cc5d25bc src/cpu/o3/fetch_impl.hh 3f37cc5d25bc src/cpu/o3/iew_impl.hh 3f37cc5d25bc src/cpu/o3/inst_queue_impl.hh 3f37cc5d25bc src/cpu/o3/rename_impl.hh 3f37cc5d25bc util/o3-pipeview.py PRE-CREATION Diff: http://reviews.m5sim.org/r/721/diff Testing --- Thanks, Ali ___ 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 ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/#review1262 --- What does Self.all do? What is it for? You have one use in the change so I have a basic idea, but it would be helpful to know the specifics. - Gabe On 2011-05-26 19:17:18, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/ --- (Updated 2011-05-26 19:17:18) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Config: Add support for a Self.all proxy object Diffs - src/python/m5/SimObject.py 3f37cc5d25bc src/python/m5/params.py 3f37cc5d25bc src/python/m5/proxy.py 3f37cc5d25bc src/sim/System.py 3f37cc5d25bc Diff: http://reviews.m5sim.org/r/720/diff Testing --- Thanks, Ali ___ 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
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/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-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/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-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/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-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/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-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. *
Re: [gem5-dev] registerThreadContext
For #1 and #4, these are pretty much the same right? The contextID is really all possible sharers rather then just threadContext. Seems like you should keep the meaning of contextID as it pertains to thread and then generate a sharerID that would be a superset of the contextIDs. Objects that dont have an explicit thread but are sharing can just offset off the highest contextID. would that make sense? For #2, I'd prefer not to further complicate that ThreadContext interface. For #3, I started on that patch but thought I would have to work after Lisa committed her changes and I envisioned having a system where you could either manually state the sharers or the system would figure it out for you. Figuring this out automatically all the time is an acceptable solution ... :) I thought the easiest way would be to use the port connections to traverse the system since something is already done for the snoop Port registration.The only trick would be for CPUs with multiple threads you need to ask out how many contexts it's going to share. On Wed, May 25, 2011 at 1:57 PM, nathan binkert n...@binkert.org wrote: Hi Everyone, I'm trying to work with Lisa's patch to convert cache vector statistics to record data on a per-context basis where context is anything that executes instructions. (Some things were per-CPU and some things were per-thread and neither make sense). She added a parameter to each cache called num_sharing_contexts that would tell the cache how many contexts could send that cache a request. Indexing into the vector was done by taking req-contextId and doing a modulo with num_sharing_contexts. DMA controllers would all get stuck in a special additional bin. There are two things I don't like about this scheme. First, configuring the parameter is a pain in the butt. Second, it's hard to compare statistics from two different caches because their indexes are different. Third, you can't separate out DMA controllers. So, what I did was get rid fo num_sharing_contexts and use the number of contexts that were registered with the system with registerThreadContext (adding one for the DMA controllers). This works for the common case, but doesn't work with the MemTester because the memtester doesn't have a thread context to register. 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. Thoughts? Ideas? Nate ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev -- - Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] registerThreadContext
For #1 and #4, these are pretty much the same right? The contextID is really all possible sharers rather then just threadContext. Seems like you should keep the meaning of contextID as it pertains to thread and then generate a sharerID that would be a superset of the contextIDs. Objects that dont have an explicit thread but are sharing can just offset off the highest contextID. would that make sense? Yeah, I guess #1 and #4 were more or less the same as written. What I'd really like to know is if we should have just one ID or two. I'd personally rather stick with one. Maybe we just call it memoryAccessID or sharerID and the contexts would just use that. I'd really rather avoid adding IDs for the sake of adding IDs, but if it really makes sense, then we should do it. For #2, I'd prefer not to further complicate that ThreadContext interface. I'm not sure that it would complicate things much. The idea is to just put the things that are for memory requests into a base class and have thread context derive from that. So, not adding stuff, just splitting the class into two parts. I thought the easiest way would be to use the port connections to traverse the system since something is already done for the snoop Port registration.The only trick would be for CPUs with multiple threads you need to ask out how many contexts it's going to share. Yeah, it is doable. It would probably be nice to have a routine that is just designed to traverse the memory hierarchy and call a member function on every object in the hierarchy. I think registering with the system gets the same effect and is potentially simpler. Nate ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] registerThreadContext
I'd really like to know is if we should have just one ID or two. I'd personally rather stick with one. Maybe we just call it memoryAccessID or sharerID memoryAccessID sounds like the right term here. I'm not sure that it would complicate things much. The idea is to just put the things that are for memory requests into a base class and have thread context derive from that. So, not adding stuff, just splitting the class into two parts. I see, that's not too bad then. I thought the easiest way would be to use the port connections to traverse the system since something is already done for the snoop Port registration.The only trick would be for CPUs with multiple threads you need to ask out how many contexts it's going to share. Yeah, it is doable. It would probably be nice to have a routine that is just designed to traverse the memory hierarchy and call a member function on every object in the hierarchy. I think registering with the system gets the same effect and is potentially simpler. That routine would be useful I agree. What I ran into when I started this is you can't necessarily just sum up values though because things share the same bus. Thus, if you ask an icache and a dcache for num sharers then you get back 1 both time, but you can't sum those. So the traversal algorithm has to be smart enough to count unique sharers (stl set?) on a bus and then pass that value down the hierarchy for it to work right. -- - Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-05-27 11:41:44.345753) Review request for Default. Summary (updated) --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. The patch has been updated to set permissions for all the five protocols. All the protocols compile and clears 1 loads. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MI_example-cache.sm dda2a88eb7c4 src/mem/protocol/MI_example-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-dir.sm dda2a88eb7c4 src/mem/protocol/RubySlicc_Types.sm dda2a88eb7c4 src/mem/slicc/ast/MethodCallExprAST.py dda2a88eb7c4 src/mem/slicc/symbols/StateMachine.py dda2a88eb7c4 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Enabled instruction fetch pipelining.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/718/#review1263 --- I think this type of change is necessary for reasonable performance, but the implementation here does pose some issues for any ISA that uses micro-coded instructions (and faults on one). Additionally, if you look at small issue width CPUs this doesn't generally solve the problem. We've re-worked this change to fix the correctness issue and as soon as it goes through a battery of internal tests we can post it for review if that works for everyone. - Ali On 2011-05-24 12:01:29, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/718/ --- (Updated 2011-05-24 12:01:29) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Enabled instruction fetch pipelining. This patch is from one of our co-ops who has since finished her term, Yasuko Watanabe. I don't personally know much about it. In the end, I'll push in her name. Thanks. Diffs - src/cpu/o3/fetch.hh 54a65799e4c1 src/cpu/o3/fetch_impl.hh 54a65799e4c1 Diff: http://reviews.m5sim.org/r/718/diff Testing --- Thanks, Lisa ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/#review1265 --- src/python/m5/SimObject.py http://reviews.m5sim.org/r/720/#comment1742 Does this do what you want? It doesn't seem like it would recurse down the tree and find all nodes that match (or does it?) src/python/m5/params.py http://reviews.m5sim.org/r/720/#comment1743 what exactly is this doing? Also, what happens if val is of length 2 and the first element is a list or tuple? Seems like an error condition or you're doing something wrong. src/python/m5/proxy.py http://reviews.m5sim.org/r/720/#comment1744 Seems like Mr Doxygen should be documenting this file a bit better :) Also, what does Parent.all do? It'd be nice if you described Self.all and Parent.all in this file. - Nathan On 2011-05-26 19:17:18, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/ --- (Updated 2011-05-26 19:17:18) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Config: Add support for a Self.all proxy object Diffs - src/python/m5/SimObject.py 3f37cc5d25bc src/python/m5/params.py 3f37cc5d25bc src/python/m5/proxy.py 3f37cc5d25bc src/sim/System.py 3f37cc5d25bc Diff: http://reviews.m5sim.org/r/720/diff Testing --- Thanks, Ali ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object
On 2011-05-26 23:29:05, Gabe Black wrote: What does Self.all do? What is it for? You have one use in the change so I have a basic idea, but it would be helpful to know the specifics. Ali Saidi wrote: It's similar to Parent.any in that it traverses the object hierarchy and finds all (as opposed to one) objects that are of a certain type. As you see from the memories example, the system object can have a pointer to all PhysicalMemory objects that belong to that system. The reason to add something like this, is to have a generic way to prevent speculation from touching I/O. It's possible for a speculative instruction fetch to sneak out of the CPU if the wrong 10 things all happen an once and with this another change can prevent that (will post soon). It's not as simple as just not fetching from non-cacheable memory, since most architectures start their processors in some kind of caches disabled, tlb should only issue non-cachable transaction state. So if the real machine is using speculative execution in this cache-disable mode, how does it avoid touching I/O locations? - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/#review1262 --- On 2011-05-26 19:17:18, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/720/ --- (Updated 2011-05-26 19:17:18) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Config: Add support for a Self.all proxy object Diffs - src/python/m5/SimObject.py 3f37cc5d25bc src/python/m5/params.py 3f37cc5d25bc src/python/m5/proxy.py 3f37cc5d25bc src/sim/System.py 3f37cc5d25bc Diff: http://reviews.m5sim.org/r/720/diff Testing --- Thanks, Ali ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
