Hello Andreas, I have modelled a system with large MSHRs, LSQ depth etc. With this i could see that the packet size grows beyond 100 and hits this assertion. After disabling this assertion the test runs to completion.
1)Is it safe to disable this? However as i mentioned in an earlier email, i have modified the DRAM controller switching algorithm to prioritize reads and never switch to writes as long as there are reads in the read buffer. With this modification, In one set of memory intensive benchmarks with high page hit rate, I could see that min_number_of_writes_per switch is ~15 . I expect that the write buffer(DRAM and cache) gets full as a result the core stalls, and no more requests arrives at DRAM controller. Once the DRAM controller drains the existing reads it switches to writes and when a write is serviced, and corresponding buffer is freed, core can generate a new load/store. But the number of writes per switch(15) that i see doesn't justify the round trip time. Further debugging this issue, I observed that once the write queue/ write buffers are full, and when the DRAM controller service the queued reads, which generates the write backs(due to eviction). Note that DRAM controller write_buffer is full at this time. These write backs will be get queued in the port(deferred packets) and any further reads will be queued at the end of write backs. 2) Is this a desired behaviour? to address write after read hazard? Thanks, Prathap On Mon, Jul 27, 2015 at 9:22 AM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > 100 was chosen to be “sufficiently infinite”, and only break if > something is wrong. > > The caches have a limited number of MSHRs, the cores have limited LSQ > depth etc. We could easily add an outstanding transaction limit to the > crossbar class. In the end it is a detail/speed trade-off. If it does not > matter, do not model it… > > 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: Monday, 27 July 2015 15:15 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] How queued port is modelled in real platforms? > > Hello Andreas, > > Currently, the reasonable limit of this queue is set to 100. Is there a > specific reason to choose this as the maximum packet queue size. > Do any bus interface protocol specifies this limit in real platforms? > > Thanks, > Prathap > > On Mon, Jul 27, 2015 at 4:54 AM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > >> Hi Prathap, >> >> The queued port is indeed infinite, and is a convenience construct. It >> should only be used in places where there is already an inherent limit to >> the number of outstanding requests. There is an assert in the queued port >> to ensure things do not grow uncontrollably. >> >> 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: Sunday, 26 July 2015 18:34 >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: [gem5-users] How queued port is modelled in real platforms? >> >> Hell Users, >> >> Gem5 implements a queued port to interface memory objects. In my >> understanding this queued port is of infinite size. Is this specific to >> Gem5 implementation? How packets are handled in real hardware if the >> request rate of a layer is faster than the service rate of underlying layer? >> It would be great if someone could help me in understanding this. >> >> 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 >> > > > -- 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
