Oh I mean ... since the memory latencies are sort of a best guess of the average, I would just kind of a pick a small number for that number instead of MEM_LATENCY.
Typically, the requests would stream out back to back. With a DDR3 part that would take 4 memory clock cycles to get the data burst + a few cycles for the precharge to close out the row. Assuming say a 3:1 CPU:Memory clock, something like 15-20 cycles sounds reasonable to me. I don't think there's any reason to make it more complex than that (that's what DRAMSim2 is for :) ) -Paul On Fri, Jan 14, 2011 at 3:52 PM, avadh patel <[email protected]> wrote: > Thanks Paul. > Thats a great find. Do you have any quick fix for this issue? If you have a > logic how to fix it let me know I can code it up. > > Thanks, > Avadh > > On Thu, Jan 13, 2011 at 10:58 PM, DRAM Ninjas <[email protected]>wrote: > >> Nope, sorry, I was right the first time. The scheduling of >> access_completed is MEM_LATENCY cycles after the current request is already >> done.... And I think that's way too long of a latency. >> >> >> On Thu, Jan 13, 2011 at 6:16 PM, DRAM Ninjas <[email protected]>wrote: >> >>> Oh wait, I see my error.... the access is scheduled from the same cycle + >>> MEM_LATENCY so really they just complete together ... >>> >>> Ugh, nevermind. >>> >>> On Thu, Jan 13, 2011 at 6:14 PM, DRAM Ninjas <[email protected]>wrote: >>> >>>> I was reading through the memory controller code and in >>>> MemoryController::access_completed_cb(), I noticed this (line numbers may >>>> not match up correctly since this is in a modified branch): >>>> >>>> 199 /* >>>> 200 * Now check if we still have pending requests >>>> 201 * for the same bank >>>> 202 */ >>>> 203 MemoryQueueEntry* entry; >>>> 204 foreach_list_mutable(pendingRequests_.list(), entry, entry_t, >>>> 205 prev_t) { >>>> 206 int bank_no_2 = get_bank_id(entry->request-> >>>> 207 get_physical_address()); >>>> 208 if(bank_no == bank_no_2 && entry->inUse == false) { >>>> 209 entry->inUse = true; >>>> 210 >>>> *211 memoryHierarchy_->add_event(&accessCompleted_, >>>> 212 MEM_LATENCY, entry);* >>>> 213 banksUsed_[bank_no] = 1; >>>> 214 break; >>>> 215 } >>>> 216 } >>>> >>>> >>>> In other words, traverse the pending queue looking for things that are >>>> going to the same bank -- which is fine as far as a simple memory model >>>> goes. However, I would think that if such an entry is found, it should not >>>> have to incur a full MEM_LATENCY penalty for completing the request (lines >>>> 211-212). I think as far as DRAM goes, if something is sitting in a pending >>>> queue that can be sent to an open row, a memory controller would be able to >>>> schedule that request so it completes almost back to back with the previous >>>> request ... maybe like 5-10 cycles instead of 100 cycles. >>>> >>>> Thoughts? >>>> >>>> >>>> >>> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
