[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** [build/X86_SE/m5.fast.unstripped] Error 1 * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing
Re: [m5-dev] files in the root of the tree
I decided not to mention it before, but we also have an AUTHORS file which is a little out of date. For instance, I don't think it includes the contribution of Power support. I like being listed in that file and I'm sure other people like the recognition as well, but the decision of what and who to include is a bit arbitrary and could be considered unfair. The repository history will have some of that information and is more unbiased. I think we should get rid of that file, but only if the other people on it are ok with it too. Gabe On 02/13/11 21:03, Gabe Black wrote: I was looking at the structure of the tree, and a few of the files at the root are a little stale. The LICENSE file doesn't list any of the other institutions that have a files in the tree and is up to 2008 instead of 2011. The README and RELEASE_NOTES files reflect beta 6 and are also dated 2008. The README file could probably be just touched up and still be useful. RELEASE_NOTES can probably be deleted outright since we don't have releases any more. As for the LICENSE file, I think we should create a license or LICENSE directory and put one file in it for each license in use for M5. Then, in each file that needs a license, we could put something like Copyright Foo Inc., license in LICENSE/foo.txt. This is probably going to be a bit controversial, but it would help tidy up small files that are 50% license text. Gabe ___ 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] Review Request: Util: Get rid of the make_release.py script.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/488/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Util: Get rid of the make_release.py script. Since we're not doing releases any more we don't really need this script. If we need it in the future, we can resurrect it from the history. Diffs - util/make_release.py e8f4bb35dca9 Diff: http://reviews.m5sim.org/r/488/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
But I need to find the point to log order of completion of loads and stores in the LSQ (between LSQ and L1 cache), to check the effect of that change. I was observing inside LSQUnitImpl::completeDataAccess(PacketPtr pkt). But the order observed doesn't look like the expected. Looks like you are going to have to check the TSO (?) semantics here. Whose to say that if you issue a # of memory accesses in a particular order, that they finish in a particular order? Isn't caching (and locality of your memory accesses) going to determine this? Is it not OK that the memory accesses are sent to the memory system in a certain order but arent necessarily completed in a certain order? Again, you'll need to check the TSO or whatever constraints you are trying to enforce for that case. -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Util: Get rid of the make_release.py script.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/488/#review861 --- Fine with me, though I'd like a second opinion. (I would like a second opinion on the RELEASE_NOTES change). - Nathan On 2011-02-14 01:22:11, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/488/ --- (Updated 2011-02-14 01:22:11) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Util: Get rid of the make_release.py script. Since we're not doing releases any more we don't really need this script. If we need it in the future, we can resurrect it from the history. Diffs - util/make_release.py e8f4bb35dca9 Diff: http://reviews.m5sim.org/r/488/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Info: Clean up some info files.
On 2011-02-14 06:48:03, Nathan Binkert wrote: LICENSE, line 1 http://reviews.m5sim.org/r/486/diff/1/?file=10325#file10325line1 Should we put everyone in here? (And all licenses?) I think we should as most of the license text says in, source and binary forms. The LICENSE file gets sucked into the simulator as a string and can be printed with a command line parameter, so it probably should have all of them. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/486/#review860 --- On 2011-02-13 23:47:40, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/486/ --- (Updated 2011-02-13 23:47:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Info: Clean up some info files. Get rid of RELEASE_NOTES since we no longer do releases, update some of the information in README, and update the date in LICENSE. Diffs - LICENSE e8f4bb35dca9 README e8f4bb35dca9 RELEASE_NOTES e8f4bb35dca9 src/SConscript e8f4bb35dca9 src/python/m5/main.py e8f4bb35dca9 Diff: http://reviews.m5sim.org/r/486/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Alpha: Import the alpha-system files into the m5 repository.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/487/#review863 --- I think you can preserve the history by doing a hg pull -f path to alpha-system, although before you do you should do an hg mv to move all the file into system/alpha. - Ali On 2011-02-13 23:53:32, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/487/ --- (Updated 2011-02-13 23:53:32) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Alpha: Import the alpha-system files into the m5 repository. Bring the alpha-system files into the M5 repository alongside the ARM files. This unfortunately does not bring along the old history. Diffs - system/alpha/console/Makefile PRE-CREATION system/alpha/console/console.c PRE-CREATION system/alpha/console/dbmentry.S PRE-CREATION system/alpha/console/paljtokern.S PRE-CREATION system/alpha/console/paljtoslave.S PRE-CREATION system/alpha/console/printf.c PRE-CREATION system/alpha/h/cserve.h PRE-CREATION system/alpha/h/dc21164FromGasSources.h PRE-CREATION system/alpha/h/ev5_alpha_defs.h PRE-CREATION system/alpha/h/ev5_defs.h PRE-CREATION system/alpha/h/ev5_impure.h PRE-CREATION system/alpha/h/ev5_osfalpha_defs.h PRE-CREATION system/alpha/h/ev5_paldef.h PRE-CREATION system/alpha/h/fromHudsonMacros.h PRE-CREATION system/alpha/h/fromHudsonOsf.h PRE-CREATION system/alpha/h/rpb.h PRE-CREATION system/alpha/h/tlaser.h PRE-CREATION system/alpha/palcode/Makefile PRE-CREATION system/alpha/palcode/osfpal.S PRE-CREATION system/alpha/palcode/platform.S PRE-CREATION Diff: http://reviews.m5sim.org/r/487/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
Brad, this patch to affects the number of ticks required for performing a particular number of loads. I don't expect such a thing to happen. Do you? -- Nilay On Wed, 9 Feb 2011, Brad Beckmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/#review839 --- Overall, this looks great. A pretty simple change that offers significant speedup. I just have one question about the parameters to storeEventInfo. src/mem/ruby/buffers/MessageBuffer.cc http://reviews.m5sim.org/r/328/#comment1196 Is there a reason why you want to pass the message pointer instead of just the vnet id? src/mem/ruby/network/simple/PerfectSwitch.cc http://reviews.m5sim.org/r/328/#comment1197 It seems that you could remove the safe_cast and message pointer dereference if you passed in the vnet id as the first parameter. Am I missing something? - Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
I realized the reason for this. Actually, the wakeup function performs a round-robin scheduling between the incoming links. This code had moved inside the a new if condition that has been introduced in the code. I have moved that code before the if condition so that the timing remains same as before. -- Nilay On Mon, 14 Feb 2011, Nilay Vaish wrote: Brad, this patch to affects the number of ticks required for performing a particular number of loads. I don't expect such a thing to happen. Do you? -- Nilay On Wed, 9 Feb 2011, Brad Beckmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/#review839 --- Overall, this looks great. A pretty simple change that offers significant speedup. I just have one question about the parameters to storeEventInfo. src/mem/ruby/buffers/MessageBuffer.cc http://reviews.m5sim.org/r/328/#comment1196 Is there a reason why you want to pass the message pointer instead of just the vnet id? src/mem/ruby/network/simple/PerfectSwitch.cc http://reviews.m5sim.org/r/328/#comment1197 It seems that you could remove the safe_cast and message pointer dereference if you passed in the vnet id as the first parameter. Am I missing something? - Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Info: Clean up some info files.
On 2011-02-14 06:48:03, Nathan Binkert wrote: LICENSE, line 1 http://reviews.m5sim.org/r/486/diff/1/?file=10325#file10325line1 Should we put everyone in here? (And all licenses?) Ali Saidi wrote: I think we should as most of the license text says in, source and binary forms. The LICENSE file gets sucked into the simulator as a string and can be printed with a command line parameter, so it probably should have all of them. That would tie back into my idea of having a directory for all the different licenses which could then all be sucked in and output together. I didn't want to mess with the license stuff too much in this change since IANAL and I'm sure there will be some diversity of opinion here. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/486/#review860 --- On 2011-02-13 23:47:40, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/486/ --- (Updated 2011-02-13 23:47:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Info: Clean up some info files. Get rid of RELEASE_NOTES since we no longer do releases, update some of the information in README, and update the date in LICENSE. Diffs - LICENSE e8f4bb35dca9 README e8f4bb35dca9 RELEASE_NOTES e8f4bb35dca9 src/SConscript e8f4bb35dca9 src/python/m5/main.py e8f4bb35dca9 Diff: http://reviews.m5sim.org/r/486/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: naming for RubyNetwork dprintfs
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/489/#review865 --- Seems like a reasonable idea to me, but a Ruby person has to agree. src/mem/ruby/buffers/MessageBuffer.cc http://reviews.m5sim.org/r/489/#comment1229 If you're going to change this, you should change it to a ccprintf :) Totally not necessary if you don't feel like it. src/mem/ruby/network/simple/PerfectSwitch.hh http://reviews.m5sim.org/r/489/#comment1233 probably not worth storing m_name. You may as well just generate it in name(). src/mem/ruby/network/simple/PerfectSwitch.cc http://reviews.m5sim.org/r/489/#comment1230 IMHO, You may as well just stick this in the header. src/mem/ruby/network/simple/Throttle.hh http://reviews.m5sim.org/r/489/#comment1231 Please put system headers above M5 headers. src/mem/ruby/network/simple/Throttle.hh http://reviews.m5sim.org/r/489/#comment1234 Same as above. src/mem/ruby/network/simple/Throttle.cc http://reviews.m5sim.org/r/489/#comment1232 header file. - Nathan On 2011-02-14 13:32:56, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/489/ --- (Updated 2011-02-14 13:32:56) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: naming for RubyNetwork dprintfs add a name() to the Ruby Throttle PerfectSwitch objects so that the debug output isn't littered w/global: everywhere and it also negates the need to put the name of the object in every dprintf in the form of DPRINTF(RubyNetwork, Switch %i: msg). This also makes debug output easier to read and conforms to how the other objects are handled in M5 for debugging ... Additionally, knock off an extra newline on a message buffer print Diffs - src/mem/ruby/buffers/MessageBuffer.cc 68a5b8bba293 src/mem/ruby/network/simple/PerfectSwitch.hh 68a5b8bba293 src/mem/ruby/network/simple/PerfectSwitch.cc 68a5b8bba293 src/mem/ruby/network/simple/Throttle.hh 68a5b8bba293 src/mem/ruby/network/simple/Throttle.cc 68a5b8bba293 Diff: http://reviews.m5sim.org/r/489/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Improve Change PerfectSwitch's wakeup fun...
changeset e5550966464a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e5550966464a
description:
Ruby: Improve Change PerfectSwitch's wakeup function
Currently the wakeup function for the PerfectSwitch contains three
loops -
loop on number of virtual networks
loop on number of incoming links
loop till all messages for this (link, network) have been
routed
With an 8 processor mesh network and Hammer protocol, about 11-12% of
the
was observed to have been spent in this function, which is the highest
amongst all the functions. It was found that the innermost loop is
executed
about 45 times per invocation of the wakeup function, when each
invocation
of the wakeup function processes just about one message.
The patch tries to do away with the redundant executions of the
innermost
loop. Counters have been added for each virtual network that record the
number of messages that need to be routed for that virtual network. The
inner loops are only executed when the number of messages for that
particular
virtual network 0. This does away with almost 80% of the executions
of the
innermost loop. The function now consumes about 5-6% of the total
execution
time.
diffstat:
src/mem/ruby/buffers/MessageBuffer.cc |3 +
src/mem/ruby/buffers/MessageBuffer.hh |6 +
src/mem/ruby/common/Consumer.hh|1 +
src/mem/ruby/network/simple/PerfectSwitch.cc | 285 +---
src/mem/ruby/network/simple/PerfectSwitch.hh |2 +
src/mem/ruby/slicc_interface/Message.hh|2 +
src/mem/ruby/slicc_interface/NetworkMessage.hh |7 +
7 files changed, 172 insertions(+), 134 deletions(-)
diffs (truncated from 441 to 300 lines):
diff -r 42f772dc5a96 -r e5550966464a src/mem/ruby/buffers/MessageBuffer.cc
--- a/src/mem/ruby/buffers/MessageBuffer.cc Sun Feb 13 17:46:04 2011 -0800
+++ b/src/mem/ruby/buffers/MessageBuffer.cc Mon Feb 14 16:14:54 2011 -0600
@@ -58,6 +58,8 @@
m_name = name;
m_stall_msg_map.clear();
+m_input_link_id = 0;
+m_vnet_id = 0;
}
int
@@ -228,6 +230,7 @@
// Schedule the wakeup
if (m_consumer_ptr != NULL) {
g_eventQueue_ptr-scheduleEventAbsolute(m_consumer_ptr, arrival_time);
+m_consumer_ptr-storeEventInfo(m_vnet_id);
} else {
panic(No consumer: %s name: %s\n, *this, m_name);
}
diff -r 42f772dc5a96 -r e5550966464a src/mem/ruby/buffers/MessageBuffer.hh
--- a/src/mem/ruby/buffers/MessageBuffer.hh Sun Feb 13 17:46:04 2011 -0800
+++ b/src/mem/ruby/buffers/MessageBuffer.hh Mon Feb 14 16:14:54 2011 -0600
@@ -142,6 +142,9 @@
void printStats(std::ostream out);
void clearStats() { m_not_avail_count = 0; m_msg_counter = 0; }
+void setIncomingLink(int link_id) { m_input_link_id = link_id; }
+void setVnet(int net) { m_vnet_id = net; }
+
private:
//added by SS
int m_recycle_latency;
@@ -184,6 +187,9 @@
bool m_ordering_set;
bool m_randomization;
Time m_last_arrival_time;
+
+int m_input_link_id;
+int m_vnet_id;
};
inline std::ostream
diff -r 42f772dc5a96 -r e5550966464a src/mem/ruby/common/Consumer.hh
--- a/src/mem/ruby/common/Consumer.hh Sun Feb 13 17:46:04 2011 -0800
+++ b/src/mem/ruby/common/Consumer.hh Mon Feb 14 16:14:54 2011 -0600
@@ -67,6 +67,7 @@
virtual void wakeup() = 0;
virtual void print(std::ostream out) const = 0;
+virtual void storeEventInfo(int info) {}
const Time
getLastScheduledWakeup() const
diff -r 42f772dc5a96 -r e5550966464a
src/mem/ruby/network/simple/PerfectSwitch.cc
--- a/src/mem/ruby/network/simple/PerfectSwitch.cc Sun Feb 13 17:46:04
2011 -0800
+++ b/src/mem/ruby/network/simple/PerfectSwitch.cc Mon Feb 14 16:14:54
2011 -0600
@@ -54,6 +54,11 @@
m_round_robin_start = 0;
m_network_ptr = network_ptr;
m_wakeups_wo_switch = 0;
+
+for(int i = 0;i m_virtual_networks;++i)
+{
+m_pending_message_count.push_back(0);
+}
}
void
@@ -62,12 +67,15 @@
assert(in.size() == m_virtual_networks);
NodeID port = m_in.size();
m_in.push_back(in);
+
for (int j = 0; j m_virtual_networks; j++) {
m_in[port][j]-setConsumer(this);
string desc = csprintf([Queue from port %s %s %s to PerfectSwitch],
NodeIDToString(m_switch_id), NodeIDToString(port),
NodeIDToString(j));
m_in[port][j]-setDescription(desc);
+m_in[port][j]-setIncomingLink(port);
+m_in[port][j]-setVnet(j);
}
}
@@ -154,161 +162,170 @@
m_round_robin_start = 0;
}
-// for all input ports, use round robin scheduling
-for (int counter = 0; counter m_in.size(); counter++) {
-// Round robin scheduling
-incoming++;
-if (incoming = m_in.size()) {
-
Re: [m5-dev] Review Request: configs: set default cache params
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/485/#review866 --- configs/common/CacheConfig.py http://reviews.m5sim.org/r/485/#comment1235 These lines look like they're too long. Since these are more complicated now, it might be a good idea to set up the two caches before the if buildEnv[... and then just pass them in to whichever function ends up being called. - Gabe On 2011-02-13 19:13:33, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/485/ --- (Updated 2011-02-13 19:13:33) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- configs: set default cache params It's confusing (especially to new users), when you are setting some standard parameters (as defined in Options.py) and they aren't reflected in the simulations so we might as well link the settings in CacheConfig.py to those in Options.py Diffs - configs/common/CacheConfig.py 68a5b8bba293 configs/common/Options.py 68a5b8bba293 Diff: http://reviews.m5sim.org/r/485/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Info: Clean up some info files.
Yeah, that would probably be overkill to do at build time. It would probably be useful for initially extracting licenses to put in a LICENSES directory though. Gabe On 02/14/11 13:12, nathan binkert wrote: I do have code that can parse source files to extract licenses. We could write a script that sucks out all of the licenses automatically (collapsing common pieces as necessary). Seems like it could be overkill though. Nate On Mon, Feb 14, 2011 at 8:54 PM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/486/ On February 14th, 2011, 6:48 a.m., *Nathan Binkert* wrote: LICENSE http://reviews.m5sim.org/r/486/diff/1/?file=10325#file10325line1 (Diff revision 1) 1 Copyright (c) 2000-2008 The Regents of The University of Michigan 1 Copyright (c) 2000-2011 The Regents of The University of Michigan Should we put everyone in here? (And all licenses?) On February 14th, 2011, 7:58 a.m., *Ali Saidi* wrote: I think we should as most of the license text says in, source and binary forms. The LICENSE file gets sucked into the simulator as a string and can be printed with a command line parameter, so it probably should have all of them. That would tie back into my idea of having a directory for all the different licenses which could then all be sucked in and output together. I didn't want to mess with the license stuff too much in this change since IANAL and I'm sure there will be some diversity of opinion here. - Gabe On February 13th, 2011, 11:47 p.m., Gabe Black wrote: Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. By Gabe Black. /Updated 2011-02-13 23:47:40/ Description Info: Clean up some info files. Get rid of RELEASE_NOTES since we no longer do releases, update some of the information in README, and update the date in LICENSE. Diffs * LICENSE (e8f4bb35dca9) * README (e8f4bb35dca9) * RELEASE_NOTES (e8f4bb35dca9) * src/SConscript (e8f4bb35dca9) * src/python/m5/main.py (e8f4bb35dca9) View Diff http://reviews.m5sim.org/r/486/diff/ ___ 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] changeset in m5: Info: Clean up some info files.
changeset 13692327bb0b in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=13692327bb0b description: Info: Clean up some info files. Get rid of RELEASE_NOTES since we no longer do releases, update some of the information in README, and update the date in LICENSE. diffstat: LICENSE |2 +- README| 32 ++ RELEASE_NOTES | 136 -- src/SConscript|2 +- src/python/m5/main.py |9 --- 5 files changed, 21 insertions(+), 160 deletions(-) diffs (260 lines): diff -r e5550966464a -r 13692327bb0b LICENSE --- a/LICENSE Mon Feb 14 16:14:54 2011 -0600 +++ b/LICENSE Mon Feb 14 21:36:37 2011 -0800 @@ -1,4 +1,4 @@ -Copyright (c) 2000-2008 The Regents of The University of Michigan +Copyright (c) 2000-2011 The Regents of The University of Michigan All rights reserved. Redistribution and use in source and binary forms, with or without diff -r e5550966464a -r 13692327bb0b README --- a/READMEMon Feb 14 16:14:54 2011 -0600 +++ b/READMEMon Feb 14 21:36:37 2011 -0800 @@ -1,4 +1,4 @@ -This is release 2.0_beta6 of the M5 simulator. +This is the M5 simulator. For detailed information about building the simulator and getting started please refer to http://www.m5sim.org. @@ -9,13 +9,16 @@ Short version: -1. If you don't have SCons version 0.96.91 or newer, get it from +1. If you don't have SCons version 0.98.1 or newer, get it from http://.scons.org. -2. If you don't have SWIG version 1.3.28 or newer, get it from +2. If you don't have SWIG version 1.3.31 or newer, get it from http://.swig.org. -3. In this directory, type 'scons build/ALPHA_SE/tests/debug/quick'. This +3. Make sure you also have gcc version 3.4.6 or newer, Python 2.4 or newer +(the dev version with header files), zlib, and the m4 preprocessor. + +4. In this directory, type 'scons build/ALPHA_SE/tests/debug/quick'. This will build the debug version of the m5 binary (m5.debug) for the Alpha syscall emulation target, and run the quick regression tests on it. @@ -25,18 +28,21 @@ - The basic source release includes these subdirectories: - - m5: + - m5: + - configs: simulation configuration scripts + - ext: less-common external packages needed to build m5 - src: source code of the m5 simulator + - system: source for some optional system software for simulated systems - tests: regression tests - - ext: less-common external packages needed to build m5 + - util: useful utility programs and files -To run full-system simulations, you will need compiled console, -PALcode, and kernel binaries and one or more disk images. These files -are collected in a separate archive, m5_system.tar.bz2. This file -can he downloaded separately. +To run full-system simulations, you will need compiled system firmware +(console and PALcode for Alpha), kernel binaries and one or more disk images. +These files for Alpha are collected in a separate archive, m5_system.tar.bz2. +This file can he downloaded separately. -M5 supports Linux 2.4/2.6, FreeBSD, and the proprietary Compaq/HP -Tru64 version of Unix. We are able to distribute Linux and FreeBSD -bootdisks, but we are unable to distribute bootable disk images of +Depending on the ISA used, M5 may support Linux 2.4/2.6, FreeBSD, and the +proprietary Compaq/HP Tru64 version of Unix. We are able to distribute Linux +and FreeBSD bootdisks, but we are unable to distribute bootable disk images of Tru64 Unix. If you have a Tru64 license and are interested in obtaining disk images, contact us at m5-us...@m5sim.org diff -r e5550966464a -r 13692327bb0b RELEASE_NOTES --- a/RELEASE_NOTES Mon Feb 14 16:14:54 2011 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,149 +0,0 @@ -October 6, 2008: m5_2.0_beta6 - -New Features -1. Support for gcc 4.3 -2. Core m5 code in libm5 for integration with other simulators -3. Preliminary support for X86 SE mode -4. Additional system calls emulated -5. m5term updated to work on OS X -6. Ability to disable listen sockets -7. Event queue performance improvements and rewrite -8. Better errors for unconnected memory ports - -Bug fixes -1. ALPHA_SE O3 perlbmk benchmark -2. Translation bug where O3 could fetch from uncachable memory -3. Many minor bugs - -Outstanding issues for 2.0 release: - -1. Statistics cleanup -2. Improve regression system -3. Testing -4. Validation - -March 1, 2008: m5_2.0_beta5 - -New Features -1. Rick Strong's Simpoints config changes -2. Support for FSU ARM port -3. EXTRAS= option allow architectures to be specified - -Bug fixes -1. Bus timing more realistic -2. Cache writeback, LL/SC fixes -3. Minor IGbE NIC fixes -4. O3 op latency fix -5. SPARC TLB demap fixes -6. SPARC SE memory layout fixes -7. Variety of MIPS fixes - -Nov 4, 2007: m5_2.0_beta4 - -New Features
Re: [m5-dev] Review Request: Alpha: Import the alpha-system files into the m5 repository.
Actually, I think we want to run HG convert (from hg to hg) first and then do a pull -f after that. I can take a look at this tonight. Ok. I think I've got this right. I'm not going to put it on reviewboard since there are so many changes. I've got the formula below for the hg convert. After that are small tweaks to deal with compile issues which are an additional changeset which you can look at when I put up a repo that people can look at (I'll do that as soon as I get a chance). Once I get a confirmation that I didn't screw stuff up, I'll commit it. One simple question, what should the parent of the first changeset for the alpha-system branch of the graph be? What I have below is simply linearized on the tip, but I could alternatively have no parent (that's the default, but I don't know if there is any downside to that) or have the parent be any arbitrary changeset. Opinions are welcome. Nate hg convert --filemap as.map --splicemap as.splice -A as.authors alpha-system m5 as.map -- rename console system/alpha/console rename h system/alpha/h rename palcode system/alpha/palcode as.splice - 05dc3a70a076d184c3dbee03bac4e644486783f9 9c245e375e05179c120e9c56e6d8d35b440a4528 as.authors --- alschult=Andrew Schultz alsch...@umich.edu benash=Benjamin Nash ben...@umich.edu binkertn=Nathan Binkert binke...@umich.edu ehallnor=Erik Hallnor ehall...@umich.edu hsul=Lisa Hsu h...@eecs.umich.edu mserrano=Miguel Serrano mserr...@umich.edu saidi=Ali Saidi sa...@eecs.umich.edu stever=Steve Reinhardt ste...@eecs.umich.edu ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Next steps
Hi Brad, I have checked in the patch dealing with Perfect Switch. I am will clean the patch that removes CacheMsg class soon. What to take up next? I am kind of bored with this optimization stuff right now. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] CacheController's wakeup function
I thought of this a moment ago, so I have not confirmed this empirically.
The CacheController's wakeup function includes a while loop, in which all
the queues are checked. Consider the Hammer protocol's L1 Cache
Controller. It has four incoming queues - trigger, response, forward,
mandatory. The wakeup function looks like this --
while(true)
{
process trigger queue;
process response queue;
process forward queue;
process mandatory queue;
}
where process means processing a single message from the queue.
I expect most of the messages to be present in the mandatory queue which
processes the actually loads and stores issued by the associated
processor. Would the following be better --
while(true) process trigger queue;
while(true) process response queue;
while(true) process forward queue;
while(true) process mandatory queue;
I do not expect any improvement in case of FS profiling as most of the
times, the mandatory queue has only one single message. But for testing
protocols using ruby random tester, I do expect some improvement. In FS
profile, after the histogram function (which takes about 8% time), the
wakeup function's execution time is the highest (about 5%). For ruby
random tester profile, the wakeup function takes about 11% of the time.
--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
