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
