Hi Prathap,
As I already mentioned, the controller achieves close to the theoretical max,
and if there were unnecessary bubbles this would not be the case. Remember that
the controller is event driven and that the calculations are based on the
constraints (bus, bank availability etc).
If you want to see a command trace, the easiest is to enable the DRAMPower flag
as all the PRE, ACT, RD, WR calls are made with the appropriate time stamp.
If it is truly a bug, please post a fix. At this point I am not sure anything
is really wrong.
Andreas
From: Tao Zhang <tao.zhang.0...@gmail.com<mailto:tao.zhang.0...@gmail.com>>
Date: Friday, November 14, 2014 at 11:37 PM
To: Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>>,
gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Cc: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Subject: Re: [gem5-users] DRAMCTRL:Seeing an unusual behaviuor with FR-FCFS
scheduler
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<mailto: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<mailto: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<mailto:kvprat...@gmail.com>>
Date: Friday, November 14, 2014 at 10:37 PM
To: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Cc: gem5 users mailing list <gem5-users@gem5.org<mailto: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<mailto: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<mailto:gem5-users@gem5.org>>
Reply-To: Prathap Kolakkampadath
<kvprat...@gmail.com<mailto:kvprat...@gmail.com>>, gem5 users mailing list
<gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Date: Friday, 14 November 2014 00:11
To: gem5 users mailing list <gem5-users@gem5.org<mailto: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<mailto: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.
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
