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 <[email protected]<mailto:[email protected]>>
Date: Friday, November 14, 2014 at 10:37 PM
To: Andreas Hansson <[email protected]<mailto:[email protected]>>
Cc: gem5 users mailing list <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
Reply-To: Prathap Kolakkampadath
<[email protected]<mailto:[email protected]>>, gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Friday, 14 November 2014 00:11
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
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
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
