> On Dec. 23, 2015, 6:31 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 2405
> > <http://reviews.gem5.org/r/3254/diff/2/?file=52272#file52272line2405>
> >
> >     the snoop response is always dirty, even if I didn't request a writable 
> > copy?
> 
> Andreas Hansson wrote:
>     if cacheResponding is set it is indeed always dirty

still not clear what you mean... dirty/ownership isn't always passed to the 
recipient, if needsExclusive wasn't set and the responder does not have a 
writable copy (i.e., is in O state).  I don't think this affects what's going 
on here anyway so might be easiest just to drop "the snoop response is always 
dirty, and " from the comment.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3254/#review7743
-----------------------------------------------------------


On Dec. 24, 2015, 12:59 a.m., Andreas Hansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3254/
> -----------------------------------------------------------
> 
> (Updated Dec. 24, 2015, 12:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11281:fc4962869323
> ---------------------------
> mem: Make cache terminology easier to understand
> 
> This patch changes the name of a bunch of packet flags and MSHR member
> functions and variables to make the coherency protocol easier to
> understand. In addition the patch adds and updates lots of
> descriptions, explicitly spelling out assumptions.
> 
> The following name changes are made:
> 
> * the packet memInhibit flag is renamed to cacheResponding
> 
> * the packet shared flag is renamed to passNonWritable
> 
> * the packet NeedsExclusive attribute is renamed to NeedsWritable
> 
> * the packet isSupplyExclusive is renamed responderHadWritable
> 
> * the MSHR pendingDirty is renamed to pendingWritable
> 
> The cache states, Modified, Owned, Exclusive, Shared are also called
> out in the cache and MSHR code to make it easier to understand.
> 
> 
> Diffs
> -----
> 
>   src/mem/cache/mshr.hh d9a0136ab8cc 
>   src/mem/cache/cache.cc d9a0136ab8cc 
>   src/mem/cache/cache.hh d9a0136ab8cc 
>   src/mem/cache/blk.hh d9a0136ab8cc 
>   src/mem/bridge.cc d9a0136ab8cc 
>   src/mem/cache/base.hh d9a0136ab8cc 
>   src/mem/addr_mapper.cc d9a0136ab8cc 
>   src/mem/dramsim2.cc d9a0136ab8cc 
>   src/mem/hmc_controller.cc d9a0136ab8cc 
>   src/mem/dram_ctrl.cc d9a0136ab8cc 
>   src/mem/comm_monitor.cc d9a0136ab8cc 
>   src/mem/coherent_xbar.cc d9a0136ab8cc 
>   src/mem/cache/mshr_queue.cc d9a0136ab8cc 
>   src/mem/cache/mshr.cc d9a0136ab8cc 
>   src/mem/cache/mshr_queue.hh d9a0136ab8cc 
>   src/mem/ruby/system/RubyPort.cc d9a0136ab8cc 
>   src/mem/ruby/system/DMASequencer.cc d9a0136ab8cc 
>   src/mem/packet.hh d9a0136ab8cc 
>   src/mem/packet.cc d9a0136ab8cc 
>   src/mem/noncoherent_xbar.cc d9a0136ab8cc 
>   src/mem/mem_checker_monitor.cc d9a0136ab8cc 
>   src/mem/snoop_filter.cc d9a0136ab8cc 
>   src/mem/tport.cc d9a0136ab8cc 
>   src/mem/simple_mem.cc d9a0136ab8cc 
>   src/mem/serial_link.cc d9a0136ab8cc 
>   src/mem/abstract_mem.cc d9a0136ab8cc 
>   src/cpu/o3/cpu.cc d9a0136ab8cc 
>   src/dev/dma_device.cc d9a0136ab8cc 
> 
> Diff: http://reviews.gem5.org/r/3254/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to