Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-23 Thread Timothy M Jones
On 23/06/2015 01:12, Joel Hestness wrote: (C) seems most probable given that the changeset 10524 moved memories out of Ruby (note in that changeset that memory checkpointing occurred in RubySystem::serialize() AFTER the cache flush operation). Can you check whether the RubySystem or the

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-22 Thread Timothy M Jones
Hi All, On 19/06/2015 09:22, Timothy M Jones wrote: I think my first step will be to verify that the blocks in each of the caches at the point the checkpoint is taken is the same as after the checkpoint has been restored. I have tracked down the problem to a particular line in one of the L1

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-22 Thread Beckmann, Brad
@gem5.org Subject: Re: [gem5-dev] Ruby serialize removing event queue head Hi Brad, On 17/06/2015 21:38, Beckmann, Brad wrote: The benefit for creating at trace, rather than just inserting data into the cache, is two-fold. First, by creating a trace from a very large cache system, one can

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-22 Thread Timothy M Jones
Hi Joel, On 22/06/2015 20:35, Joel Hestness wrote: I'm not sure whether this is really a bug. No, I'm sure that this isn't the bug. The problem is that when the line is restored it isn't restored to the same state (my guess so far is that it isn't consistent with memory and because this

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-22 Thread Joel Hestness
Hi Tim, I'm not sure whether this is really a bug. Dirty cache lines could be shared in a read-only state among caches. Whether to allow data in caches to differ from memory (i.e. dirty bit set) is a choice by a directory of a protocol. It could write a line back to memory to clean it, or allow

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-19 Thread Timothy M Jones
Hi Joel, On 19/06/2015 16:16, Joel Hestness wrote: Unsolicited hint: this looks like it could be a bug in x264 or libraries (depending on which version of Linux you've booted). ld-2.6.1 is 7 years old, and may only work with older versions of Linux (e.g. 2.6.28.4). If you're booting a newer

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-19 Thread Joel Hestness
Hi Tim, On 18/06/2015 15:35, Joel Hestness wrote: I think we should keep the cache tracing functionality. I've used cache warm-up after taking repeated checkpoints to find particular system activity levels, and I only restore+simulate those that meet some criteria (i.e. like simpoints).

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-18 Thread Joel Hestness
Hi Tim, I think we should keep the cache tracing functionality. I've used cache warm-up after taking repeated checkpoints to find particular system activity levels, and I only restore+simulate those that meet some criteria (i.e. like simpoints). Often, the intervals simulated between these

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-18 Thread Timothy M Jones
Hi Brad, On 17/06/2015 21:38, Beckmann, Brad wrote: The benefit for creating at trace, rather than just inserting data into the cache, is two-fold. First, by creating a trace from a very large cache system, one can warmup caches of different sizes, associativities and even completely

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-17 Thread Beckmann, Brad
To: gem5 Developer List Subject: Re: [gem5-dev] Ruby serialize removing event queue head Thanks Nilay and Joel for the information. I've been playing around with this over the past few days and I can't work out what the point of the flush is. The CacheRecorder already has a copy of all the data

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-17 Thread Timothy M Jones
Thanks Nilay and Joel for the information. I've been playing around with this over the past few days and I can't work out what the point of the flush is. The CacheRecorder already has a copy of all the data blocks in the trace before the flush starts. Removing the flush event and subsequent

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-13 Thread Nilay Vaish
Your bisection is not right. You might want to take a look at the following changeset: changeset: 10756:f9c0692f73ec user:Curtis Dunham curtis.dun...@arm.com date:Mon Mar 23 06:57:36 2015 -0400 summary: sim: Reuse the same limit_event in simulate() I suggest that you

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-13 Thread Timothy M Jones
Hi again, Further to this message, I've used hg bisect to find the revision that breaks checkpointing with ruby. It's revision 10524 that Nilay committed in November that's the first bad changeset. It fails with the panic() on the missing event that I wrote about previously. I've scanned

Re: [gem5-dev] Ruby serialize removing event queue head

2015-06-13 Thread Joel Hestness
Hey guys, I'm pretty sure Tim is correct that the checkpointing bugs were introduced earlier than the changeset Nilay points to; gem5-gpu is currently using gem5 rev 10645 http://repo.gem5.org/gem5/rev/cd95d4d51659, and we cannot get reliable checkpoint and restore with it. Note that Tim's bug

[gem5-dev] Ruby serialize removing event queue head

2015-06-11 Thread Timothy M Jones
Hello, Could someone tell me why we need to take the head event off the event queue in RubySystem::serialize() in src/mem/ruby/system/System.cc? Event* eventq_head = eventq-replaceHead(NULL); The problem I'm getting is that when simulate() is called a few lines later, it tries to reschedule