Re: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
Prathap, 75 L2 misses, 26 L2 writebacks. 26 writebacks is what I would expect, given the 1,664 bytesWritten reported by the memory controller. However, what about the other 2,432 bytes in the array that were written? I dumped the stats after the process exited, so I wouldn't expect any of the written data at that point to be sitting in the caches. Thanks for the response. Patrick On Tue, Apr 21, 2015 at 9:27 PM, Prathap Kolakkampadath kvprat...@gmail.com wrote: Hello Patrick, Can you check the number of last level cache misses as reported by stats.text? Prathap On Apr 21, 2015 5:47 PM, Patrick plafr...@gmail.com wrote: I looked back at this, and I'm still not sure it's clear to me what is going on. I decreased the size of the write queue to 2, and when running the simulation described in my previous message (in which 512 64-bit stores to unique addresses are issued), bytesWritten in one run was reported to be only 1,664 bytes. With the write queue set to size 2, I would expect bytesWritten to be at least 4096 - 128 = 3,968 bytes (the burstSize is 64 bytes). Any additional help is appreciated. Regards, Patrick On Thu, Apr 16, 2015 at 2:07 PM, Patrick plafr...@gmail.com wrote: Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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 ___ 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] bytesWritten (8 * number of 64-bit stores to unique addresses)
Hello Patrick, Can you check the number of last level cache misses as reported by stats.text? Prathap On Apr 21, 2015 5:47 PM, Patrick plafr...@gmail.com wrote: I looked back at this, and I'm still not sure it's clear to me what is going on. I decreased the size of the write queue to 2, and when running the simulation described in my previous message (in which 512 64-bit stores to unique addresses are issued), bytesWritten in one run was reported to be only 1,664 bytes. With the write queue set to size 2, I would expect bytesWritten to be at least 4096 - 128 = 3,968 bytes (the burstSize is 64 bytes). Any additional help is appreciated. Regards, Patrick On Thu, Apr 16, 2015 at 2:07 PM, Patrick plafr...@gmail.com wrote: Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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 ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
I looked back at this, and I'm still not sure it's clear to me what is going on. I decreased the size of the write queue to 2, and when running the simulation described in my previous message (in which 512 64-bit stores to unique addresses are issued), bytesWritten in one run was reported to be only 1,664 bytes. With the write queue set to size 2, I would expect bytesWritten to be at least 4096 - 128 = 3,968 bytes (the burstSize is 64 bytes). Any additional help is appreciated. Regards, Patrick On Thu, Apr 16, 2015 at 2:07 PM, Patrick plafr...@gmail.com wrote: Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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] bytesWritten (8 * number of 64-bit stores to unique addresses)
Thanks, Andreas. This makes sense. On Wed, Apr 15, 2015 at 5:26 PM, Andreas Hansson andreas.hans...@arm.com wrote: Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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
[gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses)
Hi Patrick, When it comes to the stores you are looking at a rather small number of operations, and my guess is that they are still in the DRAM write queues. These queues are not drained at the moment once the writes fall below the “low water mark”. Andreas From: Patrick plafr...@gmail.commailto:plafr...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Wednesday, 15 April 2015 19:13 To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] bytesWritten (8 * number of 64-bit stores to unique addresses) I am looking at stats.txt for the amount of data written to the DRAM during the execution of a process in full system mode. I looked at the execution trace, and there are at least 512 64-bit stores to unique addresses. However, stats.txt reports only 2,304 bytesWritten to the memory. It is a 4-channel memory configuration. stats.txt reports 1,152 bytesWritten on channel 0, 0 bytesWritten to channel 1, 0 bytesWritten to channel 2, and 1,152 bytesWritten to channel 3. Does anyone know what would cause this? I thought maybe the data might be getting left in the caches, but I am waiting until the process exits before calling m5 resetstats. The bytesReadDRAM is less than expected, also, based on the number of loads in the instruction trace. I thought perhaps this was because no-write allocate was being used, but the discussion linked below suggests that default is to use write-allocate. I can't find where this is configured in gem5, so I'm not able to check this at the moment. http://comments.gmane.org/gmane.comp.emulators.m5.users/12597 Any help is appreciated. - Patrick -- 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
