Hi,
I've tried adjusting the original code to do exactly what your diff
shows and I still get the same assertion error...perhaps the difference
is in the binary executable. Note that everything, both benchmark and M5
were compiled on 64bit Ubuntu.
I also run with the command line: <m5opt> ~/m5/configs/example/se.py
--caches --detailed -c ~/stream/stream
I've put the zipped binary on my website:
http://glue.umd.edu/~joegross/stream.gz
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Alpha
Version: 0x1
Entry point address: 0x1200001b0
Start of program headers: 64 (bytes into file)
Start of section headers: 558640 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 4
Size of section headers: 64 (bytes)
Number of section headers: 27
Section header string table index: 24
My new memory object does in fact derive from PhysicalMemory and I use
the PhysicalMemory::doAtomicAccess() function and all that it calls, I
don't reimplement this. I do, however, create my own memory port derived
from SimpleTimingPort and my own timing event derived from Event so that
I can schedule wakeups at arbitrary times. The method of calculating
latencies based upon some known state at the time the packet arrives
won't work for me, because the latency is not only variable but is also
nondeterministic at that point. A later request could have higher
priority than earlier ones and thus dynamically increase the latency of
the earlier requests. I'll see if the problem persists once I get access
to a real Alpha machine, possibly tomorrow.
Joe
Steve Reinhardt wrote:
Hi Joe,
I downloaded and compiled stream (on Alpha Tru64, not using the Linux
cross-compiler, though that shouldn't matter). I also put in a quick
hack to have the main memory latency be a random value betw 20K and
40K ticks (see patch below). I ran stream like this:
build/ALPHA_SE/m5.opt configs/example/se.py -c ~/stream/stream -d --caches
and it ran to completion successfully. I also ran with
--trace-flags=Bus,MemoryAccess long enough to verify that there were
responses coming back out of order. So simply returning responses out
of order to the cache does not seem to be sufficient to trigger your
assertion failure. I'm not sure what the problem is then. If you're
running with different arguments please let me know.
Is there a particular reason you're adding a whole new object that
doesn't derive from PhysicalMemory but still uses PhysicalMemory to
maintain storage? Would it be possible for you to make
PhysicalMemory::calculateLatency() a virtual function, then implement
your model by deriving from PhysicalMemory and just overriding that
function? That seems like it could eliminate a lot of redundant code
that you must have, which might be the source of the problem.
Steve
% hg diff
diff -r 0f92b8eeaec5 src/mem/physical.cc
--- a/src/mem/physical.cc Thu Nov 08 23:50:10 2007 -0800
+++ b/src/mem/physical.cc Sat Nov 10 08:13:29 2007 -0800
@@ -112,7 +112,9 @@ Tick
Tick
PhysicalMemory::calculateLatency(PacketPtr pkt)
{
- return lat;
+ Tick l = 20000*lat + randomGen.random((Tick)0, (Tick)20000*lat);
+ DPRINTF(MemoryAccess, "latency %d\n", l);
+ return l;
}
diff -r 0f92b8eeaec5 src/mem/physical.hh
--- a/src/mem/physical.hh Thu Nov 08 23:50:10 2007 -0800
+++ b/src/mem/physical.hh Sat Nov 10 08:13:29 2007 -0800
@@ -37,6 +37,7 @@
#include <map>
#include <string>
+#include "base/random.hh"
#include "base/range.hh"
#include "mem/mem_object.hh"
#include "mem/packet.hh"
@@ -149,6 +150,8 @@ class PhysicalMemory : public MemObject
std::vector<MemoryPort*> ports;
typedef std::vector<MemoryPort*>::iterator PortIterator;
+ Random randomGen;
+
public:
Addr new_page();
uint64_t size() { return params()->range.size(); }
On 11/10/07, Joe Gross <[EMAIL PROTECTED]> wrote:
Currently I take the standard se.py file and all its settings and just
replace PhysicalMemory with my own simulator, leaving everything else alone.
I also test using the stream benchmark
(http://www.cs.virginia.edu/stream/ref.html), cross-compiled with the
-O3 flag.
I'm able to reproduce the error by using only the following code in
recvTiming():
bool nr = pkt->needsResponse();
memory->doAtomicAccess(pkt);
if (nr)
{
memory->ports[memory->lastPortIndex]->doSendTiming(pkt,curTick +
18750 + rand()%400);
}
else
{
delete pkt->req;
delete pkt;
}
return true;
Interestingly, it seems to work when I use 1875, but breaks with 18750.
Since the default CPU is 1THz and the memory system is ~400/800MHz,
latencies can be up to 200000 CPU cycles.
Joe
Steve Reinhardt wrote:
OK, I'll take a look... I just hacked a randomized latency into
PhysicalMemory to try and reproduce the problem but it's still working
for me. I'll run some longer tests to see if I can reproduce it. If
not, would you be willing to send me your code so I can see if I can
track it down?
Also, what kind of memory hierarchy are you using (uni- vs
multiprocessor, # of cache levels, etc.)?
Steve
On 11/9/07, Joe Gross <[EMAIL PROTECTED]> wrote:
Same problem even when doAtomicAccess() is performed before delaying the
return of the packet (thus ensuring that this is performed in order). I
checked to see if the packets were being returned in order with any
configuration of my memory simulator and they frequently aren't (some
ranks/banks see much more traffic). So it seems that it's a problem not
of doing the doAtomicAccess() but rather of sending the packets back in
a different order and it's somehow different than b3 when this
rearrangement worked fine.
Joe
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
