Hello Andreas, I don't quite understand, why updating the CAS to other banks only on RowHit request would break the "non-monotonic temporal order". I will try to post a fix on review board.
Thanks, Prathap On Wed, Nov 11, 2015 at 4:17 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > Let me first reiterate that I don’t think this would ever be a problem in > a realistic scenario (the tree arguments from before), but it would be good > to quantify the impact. > > The “solution” in my view would need the controller to take decisions in a > non-monotonic temporal order, and that would also mean that the data bus > occupancy would have to be tracked as intervals rather than an end value. I > think the same holds try for the column (and other) constraints. Perhaps > the latter can be “tricked” by not updating it and relying on the other > constraints, but conceptually we would beed to track the start and end, not > just the end. Agreed? > > Andreas > > From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap > Kolakkampadath <kvprat...@gmail.com> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Wednesday, 11 November 2015 at 21:54 > > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Modelling command bus contention in DRAM > controller > > Hello Andreas, > > see my comments below. > > Thanks, > Prathap > > On Wed, Nov 11, 2015 at 12:59 PM, Andreas Hansson <andreas.hans...@arm.com > > wrote: > >> Hi Prathap, >> >> Ok, so for FCFS we are seeing the expected behaviour. Agreed? >> > > >> Agreed. Because CAS is ordered. > > >> >> I completely agree on the point of the ordered CAS, and for FR-FCFS we >> could indeed hit the case you describe. Additionally, the model makes >> scheduling decisions “conservatively” early (assuming it has to precharge >> the page), so there is also an inherent window where we decide to do >> something, and something else could show up in the meanwhile, which we >> would have chosen instead. >> > > >> I agree that we could fix this. The arguments against: 1) in any case, a >> real controller has a pipeline latency that will limit the visibility to >> the scheduler, so if the window is in the order of the “fronted pipeline >> latency” of the model then it’s not really a problem since we would have >> missed them in reality as well (admittedly here it is slightly longer), 2) >> with more things in the queues (typical case), the likelihood of having to >> make a bad decision because of this window is very small, 3) I fear it >> might add quite some complexity to account for these gaps (as opposed to >> just tracking next CAS), with a very small impact in most full-blown >> use-cases. >> > > >> I agree that this may not be an issue on larger use-cases, however > the implementation differs from how a real DRAM controllers schedules the > commands, where CAS can be reordered based > >> on the readiness of the respective Bank. > > >> >> It would be great to actually figure out if this is an issue on larger >> use-cases, and what the performance impact on the simulator is for fixing >> the issue. Will you take a stab at coding up a fix? >> > > >> I think this can be easily fixed by "updating the next CAS to banks, > only if the packet is a row hit". I believe this works assuming tRRD for > any DRAM module is greater than the CAS-CAS delay. > >> I did a fix and ran dram_sweep.py. There was absolutely no > difference in the performance, which was expected. > >> Presently i am not able to anticipate any other complexity. > > >> >> Andreas >> >> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap >> Kolakkampadath <kvprat...@gmail.com> >> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >> Date: Wednesday, 11 November 2015 at 18:47 >> >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >> controller >> >> Hello Andreas, >> >> Please see my comments below >> >> Thanks, >> Prathap >> >> On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson < >> andreas.hans...@arm.com> wrote: >> >>> Hi Prathap, >>> >>> I don’t quite understand the statement about the second CAS being issued >>> before the first one. FCFS by construction won’t do that (in any case, >>> please do not use FCFS for anything besides debugging, it’s really not >>> representative). >>> >> >> >>>> This could happen even in fr-fcfs, incase a hit request arrives soon >> after a miss request has been selected by the scheduler. >> >>> >>> The latency you quote for access (2), is that taking the colAllowedAt >>> and busBusyUntil into account? Remember that doDRAMAccess is not >>> necessarily coinciding with then this access actually starts. >>> >> >> >>>> My point here is a CAS to a bank has to be issued as soon as the >> bank is available. In that case, the request 2 should be ready before >> request one. However, in the current implementation, "all CAS are strictly >> ordered". >> >>> >>> It could very well be that there is a bug, and if there is we should get >>> it sorted. >>> >> >>>> I believe that this could be a bug. >> >>> >>> Andreas >>> >>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap >>> Kolakkampadath <kvprat...@gmail.com> >>> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >>> Date: Wednesday, 11 November 2015 at 17:43 >>> >>> To: gem5 users mailing list <gem5-users@gem5.org> >>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >>> controller >>> >>> Hello Andreas, >>> >>> I believe it is restrictive. >>> Below is the DRAM trace under fcfs scheduler for two requests, where >>> first request is a RowMiss request to Bank0 >>> and second request is a RowHit request to Bank1. >>> >>> 1) *Memory access latency of first miss request*. >>> From the trace, the Memory access latency of the first miss request >>> is 52.5ns (tRP(15) + tRCD(15) + tCL(15) + tBURST(7.5)). >>> This is expected. >>> 2) *Memory access latency of second request, which is a Hit to a >>> different Bank.* >>> From the trace, the memory access latency for the second request is >>> also 52.5ns >>> This is unexpected. CAS of this ready request should have issued >>> before the CAS of the first Miss request. >>> >>> In doDRAMAccess() the miss request is updating the next read/write burst >>> of all banks, thus the CAS of Ready request >>> can now be issued only after the CAS of the Miss Request. >>> >>> 321190719635810: system.mem_ctrls: Timing access to addr 4291233984, >>> rank/bank/row 0 0 65422 >>> 321190719635810: system.mem_ctrls: RowMiss:READ >>> 321190719635810: system.mem_ctrls: Access to 4291233984, ready at >>> 321190719688310 bus busy until 321190719688310. >>> 321190719643310: system.mem_ctrls: Timing access to addr 3983119872, >>> rank/bank/row 0 1 56019 >>> 321190719643310: system.mem_ctrls: RowHit:READ >>> 321190719643310: system.mem_ctrls: Access to 3983119872, ready at >>> 321190719695810 bus busy until 321190719695810. >>> >>> Please let me know what you think. >>> >>> Thanks, >>> Prathap >>> >>> >>> On Wed, Nov 11, 2015 at 3:00 AM, Andreas Hansson < >>> andreas.hans...@arm.com> wrote: >>> >>>> Hi Prathap, >>>> >>>> Could you elaborate on why you think this line is causing problems. It >>>> sounds like you are suggesting this line is too restrictive? >>>> >>>> It simply enforces a minimum col-to-col timing, there could still be >>>> other constraints that are more restrictive. >>>> >>>> Andreas >>>> >>>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap >>>> Kolakkampadath <kvprat...@gmail.com> >>>> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >>>> Date: Tuesday, 10 November 2015 at 21:30 >>>> >>>> To: gem5 users mailing list <gem5-users@gem5.org> >>>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >>>> controller >>>> >>>> Hi Andreas, >>>> >>>> To be more precise, I believe the below code snippet in doDRAMAccess(), >>>> should be called only for the Row Hit request. For a Row Miss request why >>>> do we have to update the bank.colAllowedAt for all the Banks? >>>> >>>> // update the time for the next read/write burst for each >>>> >>>> // bank (add a max with tCCD/tCCD_L here) >>>> >>>> ranks[j]->banks[i].colAllowedAt = std::max(cmd_at + >>>> cmd_dly,ranks[j]->banks[i].colAllowedAt) >>>> >>>> >>>> Thanks, >>>> >>>> Prathap >>>> >>>> >>>> >>>> On Tue, Nov 10, 2015 at 12:13 PM, Prathap Kolakkampadath < >>>> kvprat...@gmail.com> wrote: >>>> >>>>> Hi Andreas, >>>>> >>>>> As you said all the act-act are taken in to account. >>>>> All col-to-col is taken in to account except, if there is a open >>>>> request(Hit) after a closed request(Miss). >>>>> If i am using* FCFS* scheduler, and there are two requests in the >>>>> queue Request1 and Request2 like below, according >>>>> to the current implementation CAS of Request2 is only issued after CAS >>>>> of Request1. Is that correct? >>>>> I don't see in doDramAccess(), where the CAS of second request is >>>>> updated ahead of CAS of first request. >>>>> >>>>> *Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS)* >>>>> >>>>> Could you please clarify? >>>>> >>>>> I will also take a look into the util/dram_sweep_plot.py. >>>>> >>>>> Thanks, >>>>> Prathap >>>>> >>>>> On Tue, Nov 10, 2015 at 9:41 AM, Andreas Hansson < >>>>> andreas.hans...@arm.com> wrote: >>>>> >>>>>> Hi Prathap, >>>>>> >>>>>> All the col-to-col, act-to-act etc are taken into account, just not >>>>>> command-bus contention. Have a look at util/dram_sweep_plot.py for a >>>>>> graphical “test bench” for the DRAM controller. As you will see, it never >>>>>> exceeds the theoretical max. This script relies on the >>>>>> configs/dram/sweep.py for the actual generation of data. >>>>>> >>>>>> Andreas >>>>>> >>>>>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap >>>>>> Kolakkampadath <kvprat...@gmail.com> >>>>>> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >>>>>> Date: Monday, 9 November 2015 at 21:53 >>>>>> To: gem5 users mailing list <gem5-users@gem5.org> >>>>>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >>>>>> controller >>>>>> >>>>>> Hello Andreas, >>>>>> >>>>>> One problem could be when there is a Miss request followed by a Hit >>>>>> request. Taking the below example, initially queue has only one request >>>>>> R1(Miss), as soon as the this request is selected there >>>>>> is another request in the queue R2(Hit). Here CAS of R2 is ready and >>>>>> can be issued right away in the next clock cycle. However, i believe in >>>>>> the simulator, while it computes the ready time of R1, it also recomputes >>>>>> the >>>>>> next CAS that can be issued to other Banks. Thus the CAS of R2 can >>>>>> now be issued only after the CAS of R1. If i am right, this could be a >>>>>> problem? >>>>>> >>>>>> Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) >>>>>> >>>>>> Thanks, >>>>>> Prathap >>>>>> >>>>>> On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson < >>>>>> andreas.hans...@arm.com> wrote: >>>>>> >>>>>>> Hi Prathap, >>>>>>> >>>>>>> Command-bus contention is intentionally not modelled. The main >>>>>>> reason for this is to keep the model performant. Moreover, in real >>>>>>> devices >>>>>>> the command bus is typically designed to _not_ be a bottleneck. >>>>>>> Admittedly >>>>>>> this choice could be reassessed if needed. >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap >>>>>>> Kolakkampadath <kvprat...@gmail.com> >>>>>>> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >>>>>>> Date: Monday, 9 November 2015 at 18:25 >>>>>>> To: gem5 users mailing list <gem5-users@gem5.org> >>>>>>> Subject: [gem5-users] Modelling command bus contention in DRAM >>>>>>> controller >>>>>>> >>>>>>> >>>>>>> Hello Users, >>>>>>> >>>>>>> After closely looking at the doDRAMAccess() of dram controller >>>>>>> implementation in GEM5, i suspect that the current implementation may >>>>>>> not >>>>>>> be taking in to account the command bus contention that could happen if >>>>>>> DRAM timing constraints take particular values. >>>>>>> >>>>>>> For example in the below scenario, the queue has two closed requests >>>>>>> one to Bank1 and other to Bank2. >>>>>>> >>>>>>> Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) >>>>>>> >>>>>>> Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 >>>>>>> cycles). In this case ACT of R2 and CAS of R1 becomes active at the same >>>>>>> time. >>>>>>> At this point one command needs to be delayed by one clock cycle. I >>>>>>> don't see how simulator is handling this? If the simulator is handling >>>>>>> this, could someone please point me to the code snippet where this is >>>>>>> handled. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Prathap >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> -- 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-users mailing list >>>>>>> gem5-users@gem5.org >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> -- 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-users mailing list >>>>>> gem5-users@gem5.org >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>> >>>>> >>>>> >>>> >>>> ------------------------------ >>>> >>>> -- 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-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> ------------------------------ >>> >>> -- 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-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> ------------------------------ >> >> -- 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-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > ------------------------------ > > -- 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-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
