Hi Everyone,

The following patches have been on the RB for almost two weeks and we are 
planning on pushing them early next week. Please let me know if there are any 
objections or if someone needs more  time.


Read Response with invalidate fix:

1) #3724 - mem: Add support for repopulating the flags of an MSHR TargetList
2) #3725 - mem: Keep track of allocOnFill in the TargetList
3) #3726 - mem: Service only the 1st FromCPU MSHR target on ReadRespWithInv
4) #3727 - cpu: Change traffic generators to use different values for writes


Invalidatation fix:

1) #3728 - mem: Make packet debug printing more uniform
2) #3729 - mem: Ensure InvalidateReq is considered isForward by MSHRs
3) #3730 - mem: Assert that the responderHadWritable is set only once
4) #3731 - mem: Always use InvalidateReq to service WriteLineReq misses
5) #3732 - mem: Don't use hasSharers in the snoopFilter for memory responses
6) #3733 - mem: Allow non invalidating snoops on an InvalidateReq MSHR
7) #3734 - mem: Invalidate a blk when servicing the 1st invalidating target
8) #3735 - mem: Respond to InvalidateReq when the block is (pending) dirty
9) #3736 - config: Add whole line accesses to improve memchecker's coverage)
10) #3737 - config: Add an option to generate a random topology in memcheck


Thanks,


Nikos

________________________________
From: Nikos Nikoleris
Sent: 18 November 2016 17:20:57
To: Default
Subject: Memory model patches for review

Fellow gem5 developers,

I have just posted a number of patches on the reviewboard that address two 
issues with the memory model of the classic memory system. This is a short 
description of the context for these patches to help out with any reviews.

The first set of patches deals with memory ordering issues when two consecutive 
read requests miss in the cache and the downstream cache receives an 
invalidating snoop request in between. Currently the cache would service both 
read requests with the same response despite the fact that the ordering point 
(the downstream cache) received an invalidating snoop between the two requests. 
The following patches address this issue by deferring the second read request 
when a read response with invalidate is received. The issue can be reproduced 
using the memchecker after #3727 has been applied.

1) #3724 - mem: Add support for repopulating the flags of an MSHR TargetList
2) #3725 - mem: Keep track of allocOnFill in the TargetList
3) #3726 - mem: Service only the 1st FromCPU MSHR target on ReadRespWithInv
4) #3727 - cpu: Change traffic generators to use different values for writes

The second set of patches deals with memory ordering issues in the presence of 
whole line writes. In the classic memory system, whole line requests that miss 
send out invalidations requests to every cache down to the point of coherency. 
The point of coherency (xbar) always responds to the invalidation request after 
it has sent snoops to all upstream caches. This creates problems as there is no 
ordering point and write line requests get serviced in an arbitrary order. This 
series of patches makes the cache with the (pending) dirty copy, or otherwise 
the point of coherency (xbar) the ordering point which responds the to the 
invalidation request. This way invalidation requests are handled in the same 
way as upgrade requests. The whole line memory order issue can be reproduced by 
the memchecker after #3726 has been applied.

1) #3728 - mem: Make packet debug printing more uniform
2) #3729 - mem: Ensure InvalidateReq is considered isForward by MSHRs
3) #3730 - mem: Assert that the responderHadWritable is set only once
4) #3731 - mem: Always use InvalidateReq to service WriteLineReq misses
5) #3732 - mem: Don't use hasSharers in the snoopFilter for memory responses
6) #3733 - mem: Allow non invalidating snoops on an InvalidateReq MSHR
7) #3734 - mem: Invalidate a blk when servicing the 1st invalidating target
8) #3735 - mem: Respond to InvalidateReq when the block is (pending) dirty
9) #3736 - config: Add whole line accesses to improve memchecker's coverage)
10) #3737 - config: Add an option to generate a random topology in memcheck

Thanks,

Nikos
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to