Do not merge requests and responses in completers#682
Open
akihikodaki wants to merge 3 commits intoChampSim:developfrom
Open
Do not merge requests and responses in completers#682akihikodaki wants to merge 3 commits intoChampSim:developfrom
akihikodaki wants to merge 3 commits intoChampSim:developfrom
Conversation
CACHE and DRAM_CHANNEL merge requests and return a response for each group of merged packets, saving their bandwidth. In my understanding, it is unrealistic to save bandwidth this way because a requester will need to search all requests in its queue and update them at once. BOOMv3, an open-source processor, does not seem to implement it either. Return responses for all merged packets in a group and make sure all of them consume the bandwidth.
O3_CPU, CACHE, and PageTableWalker finishes multiple memory requests at once if their lower levels return one response witch a matching address. In my understanding, finishing multiple memory requests at once is difficult for hardware as it requires to search all requests in queues and update them at once. BOOMv3, an open-source processor, does not seem to have such a behavior. Change these classes to finish only one memory request for each response.
PageTableWalker::mshr_type::to_return always has zero or one element so change its type from std::vector<std::deque<response_type>*> to std::deque<response_type>* to save extra dynamic memory allocations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a follow-up of #618.
Traditionally, ChampSim had several mechanisms to merge memory transactions. This duplication of merging operations makes it complicated to instrument for Kanata, an instruction pipeline visualizer (please also see #594). Even without Kanata, it adds extra code complexity and hurts simulation accuracy because the cost of duplicate merging operations are not accounted.
A path of memory transaction in ChampSim can be understood as it consists of the following:
#618 removed duplicate merging operations in channel (2). This pull request removes merging operations in completers (3). In other words, this pull request ensures that the requester always sees one response for each request it makes, just as a real hardware protocol like AXI do.
With this change, merging will only happen at the requester. More concretely,
O3_CPUfetches multiple instructions with one request.CACHEallocates an MSHR for multiple upstream requests with overlapping addresses and issues one corresponding request to the downstream.As I have done in #618, I evaluated the changes with the DPC-3 traces:
https://github.dev/akihikodaki/e/blob/fd8e72e83fa95aa41e308de2d7c4e0b148478778/stats.ipynb
The "timeline" column at the bottom left allows you to compare commits.
Notably, commit d048f26 dramatically reduced the IPC by about 4 %. This is because the bandwidth consumption for responses that used to be merged is now properly modeled.