Re: [gem5-dev] Review Request 2595: x86: Delay X86 table walk on receiving walker response
On Jan. 5, 2015, 10:48 p.m., Andreas Hansson wrote: Can you explain the sequence of events that result in bad behavior? If possible (which is not necessarily the case), it would be best to fix this without adding arbitrary delays. Andreas Hansson wrote: The crossbar is processing a response, and as part of that forward it to the next object, in this case the pagetable walker, and before the call to sendTimingResp is finished, the pagetable walker sends a new request back to the crossbar. This change ensures that the sendTimingResp is finished and done with before the request is sent. If you do not like the idea of sending it on the next clock edge we can also make it curTick(). Gabe Black wrote: curTick would be better I think. I feel like I've run into this sort of thing before, where I've wanted to do something inline but there were assumptions/expectations that it be done in a different call stack. I *think* we even had issues where we'd run out of stack when that looped back on itself too much under certain circumstances, but it may just be that that theoretically could happen but hadn't. In any case, it feels like there's a generic problem to be solved here, although not necessarily as part of what you're doing. Andreas Hansson wrote: The main reason I went for clockEdge rather than curTick is that it aligns the request sending with the CPU clock edges rather than the crossbar. If curTick is aligned with the CPU clock then clockEdge == curTick. Only if the response arrives in the middle of a CPU cycle will the request be delayed to the next edge. Makes sense? From an realism point of view I do not see how any sensible implementation would have a direct combinational path from receiving a response to sending a request (not that it has stopped us in other places in the code base). Gabe Black wrote: Yep, that makes sense. I will consider that a Ship it unless someone objects. - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2595/#review5724 --- On Jan. 5, 2015, 4:35 p.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2595/ --- (Updated Jan. 5, 2015, 4:35 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10643:30307bfe1e8c --- x86: Delay X86 table walk on receiving walker response This patch fixes a minor issue in the X86 page table walker where it ended up sending new request packets to the crossbar before the response processing was finished (recvTimingResp is directly calling sendTimingReq). Under certain conditions this caused the crossbar to see illegal combinations of request/response overlap, in turn causing problems with a slightly modified crossbar implementation. Diffs - src/arch/x86/pagetable_walker.hh 9ac724889705 src/arch/x86/pagetable_walker.cc 9ac724889705 Diff: http://reviews.gem5.org/r/2595/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Transition from RubyMemoryControl to DRAMCtrl?
Hi everyone, I am merely curious to know if we can prune the RubyMemoryControl (I’d like to minimise the number of subclasses that need modifications as AbstractMemory changes). As you are probably aware, the DRAMCtrl class has a GDDR5 config (as well as LPDDRx, DDRx, WideIOx), and is completely integrated with DRAMPower. We are also about to push out some further patches adding low-power-state control to the DRAMCtrl. I would think DRAMCtrl Pareto dominates the RubyMemoryControl by far, but I could be missing something. Thanks, Andreas -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2602: mem: Remove unused Packet src and dest fields
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2602/ --- Review request for Default. Repository: gem5 Description --- Changeset 10657:9fe25a9a8c8a --- mem: Remove unused Packet src and dest fields This patch takes the final step in removing the src and dest fields in the packet. These fields were rather confusing in that they only remember a single multiplexing component, and pushed the responsibility to the bridge and caches to store the fields in a senderstate, thus effectively creating a stack. With the recent changes to the crossbar response routing the crossbar is now responsible without relying on the packet fields. Thus, these variables are now unused and can be removed. Diffs - src/arch/x86/pagetable_walker.cc cd95d4d51659 src/mem/packet.hh cd95d4d51659 Diff: http://reviews.gem5.org/r/2602/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2601: mem: Remove Packet source from ForwardResponseRecord
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2601/ --- Review request for Default. Repository: gem5 Description --- Changeset 10656:851b58c59d0b --- mem: Remove Packet source from ForwardResponseRecord This patch removes the source field from the ForwardResponseRecord, but keeps the class as it is part of how the cache identifies responses to hardware prefetches that are snooped upwards. Diffs - src/mem/cache/cache_impl.hh cd95d4d51659 Diff: http://reviews.gem5.org/r/2601/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Transition from RubyMemoryControl to DRAMCtrl?
Hi Joel, Great. I’d be curious to know how it goes. Do you already have a timeline in mind? If there are any issues I am sure we’ll manage to work it out. Andreas On 12/01/2015 16:07, Joel Hestness via gem5-dev gem5-dev@gem5.org wrote: Hi Andreas, We (the gem5-gpu crew) are ok with this move. The big thing for us is that we'll need to adapt our public patches to use the DRAMCtrl rather than RubyMemoryControl. However, we've already planned to update the gem5-gpu-supported version of gem5, so we've started prepping to cross that bridge. Joel ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] simpoints and KVM
Hi Mike, I'm the one who wrote the initial version of the simpoint collection/generation a few years ago. I enforced the fastmem option primarily because I didn't see it necessary to simulate caches during simpoint generation and it made simulation faster. You can simply disable this and it should all still work. For the --cpu-type=atomic option, initially simpoints were hardcoded directly into the atomic CPU. Since then, they've been changed to use the probe system. However, a quick grep of the code shows the initialization for the SimPoint probe only exists in the atomic CPU. If you registered the probe point with the TimingCPU as well, then that should work (I think). On Mon, Jan 12, 2015 at 5:02 PM, mike upton via gem5-dev gem5-dev@gem5.org wrote: I am trying to enable simpoint generation with kvm enabled. Is there anything that inherently blocks this? Simpoints are currently enabled only with --fastmem and --cpu-type=atomic. How fundamental are each of these restrictions? Thanks, Mike ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Transition from RubyMemoryControl to DRAMCtrl?
Hi Andreas, We (the gem5-gpu crew) are ok with this move. The big thing for us is that we'll need to adapt our public patches to use the DRAMCtrl rather than RubyMemoryControl. However, we've already planned to update the gem5-gpu-supported version of gem5, so we've started prepping to cross that bridge. Joel ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
