[gem5-users] Query regarding blocking cache slave port
Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do this? Thanks, Prathap ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Query regarding blocking cache slave port
Thanks Andreas. On Mon, May 4, 2015 at 5:11 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, Check retryWaiting in Xbar. There we choose the port to go next when one or more ports had to wait. If you want to implement what you suggest you also have to perform a check in recvTimingReq to not just see if the layer is busy, but also check if the port asking is within budget. Andreas From: Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Monday, 4 May 2015 22:56 To: gem5 users mailing list gem5-users@gem5.org Subject: Re: [gem5-users] Query regarding blocking cache slave port Hi Andreas, Thanks for your reply. I am trying to figure out how to implement this based on your inputs. Can you also please point out the data structures which maintains the queue in cross bar.? Thanks, Prathap On Mon, May 4, 2015 at 4:04 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, The most sensible place to implement the arbitration is indeed in the crossbar which is conceptually part of the L2 cache. By default the crossbar uses First-Come First-Served, but you can change with not too much coding. The tricky bit in this case is to base the selection on MSHRs, since the crossbar has no such accounting. I would think the easiest is to add outstanding transaction counting per SlavePort in the crossbar, and then only let a port have X outstanding transactions. Overall this would be valuable functionality, so if you do code it up, please post a patch. It would be a great contribution. Andreas From: Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Monday, 4 May 2015 20:18 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Query regarding blocking cache slave port Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do 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
Re: [gem5-users] Query regarding blocking cache slave port
Hi Prathap, Check retryWaiting in Xbar. There we choose the port to go next when one or more ports had to wait. If you want to implement what you suggest you also have to perform a check in recvTimingReq to not just see if the layer is busy, but also check if the port asking is within budget. Andreas From: Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Monday, 4 May 2015 22:56 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: Re: [gem5-users] Query regarding blocking cache slave port Hi Andreas, Thanks for your reply. I am trying to figure out how to implement this based on your inputs. Can you also please point out the data structures which maintains the queue in cross bar.? Thanks, Prathap On Mon, May 4, 2015 at 4:04 PM, Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com wrote: Hi Prathap, The most sensible place to implement the arbitration is indeed in the crossbar which is conceptually part of the L2 cache. By default the crossbar uses First-Come First-Served, but you can change with not too much coding. The tricky bit in this case is to base the selection on MSHRs, since the crossbar has no such accounting. I would think the easiest is to add outstanding transaction counting per SlavePort in the crossbar, and then only let a port have X outstanding transactions. Overall this would be valuable functionality, so if you do code it up, please post a patch. It would be a great contribution. Andreas From: Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Monday, 4 May 2015 20:18 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] Query regarding blocking cache slave port Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do 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.orgmailto: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
Re: [gem5-users] Query regarding blocking cache slave port
Hi Andreas, Thanks for your reply. I am trying to figure out how to implement this based on your inputs. Can you also please point out the data structures which maintains the queue in cross bar.? Thanks, Prathap On Mon, May 4, 2015 at 4:04 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Prathap, The most sensible place to implement the arbitration is indeed in the crossbar which is conceptually part of the L2 cache. By default the crossbar uses First-Come First-Served, but you can change with not too much coding. The tricky bit in this case is to base the selection on MSHRs, since the crossbar has no such accounting. I would think the easiest is to add outstanding transaction counting per SlavePort in the crossbar, and then only let a port have X outstanding transactions. Overall this would be valuable functionality, so if you do code it up, please post a patch. It would be a great contribution. Andreas From: Prathap Kolakkampadath kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Monday, 4 May 2015 20:18 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] Query regarding blocking cache slave port Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do 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 ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Query regarding blocking cache slave port
Hi Prathap, The most sensible place to implement the arbitration is indeed in the crossbar which is conceptually part of the L2 cache. By default the crossbar uses First-Come First-Served, but you can change with not too much coding. The tricky bit in this case is to base the selection on MSHRs, since the crossbar has no such accounting. I would think the easiest is to add outstanding transaction counting per SlavePort in the crossbar, and then only let a port have X outstanding transactions. Overall this would be valuable functionality, so if you do code it up, please post a patch. It would be a great contribution. Andreas From: Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Monday, 4 May 2015 20:18 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] Query regarding blocking cache slave port Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do 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
