Re: [gem5-dev] delayedCommit not being honored
So, I was thinking about this, and generally speaking I don't think waiting for things to drain instead of squashing everything and taking the interrupt immediately is going to work for x86. In an OS, you might see a sequence of instructions like sti; cli;. What that does is turn on interrupts and then immediately turn them back off. It's used to provide a single spot for interrupts to happen, for instance if you're in a long loop where the work it's doing in an iteration isn't interruptable but it can take interrupts between iterations. The sti will happen, but before the interrupt can be taken, the cli will also happen and prevent it. I don't think you really save much by having things drain either. Sure, you don't throw away those instructions, but you have to wait for them before you trigger the interrupt. The other way, you trigger the interrupt immediately and then wait for it to get through the pipe. It doesn't make much of a difference. Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] gem5 tip information
If you give this a try, there are two approaches that might help. First, you could make generating the file that embeds the tip information part of linking the final binary. Then, you'd update it every time you really rebuilt, but you'd only do it when you were rebuilding for some other reason. The contents of that file wouldn't be updated otherwise, so they'd never make anything else out of date. Second, I'm reading a book all about build systems, and it mentioned that scons has an Ignore() builder which is the opposite of the Depends() builder in that it cuts links in the dependency graph. You could always generate new tip information, but cut the link so it won't trigger a full rebuild on its own. Like before, it would still be incorporated if one happened for another reason. In both of these approaches, the revision information could end up being stale if something other than the binary was updated and it played into whatever you were doing. For instance, if you updated configs but didn't touch anything compiled, the revision would reflect the last time gem5.whatever was built, not the revision your configs were at. That could be an important difference. One possible solution could be to embed the revision the binary was built at and to have it also figure out the revision at run time. They would usually be the same, but then you could see both and still save the spurious rebuilds. Gabe On 06/22/11 13:55, Lisa Hsu wrote: I can give it a shot. Not able to provide an ETA just yet. Lisa On Wed, Jun 22, 2011 at 1:27 PM, nathan binkert n...@binkert.org wrote: I like Nate's date.cc idea... basically that says whenever you build a binary, stick the current info in, but just because the info has changed that's not sufficient reason to consider the binary out of date. That's the same policy we use wrt the date and time. Actually, I took a quick look and I'm not sure why date.cc works. It explicitly depends on all other cc files which is why it is rebuilt, but I'm not sure why the date change itself doesn't trigger a rebuild. It could be because __DATE__ is simply an implicit variable and the SCons scanner doesn't see any input changes and never scans the file again after the first time. We could add the hg revision to date.cc (and pass it in via a #define) and perhaps use the Ignore() directive on it? Lisa, want to give it a shot? Nate ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] delayedCommit not being honored
So, I was thinking about this, and generally speaking I don't think waiting for things to drain instead of squashing everything and taking the interrupt immediately is going to work for x86. In an OS, you might see a sequence of instructions like sti; cli;. What that does is turn on interrupts and then immediately turn them back off. It's used to provide a single spot for interrupts to happen, for instance if you're in a long loop where the work it's doing in an iteration isn't interruptable but it can take interrupts between iterations. The sti will happen, but before the interrupt can be taken, the cli will also happen and prevent it. In this case shouldn't the sti instruction cause some form of serialization in the pipeline and make the cli wait in fetch until it completes? Otherwise both could go down the pipe and commit together, never allowing interrupts to happen. But again, I'm not entirely clear how the ISA should work in respect to this type of instruction. I don't think you really save much by having things drain either. Sure, you don't throw away those instructions, but you have to wait for them before you trigger the interrupt. The other way, you trigger the interrupt immediately and then wait for it to get through the pipe. It doesn't make much of a difference. In effect the pipeline already does this, commit is acknowledging the interrupt immediately but is waiting for the pipeline to finish up its current work that has to be completed before redirecting fetch and changing execution modes. To solve the issue you are seeing with the x86 ROM, you would have to add a signal from fetch to commit that would tell commit when fetch has actually decided to stall and be redirected to the interrupt handler. Maybe by doing this via an extra time buffer. Geoff ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Directory_Entry.hh
On Sat, 9 Jul 2011, ?? wrote: Under path gem5\src\mem\ruby\system,it is SparseMemory.hh file where there is a sentence as follows: #include mem/protocol/Directory_Entry.hh But I cannot find mem/protocol/Directory_Entry.hh,where is it ? You should use the gem5-users list to post any questions regarding gem5. Directory_Entry.hh is generated during the build process. After building gem5, look in the build directory, you should be able to find it. -- Nilay___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] se.py
On Wed, July 6, 2011 2:14 pm, Steve Reinhardt wrote: I was going to suggest something like: if buildEnv['RUBY']: Ruby.define_options(parser) (if that flag still exists) or maybe if 'PROTOCOL' in buildEnv: Ruby.define_options(parser) that would at least avoid the error on import PROTOCOL. Nate's solution seems OK too, though you could still run into weird errors if someone specifies '--ruby' without having compiled in Ruby (unless you add an explicit check for that). Steve On Wed, Jul 6, 2011 at 11:44 AM, Lisa Hsu h...@eecs.umich.edu wrote: That's lowest tech and least burdensome on anyone. I like. On Wed, Jul 6, 2011 at 10:56 AM, nathan binkert n...@binkert.org wrote: if options.ruby: Ruby.define_options(parser) (options, args) = parser.parse_args() Instead of this, you could simply do the following before any arguments are parsed: if '--ruby' in sys.argv: Ruby.define_options(parser) Then you only do one parse_args(). I am thinking of adding both the checks, '--ruby' would ensure that user does want ruby and concomitant options, buildEnv['RUBY'] will ensure that it has actually been compiled in. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] se.py
YOn Fri, 8 Jul 2011, Nilay wrote: On Wed, July 6, 2011 2:14 pm, Steve Reinhardt wrote: I was going to suggest something like: if buildEnv['RUBY']: Ruby.define_options(parser) (if that flag still exists) or maybe if 'PROTOCOL' in buildEnv: Ruby.define_options(parser) that would at least avoid the error on import PROTOCOL. Nate's solution seems OK too, though you could still run into weird errors if someone specifies '--ruby' without having compiled in Ruby (unless you add an explicit check for that). Steve On Wed, Jul 6, 2011 at 11:44 AM, Lisa Hsu h...@eecs.umich.edu wrote: That's lowest tech and least burdensome on anyone. I like. On Wed, Jul 6, 2011 at 10:56 AM, nathan binkert n...@binkert.org wrote: if options.ruby: Ruby.define_options(parser) (options, args) = parser.parse_args() Instead of this, you could simply do the following before any arguments are parsed: if '--ruby' in sys.argv: Ruby.define_options(parser) Then you only do one parse_args(). I am thinking of adding both the checks, '--ruby' would ensure that user does want ruby and concomitant options, buildEnv['RUBY'] will ensure that it has actually been compiled in. -- Nilay The variable 'RUBY' exists, but it is not exported. Any reason in particular? -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Prefetcher Issue
I'm sure this is Steve's favorite topic, but there is definitely an issue with the prefetcher replacing a dirty block in the cache with a clean copy recently retrieved from memory. Here is a trace of what is going on: 69707534000: system.cpu.dcache: set a3: selecting blk 2028c0 for replacement ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Prefetcher Issue
That's a pretty short trace, not much to go on ;-) On Fri, Jul 8, 2011 at 4:03 PM, Ali Saidi sa...@umich.edu wrote: I'm sure this is Steve's favorite topic, but there is definitely an issue with the prefetcher replacing a dirty block in the cache with a clean copy recently retrieved from memory. Here is a trace of what is going on: 69707534000: system.cpu.dcache: set a3: selecting blk 2028c0 for replacement ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Prefetcher Issue
No idea what happened there... my outbox still has the actual version.
lets try again:
I'm sure this is Steve's favorite topic, but there is definitely an
issue with the prefetcher replacing a dirty block in the cache with a
clean copy recently retrieved from memory. Here is a trace of what is
going on:
69707534000: system.cpu.dcache: set a3: selecting blk 2028c0 for
replacement--- L1 begins trying to writeback a
block 2028c0
69707534000: system.cpu.dcache: replacement: replacing 2028c0 with
f68c0: writeback
69707683000: system.l2-pf: queuing prefetch to 2028c0 @ 1000
69707683000: system.l2-pf: Found a pf candidate addr: 0x2028c0,
inserting into prefetch queue with delay 1000 time 6970769
69707691007: system.l2-pf: returning 0x2028c0
69707691007: system.membus: recvTiming: src 6 dst -1 ReadReq 0x2028c0
--- Prefetch sent out for address 0208c0
69707709001: system.tol2bus: recvTiming: src 2 dst -1 Writeback
0x2028c0 BUSY
69707714001: system.tol2bus: recvTiming: src 2 dst -1 Writeback
0x2028c0 BUSY
69707715000: system.tol2bus: recvTiming: src 2 dst -1 Writeback
0x2028c0
69707715000: system.l2: Writeback 2028c0 miss
--- Writeback occurs, prefetch
still pending
69707721007: system.membus: recvTiming: src 5 dst 6 ReadResp 0x2028c0
--- Block returns
69707721007: system.l2: Handling response to 2028c0
69707721007: system.l2: Block for addr 2028c0 being updated in Cache
--- And it's updated?! why?!
69707721007: system.l2: Block addr 2028c0 moving from state 15 to 15
--- Doesn't change state
69707787000: system.l2-pf: queuing prefetch to 2028c0 @ 1000
69707787000: system.l2-pf: Found a pf candidate addr: 0x2028c0,
inserting into prefetch queue with delay 1000 time 69707794000
69707795006: system.l2-pf: returning 0x2028c0
69708323000: system.cpu.dcache: ReadReq 2028c0 miss
--- L1 misses the block
69708328001: system.tol2bus: recvTiming: src 2 dst -1 ReadReq 0x2028c0
BUSY
69708329000: system.tol2bus: recvTiming: src 2 dst -1 ReadReq 0x2028c0
--- Gets data from L2, but this is the wrong
data (not the dirty copy)
69708329000: system.l2: set a3: moving blk 2028c0 to MRU
69708329000: system.l2: ReadReq 2028c0 hit
69708329000: system.l2-pf: hit: PC f048 blk_addr 2028c0 stride 64
(match), conf
69708340001: system.tol2bus: recvTiming: src 0 dst 2 ReadResp 0x2028c0
BUSY
69708346000: system.tol2bus: recvTiming: src 0 dst 2 ReadResp 0x2028c0
69708346000: system.cpu.dcache: Handling response to 2028c0
69708346000: system.cpu.dcache: Block for addr 2028c0 being updated in
Cache
69708346000: system.cpu.dcache: replacement: replacing 1fe8c0 with
2028c0: writeback
69708346000: system.cpu.dcache: Block addr 2028c0 moving from state 0
to 15
69708315000: system.cpu T0 : @route_net+2352: ldr r2, [r12, r0
LSL #2] : MemRead : D=0x A=0x2028c0
-- Instruction gets the wrong data :(
I don't know enough about the inner workings of this code to know how
this case is supposed to be handeled. Any suggestions? The only thing I
can think of is putting some code in handleFill() that does something
like:
bool was_dirty = false;
if (blk-isDirty())
was_dirty = true;
// if we got new data, copy it in
if (pkt-isRead() !was_dirty) {
std::memcpy(blk-data, pkt-getPtruint8_t(), blkSize);
} else if (was_dirty) {
DPRINTF(Cache, Block addr %x not being replaced because
previous data was dirty!, addr);
}
Any idea is this is going to create some new ugliness? It seems to
solve the problem immediately at hand.
Thanks,
Ali
On Fri, 8 Jul 2011 16:16:25 -0700, Steve Reinhardt ste...@gmail.com
wrote:
That's a pretty short trace, not much to go on ;-)
On Fri, Jul 8, 2011 at 4:03 PM, Ali Saidi sa...@umich.edu wrote:
I'm sure this is Steve's favorite topic, but there is definitely an
issue with the prefetcher replacing a dirty block in the cache with
a
clean copy recently retrieved from memory. Here is a trace of what
is
going on:
69707534000: system.cpu.dcache: set a3: selecting blk 2028c0
for replacement
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: GARNET: adding a fault model for resilient on-chip network research.
Hi all, I have already gone through the patch with Konstantinos and found it to be fine. We have made sure it integrates cleanly, and that gem5's style is followed. I look forward to hearing your comments. Thanks, Tushar On Jul 9, 2011, at 8:46 AM, Konstantinos Aisopos kaisopos.g...@gmail.com wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/776/ Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan Binkert, Brad Beckmann, and Tushar Krishna. By Konstantinos Aisopos. Description GARNET: adding a fault model for resilient on-chip network research. This patch adds a fault model, which provides the probability for a number of architectural faults in the interconnection network (e.g., data corruption, misrouting). These probabilities can be used to realistically inject faults in GARNET and faithfully evaluate the effectiveness of novel resilient NoC architectures. Diffs src/mem/ruby/network/fault_model/DB.conf.txt (PRE-CREATION) src/mem/ruby/network/fault_model/DB.temp.txt (PRE-CREATION) src/mem/ruby/network/fault_model/FaultModel.hh (PRE-CREATION) src/mem/ruby/network/fault_model/FaultModel.cc (PRE-CREATION) src/mem/ruby/network/fault_model/README (PRE-CREATION) src/mem/ruby/network/fault_model/SConscript (PRE-CREATION) src/mem/ruby/network/garnet/BaseGarnetNetwork.hh (7907b19fbe80) src/mem/ruby/network/garnet/BaseGarnetNetwork.cc (7907b19fbe80) src/mem/ruby/network/garnet/BaseGarnetNetwork.py (7907b19fbe80) src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc (7907b19fbe80) src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh (7907b19fbe80) src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc (7907b19fbe80) View Diff ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] mailing list archives
I think forums are a plausible alternative too. Since I'm deeply involved in gem5 I don't mind being on the lists, but in other situations I've been annoyed that I had to join one to ask questions and thought it was hard to find things people had already talked about. In my personal experience forums have been a bit easier to use. All of this is subjective, I'm sure, but I think it's worth considering. I know we talked about it before but I don't remember where that ended up. Gabe Quoting Ali Saidi sa...@umich.edu: I requested that mail-archive move the mails from the old list to the new list a couple of weeks ago. If previous experience is any measure of future, it will take them around 2 months to get around to handling my request. in the mean time I think the only option we have is to explain the situation on the wiki or highlight gmane as a complete archive. Thanks, Ali On Fri, 8 Jul 2011 18:54:50 -0700, Steve Reinhardt ste...@gmail.com wrote: In the process of digging up URLs to old email threads, I noticed that we now have three separate sets of archives at mail-archive.com, one for m5-*@ m5sim.org, one for gem5-*@m5sim.org, and one for gem5-*@gem5.org,each covering disjoint date ranges. I don't know what the status is at gmane, since their search wasn't responding so I gave up on it. Anyway, there's a general problem that it's a pain to have three disjoint lists to search, and a specific problem that only one set of these is linked to on the http://gem5.org/Mailing_Lists wiki page. Is there a better solution than just explaining things better on the wiki? Steve ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] se.py
I prefer to retain it. There are places where we check if RUBY is set or not, and checking for whether PROTOCOL is set or not, would not make sense, though it would yield the same information. What's the point of it? It's just redundant. The existence of both variables is simply an accident of history during the merge process. Basically, we should just check that PROTOCOL is in env or that PROTOCOL is not None and that would signify that we've got ruby compiled in. Having two variables doesn't gain us anything. We could rename PROTOCOL to RUBY_PROTOCOL. I don't care enough to fight, I just think that reducing the number of compile time variables is always a good thing. All this said, I think that actually the correct thing to do for se.py is to essentially do an if 'PROTOCOL' in env then add a --ruby option to the command line. Then do an if '--ruby' in sys.argv check to determine if the ruby options should be added. I know this is convoluted, but the classic memory system does exist even when ruby is compiled in, and without doing this in two steps you can't use the classic memory system if you have ruby compiled. That IMHO makes no sense. Nate ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
