[gem5-users] Question on retry requests due to write queue full.
Hello Users, I am using classic memory system with following DRAM controller parameters write_buffer_size = 64 write_high_thresh_perc = 85 write_low_thresh_perc = 50 min_writes_per_switch =18 According to write draining algorithm, the bus has to turn around to writes when the writeQueue.size() writeHighThreshold. However when i run some memory intensive benchmarks, i get a high number of Write retry requests because the write queue is full, as reported in the gem5 statistics. # Number of times write queue was full causing retry system.mem_ctrls.numWrRetry183731 I am not sure how this could happen, as the DRAM controller drain writes in a batch whenever the write queue size grows beyond the high threshold, which is only 85% of Write Buffer Size. Is this expected? Thanks, Prathap ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question on retry requests due to write queue full.
I think if the benchmark is write intensive, this could happen. When DRAM controller process writes, if there are many writes(cache evictions) arrives at a rate faster than the rate at which DRAM controller process writes. Thanks, Prathap On Tue, Jul 14, 2015 at 11:27 AM, Prathap Kolakkampadath kvprat...@gmail.com wrote: Hello Users, I am using classic memory system with following DRAM controller parameters write_buffer_size = 64 write_high_thresh_perc = 85 write_low_thresh_perc = 50 min_writes_per_switch =18 According to write draining algorithm, the bus has to turn around to writes when the writeQueue.size() writeHighThreshold. However when i run some memory intensive benchmarks, i get a high number of Write retry requests because the write queue is full, as reported in the gem5 statistics. # Number of times write queue was full causing retry system.mem_ctrls.numWrRetry183731 I am not sure how this could happen, as the DRAM controller drain writes in a batch whenever the write queue size grows beyond the high threshold, which is only 85% of Write Buffer Size. Is this expected? Thanks, Prathap ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question on retry requests due to write queue full.
Hello Andreas, I think that could b the case. I am running a very memory intensive synthetic benchmark, in every memory operation generates a read and write to DRAM. Thanks, Prathap On Tue, Jul 14, 2015 at 12:39 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, Your write are probably arriving faster than the controller can actually send them to the DRAM. What is it you’re running? Andreas From: gem5-users gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Tuesday, 14 July 2015 17:27 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Question on retry requests due to write queue full. Hello Users, I am using classic memory system with following DRAM controller parameters write_buffer_size = 64 write_high_thresh_perc = 85 write_low_thresh_perc = 50 min_writes_per_switch =18 According to write draining algorithm, the bus has to turn around to writes when the writeQueue.size() writeHighThreshold. However when i run some memory intensive benchmarks, i get a high number of Write retry requests because the write queue is full, as reported in the gem5 statistics. # Number of times write queue was full causing retry system.mem_ctrls.numWrRetry183731 I am not sure how this could happen, as the DRAM controller drain writes in a batch whenever the write queue size grows beyond the high threshold, which is only 85% of Write Buffer Size. Is this expected? 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Question on retry requests due to write queue full.
Hi Prathap, Your write are probably arriving faster than the controller can actually send them to the DRAM. What is it you’re running? Andreas From: gem5-users gem5-users-boun...@gem5.orgmailto:gem5-users-boun...@gem5.org on behalf of Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Tuesday, 14 July 2015 17:27 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] Question on retry requests due to write queue full. Hello Users, I am using classic memory system with following DRAM controller parameters write_buffer_size = 64 write_high_thresh_perc = 85 write_low_thresh_perc = 50 min_writes_per_switch =18 According to write draining algorithm, the bus has to turn around to writes when the writeQueue.size() writeHighThreshold. However when i run some memory intensive benchmarks, i get a high number of Write retry requests because the write queue is full, as reported in the gem5 statistics. # Number of times write queue was full causing retry system.mem_ctrls.numWrRetry183731 I am not sure how this could happen, as the DRAM controller drain writes in a batch whenever the write queue size grows beyond the high threshold, which is only 85% of Write Buffer Size. Is this expected? 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
