Prathap,
Based on your observation, the activation scheduling seems not doing the
best. When data is streamed out from one bank, another bank should be
activated in advance (don't need to wait the complete of the current data
streaming) to make sure there is no bubbles on the data bus. Can you print
out the DRAM commands on the C/A bus? This will be helpful to probe it.
-Tao
On Fri, Nov 14, 2014 at 3:19 PM, Prathap Kolakkampadath via gem5-users <
gem5-users@gem5.org> wrote:
> Hi Andreas,
>
> As you said it shouldn't have to switch to another bank which doesn't has
> a row hit. However if there is request in queue which is not row hit when
> it enters the queue, has to become row hit after time tRP+tRCD. Then this
> request will be scheduled according to FR-FCFS ahead of subsequent requests
> in the queue which are also row hits to another bank. However in the
> current code, activate and precharge is issued to a request in queue only
> if there are no more row hits in the queue. Does this makes sense?
>
> Thanks,
> Prathap
>
> On Fri, Nov 14, 2014 at 4:54 PM, Andreas Hansson <andreas.hans...@arm.com>
> wrote:
>
>> Hi Prathap,
>>
>> I am not sure I understand what you think is wrong here. If there are
>> row hits, why should the controller switch to another bank (except to avoid
>> starvation etc)?
>>
>> It will switch once there are no row hits or the limit on in-row-hits
>> is reached, and at that point it will switch to the request that is first
>> ready, or FCFS if there is more than one that would be ready at the same
>> time. Note that there are also constraints like tRRD etc that have to be
>> respected.
>>
>> If you want to study the behaviour on a larger scale, you can have a
>> look at util/dram_sweep_plot.py (you need to run config/dram/sweep.py first
>> for a given memory config), and look at the efficiency of the controller
>> across a range of in-row-hits and bank parallelism. For the entire 3D
>> surface the controller achieves a throughput in the order of 95% of what an
>> oracle scheduler would.
>>
>> Andreas
>>
>> From: Prathap Kolakkampadath <kvprat...@gmail.com>
>> Date: Friday, November 14, 2014 at 10:37 PM
>> To: Andreas Hansson <andreas.hans...@arm.com>
>> Cc: gem5 users mailing list <gem5-users@gem5.org>
>> Subject: Re: [gem5-users] DRAMCTRL:Seeing an unusual behaviuor with
>> FR-FCFS scheduler
>>
>> Hello Andreas,
>>
>> The above patch doesn't affect my scenario on a single rank. However, i
>> suspect there is a bug in the FR-FCFS implementation in gem5.
>> Looks like, the requests are not overlapping. Precharge and/or activate
>> has to be issued once a memory request entered the queue. So in a queue,
>> if there are few ahead read requests and few following
>> read requests all targeting to a same row in Bank0 to a read request
>> which targets Bank1 and not a row hit. Worst case delay for Bank1 request
>> should be tRP+rRCD. After this delay Bank1 request should also become a row
>> hit (after the precharge and activate). However according to current
>> implementation the request to Bank1 is served only after all the ahead and
>> following row hits are done, as these timing parameters are set in
>> doDRAMAccess(), which is called after reordering the queue.
>>
>> Is this observation looks correct?
>>
>> Thanks,
>> Prathap
>>
>> On Fri, Nov 14, 2014 at 8:45 AM, Andreas Hansson <andreas.hans...@arm.com
>> > wrote:
>>
>>> Hi Prathap,
>>>
>>> It would very well be a bug. We have got a small fix for the FRFCFS
>>> about to go out (but it should not affect your scenario assuming It is a
>>> single rank):
>>>
>>> diff --git a/src/mem/dram_ctrl.cc b/src/mem/dram_ctrl.cc
>>> --- a/src/mem/dram_ctrl.cc
>>> +++ b/src/mem/dram_ctrl.cc
>>> @@ -1483,8 +1489,8 @@
>>> // 1) Commands that access the same rank as previous burst
>>> // and can prep the bank seamlessly.
>>> // 2) Commands (any rank) with earliest bank prep
>>> - if (!switched_cmd_type && same_rank_match &&
>>> - min_act_at_same_rank <= min_cmd_at) {
>>> + if ((bank_mask == 0) || (!switched_cmd_type && same_rank_match &&
>>> + min_act_at_same_rank <= min_cmd_at)) {
>>> bank_mask = bank_mask_same_rank;
>>> }
>>>
>>> Could you give that a spin?
>>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>> From: Prathap Kolakkampadath via gem5-users <gem5-users@gem5.org>
>>> Reply-To: Prathap Kolakkampadath <kvprat...@gmail.com>, gem5 users
>>> mailing list <gem5-users@gem5.org>
>>> Date: Friday, 14 November 2014 00:11
>>> To: gem5 users mailing list <gem5-users@gem5.org>
>>> Subject: [gem5-users] DRAMCTRL:Seeing an unusual behaviuor with FR-FCFS
>>> scheduler
>>>
>>> Hi Users,
>>>
>>> For the following scenario:
>>>
>>>
>>> Read0 Read1 Read2 Read3 Read4 Read5 Read6 Read7 Read8 Read9 Read10
>>> Read11
>>>
>>> There are 12 reads in the read queue numbered in the order of arrival.
>>> Read 0 to Read3 access same row of Bank1, Read4 access Bank0, Read5
>>> to Read8 access same row of Bank2 and Read9 to Read11 access same row of
>>> Bank3.
>>>
>>> According to FR-FCFS scheduler, even there is only a single request
>>> Read4 to Bank0, it should be scheduled after the Read0 to Read3 are
>>> scheduled. Because within the window of Read0-Read3, the Read4 would have
>>> done with precharge and activate and ready to schedule. Though Read5 and
>>> Read9 are also ready, Read4 needs to be scheduled as the next row hit,
>>> according to FCFS.
>>>
>>> However i see a different behaviour where Read4 is scheduled only
>>> after all other row hits to Bank2 and Bank3 is scheduled. Also i noticed
>>> from the debug prints that Read4 is not becoming a row_hit.
>>>
>>> Are we missing to mark the read as row hit after precharge and
>>> activate. I am trying to figure this out. Is my understanding correct?
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>>
>> -- 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-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
