> On 2010-07-10 08:43:33, Steve Reinhardt wrote: > > Is the root problem here that when I have an A<->B port connection, then I > > connect A to C, B still thinks it's connected to A even though it's not? > > (Where in this specific example, A is the cache, and B and C are different > > CPUs.) If so, I'd rather see a more general solution like having > > Port::setPeer() automatically clear out any previous peer's pointer back to > > itself. I would not be terribly surprised if this had surprising and ugly > > ramifications and we run away scared, but I'd at least like to try that > > before going with a localized workaround like this. Does that make sense? > > Can you give it a try? > > Timothy Jones wrote: > Yes, your summary of the problem is exactly that. I can certainly have a > go at implementing that functionality in setPeer and see what happens.
Ok, I've altered the code as in diff r2. I thought it was better to be explicit about removing connections so I've kept the call to removeConn() outside setPeer(). Also, I've created a new function to set a peer port to the default peer, instead of NULL. If you think this is surplus then I can remove that. This new function is then called in deletePortRefs() in each of the CPUs. I couldn't call setPeer() in deletePortRefs() because it starts getting complicated when CPUs override it (e.g. in O3). I think this is a better solution to what I had before. - Timothy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/49/#review64 ----------------------------------------------------------- On 2010-07-16 13:21:32, Timothy Jones wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/49/ > ----------------------------------------------------------- > > (Updated 2010-07-16 13:21:32) > > > Review request for Default. > > > Summary > ------- > > Sim: When one CPU is taking over from another, the new CPU's memory is only > connected up if it's not connected to something already. However, when > sharing caches between several CPUs and repeatedly switching between them, > the CPU thinks it is connected up when it actually isn't. To rectify this, > provide a new parameter to the takeOverFrom function that forces memory > to be connected up. > > > Diffs > ----- > > src/cpu/base.cc 249f174e6f37 > src/cpu/o3/cpu.hh 249f174e6f37 > src/cpu/simple/atomic.hh 249f174e6f37 > src/cpu/simple/atomic.cc 249f174e6f37 > src/mem/port.hh 249f174e6f37 > src/mem/port.cc 249f174e6f37 > > Diff: http://reviews.m5sim.org/r/49/diff > > > Testing > ------- > > > Thanks, > > Timothy > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
