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
