Hi Prathap, It sounds like something is going wrong in your write-switching algorithm. Have you verified that a read is actually showing up when you think it is?
If needed, is there any chance you could post the patch on RB, or include the changes in a mail? Andreas From: gem5-users <[email protected]<mailto:[email protected]>> on behalf of Prathap Kolakkampadath <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Thursday, 16 July 2015 00:36 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] DRAMCtrl: Question on read/write draining while not using the write threshold. Hello Users, I have experimented by modifying the DRAM Controller write draining algorithm in such a way that, the DRAM Controller always process reads and switch to writes only when the read queue is empty; controller switch from writes to read immediately when a read arrives in the read queue. With this modification, i ran a very memory intensive test on four cores simultaneously. Each miss generates a read(line-fill) and write(write back) to DRAM. First, I brief what i am expecting: DRAM controller continue to process reads; meanwhile DRAM write queue fills up and eventually fills up the write buffers in the cache and therefore LLC locks up, therefore, no further reads and writes to the DRAM from the core. At this point, DRAM controller process reads until the read queue is empty and switches to write and starts processing writes until a new read request arrives. Note that the LLC is blocked at this moment. Once a write is processed and corresponding write buffer of cache is cleared, a core can generate a new miss(which generates a line fill first). During this round trip time(as observed in my system 45ns and tBURST is 7.5ns), the DRAM controller can process almost 6 requests(45/7.5). After which it should switch to read. However, from the gem5 statistics, I observe that the mean writes_per_turn around is 30 instead of ~6. I don't understand why this is the case? Can someone help me in understanding this behaviour? 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
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
