summaryrefslogtreecommitdiff
path: root/src/mem/cache
AgeCommit message (Collapse)Author
2018-02-07mem-cache: Cleaned blocks should be marked as not writableNikos Nikoleris
A writeclean packet writes a dirty block to the memory below and therefore sets the dirty flag for the block when the memory below is a cache. If the block was also marked as writable it can satisfy future write requests without further requests/snoops. This can lead to multiple copies of the same block marked as dirty which is not allowed. This changeset clears the writable flag from the cleaned block to prevent the cache from satisfying future write requests without sending a downstream request. Change-Id: I14d3c62fd33f81b1a8ba62374c8565ccab00a6fe Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/7821 Maintainer: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2018-02-06mem-cache: Remove extra numSets zero check.Daniel R. Carvalho
numSets is unsigned, so it cannot be lower than 0. Besides, isPowerOf2(0) is false by definition (and implemmentation*), so there is no need for the double check. * As presented in base/intmath.hh Change-Id: I3f6296694a937434feddc7ed21f11c2a6fdfc5a9 Reviewed-on: https://gem5-review.googlesource.com/7901 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2018-02-06mem: Standardize mem folder header guardsDaniel R. Carvalho
Standardize all header guards in the mem directory according to the most frequent patterns. In general they have the form: mem: __FOLDER_TREE_FILE_NAME_HH__ ruby: __FOLDER_TREE_FILENAME_HH__ Change-Id: I983853e292deb302becf151bf0e970057dc24774 Reviewed-on: https://gem5-review.googlesource.com/7881 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2018-01-09mem-cache: Prune unnecessary writebacks in exclusive cachesNikos Nikoleris
Exclusive caches use the tempBlock to fill for responses from a downstream cache. The reason for this is that they only pass the block to the cache above without keeping a copy. When all requests are serviced the block is immediately invalidated unless it is dirty, in which case it has to be written back to the memory below. To avoid unnecessary writebacks, this changeset forces mostly exclusive caches to issuse requests that can only fetch clean data when possible. Reported-by: Quereshi Muhammad Avais <avais@kaist.ac.kr> Change-Id: I01b377563f5aa3e12d22f425a04db7c023071849 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5061 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-12-05mem: Co-ordination of CMOs in the xbarNikos Nikoleris
A clean packet request serving a cache maintenance operation (CMO) visits all memories down to the specified xbar. The visited caches invalidate their copy (if the CMO is invalidating) and if a dirty copy is found a write packet writes the dirty data to the memory level below the specified xbar. A response is send back when all the caches are clean and/or invalidated and the specified xbar has seen the write packet. This patch adds the following functionality in the xbar: 1) Accounts for the cache clean requests that go through the xbar 2) Generates the cache clean response when both the cache clean request and the corresponding writeclean packet has crossed the destination xbar. Previously transactions in the xbar were identified using the pointer of the original request. Cache clean transactions comprise of two different packets, the clean request and the writeclean, and therefore have different request pointers. This patch adds support for custom transaction IDs that by default take the value of the request pointer but can be overriden by the contructor. This allows the clean request and writeclean share the same id which the coherent xbar uses to co-ordinate them and send the response in a timely manner. Change-Id: I80db76386a1caded38dc66e6e18f930c3bb800ff Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5051 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05mem: Add support for handling CMOs in the MSHRsNikos Nikoleris
To add support for cache maintenance operations (CMOs) in the MSHRs, this change adds the following functionality: - If a CMO request hits in the MSHRs, we deferred as we can't coalesce it with any other requests. - When we promote any deferred targets, we promote them in order and stop if we encounter a CMO request. If the CMO request is at the beginning of the deferred targets list it will be the only promoted target. Change-Id: I10d1f7e16bd6d522d917279c5d408a3f0cee4286 Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5050 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05mem: Add support for CMOs in the cacheNikos Nikoleris
This change adds support for maintenance operations (CMOs) in the cache. The supported memory operations clean and/or invalidate a cache block as specified by its VA to the specified xbar (PoU, PoC). A cache maintenance packet visits all memories down to the specified xbar. Caches need to invalidate their copy if it is an invalidating CMO. If it is (additionally) a cleaning CMO and a dirty copy exists, the cache cleans it with a WriteClean request. Change-Id: Ibf31daa7213925898f3408738b11b1dd76c90b79 Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5049 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05mem: Promote deferred targets only when the block is validNikos Nikoleris
When a response indicates that there are no other sharers of the block, the cache can promote its copy of the block to writable and potential service deferred targets even if the request didn't ask for a writable copy. Previously, a response would guarantee the presence of the block in the cache. A response could either be filling, upgrading or a response to an invalidation due to a pending whole line write. Responses to cache maintenance invalidations break this assumption. This change adds an extra check to make sure that the block was already valid or that the response is filling before promoting the block. Change-Id: I6839f683a05d4dad4205c23f365a925b7b05e366 Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5048 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05mem: Support for specifying the destination of a WriteCleanNikos Nikoleris
Previously, WriteClean packets would always write to the first memory below unless the memory was unable to allocate in which case it would be forwarded further below. This change adds support for specifying the destination of a WriteClean packet. The cache annotates the request with the specified destination and marks the packet as write-through upon its creation. The coherent xbar checks packets for their destination and resets the write-through flag when necessary e.g., the coherent xbar that is set as the PoC will reset the write-through flag for packets to the PoC. Change-Id: I84b653f5cb6e46e97e09508649a3725d72d94606 Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5046 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05mem: Add support for WriteClean packets in the memory systemNikos Nikoleris
This change adds support for creating and handling WriteClean packets. The WriteClean operation is almost identical to a WritebackDirty with the exception that the cache generating a WriteClean retains a copy of the block. Change-Id: I63c8de62919fad0f9547d412f8266aa4292ebecd Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5045 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-12-05mem-cache: Add support for checking whether a cache is busyNikos Nikoleris
This changeset adds support for checking whether the cache is currently busy and a timing request would be rejected. Change-Id: I5e37b011b2387b1fa1c9e687b9be545f06ffb5f5 Reviewed-on: https://gem5-review.googlesource.com/5042 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-12-04misc: Rename misc.(hh|cc) to logging.(hh|cc)Gabe Black
These files aren't a collection of miscellaneous stuff, they're the definition of the Logger interface, and a few utility macros for calling into that interface (panic, warn, etc.). Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1 Reviewed-on: https://gem5-review.googlesource.com/6226 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Gabe Black <gabeblack@google.com>
2017-08-08mem-cache: Delete squashed HWPrefetchesPau Cabre
Request and Packet for squashed HWPrefetches were not deleted Change-Id: I9b66bb01b8ed6a5ddfaaa8739a68165dc4a7006c Signed-off-by: Pau Cabre <pau.cabre@metempsy.com> Reviewed-on: https://gem5-review.googlesource.com/4340 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-06-27mem-cache: Add missing overrides to BaseCacheAndreas Sandberg
Change-Id: I6a3a57e3067c247bd6ce6f01ac9459883f4aae2c Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3880 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-06-20mem: Replace EventWrapper use with EventFunctionWrapperSean Wilson
NOTE: With this change there is a possibility for `DRAMCtrl::Rank`s event names to not properly match the rank they were generated by. This could occur if the public rank member is modified after the Rank's construction. A patch would mean refactoring Rank and `DRAMCtrl`b to privatize many of the members of Rank behind getters. Change-Id: I7b8bd15086f4ffdfd3f40be4aeddac5e786fd78e Signed-off-by: Sean Wilson <spwilson2@wisc.edu> Reviewed-on: https://gem5-review.googlesource.com/3745 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2017-03-03mem: Make blkAlign a common function between all tag classesNikos Nikoleris
blkAlign was defined as a separate function in the base associative and fully-associative tags classes although both functions implemented identical functionality. This patch moves the blkAlign in the base tags class. Change-Id: I3d415d0e62bddeec7ce0d559667e40a8c5fdc2d4 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2017-03-03mem: Use pkt::getBlockAddr instead of BaseCace::blockAlignNikos Nikoleris
Change-Id: I0ed4e528cb750a323facdc811dde7f0ed1ff228e Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2017-02-21mem: Remove unused size field from the CacheBlk classNikos Nikoleris
Change-Id: I6149290d6d2ac1a4bd6165871c93d7b7d6a980ad Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Remove the unused asid field from the CacheBlk classNikos Nikoleris
Change-Id: I29f45733c5fad822bdd0d8dcc7939d86b2e8c97b Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Remove unused arguments (asid/contex_id) from accessBlockNikos Nikoleris
Change-Id: I79c2662fc81630ab321db8a75be6cd15fa07d372 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Remove unused type BlkList from the cache and the tagsNikos Nikoleris
Change-Id: If9ebb8488e8db587482ecfa99d2c12cfe5734fb9 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Remove unused functions from the tag classesNikos Nikoleris
Change-Id: I4f3c2c027b1acaaf791a4c71086f34a9b9fbf4df Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Always use the helper function to invalidate a blockNikos Nikoleris
Policies like the LRU need to be notified when a block is invalidated, the helper function does this along with invalidating the block. Change-Id: I3ed59cf07938caa7f394ee6054b0af9e00b267ea Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Fix MSHR assert triggering for invalidated prefetchesSascha Bischoff
This changeset updates an assert in src/mem/cache/mshr.cc which was erroneously catching invalidated prefetch requests. These requests can become invalidated if another component writes (an exclusive access) to this location during the time that the read request is in flight. The original assert made the assumption that these cases can only occur for reads generated by the CPU, and hence prefetcher-generated requests would sometimes trip the assert. Change-Id: If4f043273a688c2bab8f7a641192a2b583e7b20e Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Populate the secure flag in the writeback visitorNikos Nikoleris
Previously the writeback visitor would not consider and set the secure flag for the blocks that are written back to memory. This patch fixes this. Change-Id: Ie1a425fa9211407a70a4343f2c6b3d073371378f Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-21mem: Remove stale argument from a panic statementNikos Nikoleris
Change-Id: I7ae5fa44a937f641a2ddd242a49e0cd23f68b9f2 Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-02-19sim: Ensure draining is deterministicAndreas Hansson
The traversal of drainable objects could potentially be non-deterministic when using an unordered set containing object pointers. To ensure that the iteration is deterministic, we switch to a vector. Note that the lookup and traversal of the drainable objects is not performance critical, so the change has no negative consequences.
2017-02-19mem: Ensure deferred snoops are cache-line alignedAndreas Hansson
This patch fixes a bug where a deferred snoop ended up being to a partial cache line, and not cache-line aligned, all due to how we copy the packet.
2017-02-11mem: fix printing of 1st cache tags lineBjoern A. Zeeb
Rather than having the 1st line on the Log line and every other line on its own, add a new line to have a common format for all of them. Makes parsing a lot easier. Reviewed at http://reviews.gem5.org/r/3808/ Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
2016-11-09style: [patch 3/22] reduce include dependencies in some headersBrandon Potter
Used cppclean to help identify useless includes and removed them. This involved erroneously included headers, but also cases where forward declarations could have been used rather than a full include.
2016-11-09style: [patch 1/22] use /r/3648/ to reorganize includesBrandon Potter
2016-12-05mem: Respond to InvalidateReq when the block is (pending) dirtyNikos Nikoleris
Previously when an InvalidateReq snooped a cache with a dirty block or a pending modified MSHR, it would invalidate the block or set the postInv flag. The cache would not send an InvalidateResp. though, causing memory order violations. This patches changes this behavior, making the cache with the dirty block or pending modified MSHR the ordering point. Change-Id: Ib4c31012f4f6693ffb137cd77258b160fbc239ca Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2016-12-05mem: Invalidate a blk when servicing the 1st invalidating targetNikos Nikoleris
Previously an MSHR with one or more invalidating targets would first service all targets in the MSHR TargetList and then invalidate the block. As a result any service snooping targets would lookup in the cache and incorrectly find the block. This patch forces the invalidation to happen when the first invalidating target is encountered. Change-Id: I9df15de24e1d351cd96f5a2c424d9a03d81c2cce Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2016-12-05mem: Allow non invalidating snoops on an InvalidateReq MSHRNikos Nikoleris
This patch changes an assertion that previously assumed that a non invalidating snoop request should never be serviced by an InvalidateReq MSHR. The MSHR serves as the ordering point for the snooping packet. When the InvalidateResp reaches the cache the snooping packet snoops the caches above to find the requested block. One or more of the caches above will have the block since earlier it has seen a WriteLineReq. Change-Id: I0c147c8b5d5019e18bd34adf9af0fccfe431ae07 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2016-12-05mem: Always use InvalidateReq to service WriteLineReq missesNikos Nikoleris
Previously, a WriteLineReq that missed in a cache would send out an InvalidateReq if the block lookup failed or an UpgradeReq if the block lookup succeeded but the block had sharers. This changes ensures that a WriteLineReq always sends an InvalidateReq to invalidate all copies of the block and satisfy the WriteLineReq. Change-Id: I207ff5b267663abf02bc0b08aeadde69ad81be61 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
2016-12-05mem: Ensure InvalidateReq is considered isForward by MSHRsAndreas Hansson
This patch fixes an issue where an MSHR would incorrectly be perceived to provide data to targets arriving after an InvalidateReq. To address this the InvalidateReq is now treated as isForward, much like an UpgradeReq that did not hit in the cache. Change-Id: Ia878444d949539b5c33fd19f3e12b0b8a872275e Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
2016-12-05mem: Make packet debug printing more uniformNikos Nikoleris
Previously DPRINTFs printing information about a packet would use ad hoc formats. This patch changes all DPRINTFs to use the print function defined by the packet class, making the packet printing format more uniform and easier to change. Change-Id: Idd436a9758d4bf70c86a574d524648b2a2580970 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
2016-12-05mem: Service only the 1st FromCPU MSHR target on ReadRespWithInvNikos Nikoleris
A response to a ReadReq can either be a ReadResp or a ReadRespWithInvalidate. As we add targets to an MSHR for a ReadReq we assume that the response will be a ReadResp. When the response is invalidating (ReadRespWithInvalidate) servicing more than one targets can potentially violate the memory ordering. This change fixes the way we handle a ReadRespWithInvalidate. When a cache receives a ReadRespWithInvalidate we service only the first FromCPU target and all the FromSnoop targets from the MSHR target list. The rest of the FromCPU targets are deferred and serviced by a new request. Change-Id: I75c30c268851987ee5f8644acb46f440b4eeeec2 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
2016-12-05mem: Keep track of allocOnFill in the TargetListNikos Nikoleris
Previously the information of whether a response was allocating or not was a property of the MSHR. This change makes this flag a property of the TargetList. Differernt TargetLists, e.g. the targets and the deferred targets lists might have different values. Additionally, the information about whether each of the target expects an allocating response is stored inside the TargetList container. This allows for repopulating the flag in case some of the targets are removed. Change-Id: If3ec2516992f42a6d9da907009ffe3ab8d0d2021 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
2016-12-05mem: Add support for repopulating the flags of an MSHR TargetListNikos Nikoleris
This patch adds support for repopulating the flags of an MSHR TargetList. The added functionality makes it possible to remove targets from a TargetList without leaving it in an inconsistent state. Change-Id: I3f7a8e97bfd3e2e49bebad056d11bbfb087aad91 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
2016-11-30mem: Split the hit_latency into tag_latency and data_latencySophiane Senni
If the cache access mode is parallel, i.e. "sequential_access" parameter is set to "False", tags and data are accessed in parallel. Therefore, the hit_latency is the maximum latency between tag_latency and data_latency. On the other hand, if the cache access mode is sequential, i.e. "sequential_access" parameter is set to "True", tags and data are accessed sequentially. Therefore, the hit_latency is the sum of tag_latency plus data_latency. Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
2016-08-15mem: Print an MSHR without triggering any assertionsNikos Nikoleris
Previously printing an mshr would trigger an assertion if the MSHR was not in service or if the targets list was empty. This patch changes the print function to bypasses the accessor functions for postInvalidate and postDowngrade and avoid the relevant assertions. It also checks if the targets list is empty before calling print on it. Change-Id: Ic18bee6cb088f63976112eba40e89501237cfe62 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-08-12mem: Update mostly exclusive policy even furtherAndreas Hansson
This patch takes yet another step in maintaining the clusivity, in that it allows a mostly-inclusive cache to hold on to blocks even when responding to a ReadExReq or UpgradeReq. Previously the cache simply invalidated these blocks, but there is no strict need to do so. The most important part of this patch is that we simply mark the block clean when satisfying the upstream request where the cache is allowed to keep the block. The only tricky part of the patch is in the memory management of deferred snoops, where we need to distinguish the cases where only the packet was copied (we expected to respond), and the cases where we created an entirely new packet and request (we kept it only to replay later). The code in satisfyRequest is definitely ready for some refactoring after this. Change-Id: I201ddc7b2582eaa46fb8cff0c7ad09e02d64b0fc Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
2016-08-12mem: Update mostly exclusive cache policy to cover more casesAndreas Hansson
This patch changes how the mostly exclusive policy is enforced to ensure that we drop blocks when we should. As part of this change, the actual invalidation due to the clusivity enforcement is moved outside the hit handling, to a separate method maintainClusivity. For the timing mode that means we can deal with all MSHR targets before taking any action and possibly dropping the block. The method satisfyCpuSideRequest is also renamed satisfyRequest as part of this change (since we only ever see requests from the cpu-side port). Change-Id: If6f3d1e0c3e7be9a67b72a55e4fc2ec4a90fd3d2 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
2016-08-12mem: Add a FromCache packet attributeAndreas Hansson
This patch adds a FromCache attribute to the packet, and updates a number of the existing request commands to reflect that the request originates from a cache. The attribute simplifies checking if a requests came from a cache or not, and this is used by both the cache and snoop filter in follow-on patches. Change-Id: Ib0a7a080bbe4d6036ddd84b46fd45bc7eb41cd8f Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Steve Reinhardt <stever@gmail.com>
2016-07-11mem: Remove stale argument from a DPRINTF in the cache codeNikos Nikoleris
Change-Id: I70dd11c23b45dfc606ef08233d2e50fcc0817505 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-06-06sim: Call regStats of base-class as wellStephan Diestelhorst
We want to extend the stats of objects hierarchically and thus it is necessary to register the statistics of the base-class(es), as well. For now, these are empty, but generic stats will be added there. Patch originally provided by Akash Bagdia at ARM Ltd.
2016-05-26mem: Fix memory leak in handling of deferred snoopsAndreas Hansson
This patch fixes a memory leak where deferred snoop packets never got deallocated. On the call to MSHR::handleSnoop these snoops were treated as if a response will be sent, as the MSHR was pendingModified. Consequently, a copy of the packet was created and added to the MSHR targets. However, an preceeding target to the same MSHR, originally from a CPU, was serviced before the snoop, and caused the block to be invalidated. This happens for ReadExReq and UpgradeReq. Note that the original snoop will receive a response, just not from the cache in question, but instead from the cache upstream that issued the ReadExReq or UpgradeReq. Change-Id: I4ac012fbc8a46cf693ca390fe9476105d444e6f4 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
2016-05-26mem: Do not set cacheResponding on MSHR snoop if not respondingAndreas Hansson
This patch changes the flow control for HSHR::handleSnoop to ensure that we only set cacheResponding on the snoop packet if we are actually responding. This avoids situations where a responder is stalling indefinitely on a response that never arrives. Change-Id: I691dd01755b614b30203581aa74fc743b350eacc Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
2016-05-26mem: fix headers include order in the cache related classesNikos Nikoleris
Change-Id: Ia57cc104978861ab342720654e408dbbfcbe4b69 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 08:46:52 +0000