> On March 23, 2015, 6:13 p.m., Steve Reinhardt wrote:
> > Can you elaborate a bit on the functional issue for timing mode?  I can see 
> > where this makes a difference for atomic, but in timing mode arbitration 
> > between misses and writebacks is done in getNextMSHR() and isn't based on 
> > the order into which things are placed in mshrQueue vs. writeBuffer (except 
> > in the case where there are conflicts, which I don't think can happen here, 
> > since you wouldn't be writing back block X if you're making room for a 
> > request to block X).  Is this strictly related to uncacheable accesses?  Or 
> > is it really just an atomic-mode fix and you're changing the timing code to 
> > be consistent?

It is strictly paving the way for properly dealing with uncacheable accesses 
(that force a writeback out "in front" of them), and making sure atomic and 
timing are consistent.


- Andreas


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


On March 22, 2015, 7:35 a.m., Andreas Hansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2703/
> -----------------------------------------------------------
> 
> (Updated March 22, 2015, 7:35 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10765:3628e18edb65
> ---------------------------
> mem: Allocate cache writebacks before new MSHRs
> 
> This patch changes the order of writeback allocation such that any
> writebacks resulting from a tag lookup (e.g. for an uncacheable
> access), are added to the writebuffer before any new MSHR entries are
> allocated. This ensures that the writebacks logically precedes the new
> allocations.
> 
> The patch also changes the uncacheable flush to use proper timed (or
> atomic) writebacks, as opposed to functional writes.
> 
> 
> Diffs
> -----
> 
>   src/mem/cache/cache.hh 48a72150f82c 
>   src/mem/cache/cache_impl.hh 48a72150f82c 
> 
> Diff: http://reviews.gem5.org/r/2703/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Reply via email to