Re: [gem5-users] Dynamic Associative cache in gem5
Hi Avais, You might need to remove the snoop filter from the system as well, depending on what exactly you want to do. Doing so will increase significantly the number of snoops in the system. But in your case, the snoop filter performs sanity checks about the coherence protocol and if these checks fail then the memory system is not any more in a consistent state. Unless I am missing something, you will have to change WritebackDrity to WriteClean as well. Nikos From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Muhammad Avais <avais.suh...@gmail.com> Reply-To: gem5 users mailing list <gem5-users@gem5.org> Date: Friday, 4 May 2018 at 11:16 To: gem5 users mailing list <gem5-users@gem5.org> Subject: Re: [gem5-users] Dynamic Associative cache in gem5 Dear Nikos, I have seen that we can bypass snoopfilter in "coherent_xbar.cc" file by passing snoopfilter variabels as nullptr. Is it good solution to avoid snoopfilter checking, if we do not care about coherence protocols in simulation. Best Regards, Thanks, Avais On Fri, May 4, 2018 at 2:28 PM, Muhammad Avais <avais.suh...@gmail.com<mailto:avais.suh...@gmail.com>> wrote: Dear Nikos, Many thanks for your reply. Your suggestion are always helpful in solving issues in gem5. I will try to use writeclean packets. Many thanks, Kind Regards, Avais On Thu, May 3, 2018 at 11:24 PM, Nikos Nikoleris <nikos.nikole...@arm.com<mailto:nikos.nikole...@arm.com>> wrote: Hi Avais, I am not sure exactly what you mean by not invalidating but based on the assertion I am assuming that for some blocks you write back any dirty data and then you retain them in the cache, but it is not clear how you handle subsequent accesses and snoops to any of these blocks. I can only speculate about the problem, but this might help. I suppose that you use WritebackDirty packets to write dirty data to the memory below. WritebackDirty packets are treated as evicts and the snoop filter believes that the cache doesn’t have the data any longer. If you are on a reasonably recent version of gem5, you could try using WriteClean packets which have the exact same property of carrying dirty data without the additional property of implying an eviction. Nikos From: gem5-users <gem5-users-boun...@gem5.org<mailto:gem5-users-boun...@gem5.org>> on behalf of Muhammad Avais <avais.suh...@gmail.com<mailto:avais.suh...@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Thursday, 3 May 2018 at 06:44 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Dynamic Associative cache in gem5 Dear All, I am trying tom implement dynamic associative cache. I have found that after decreasing the associativity, if i do not invalidate blocks then following problem occurs. Actually, i do not want to invaliate blocks that are out of associativity, can anyone suggest some solution #0 0x76401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x009c4327 in SnoopFilter::lookupRequest(Packet const*, SlavePort const&) () at build/X86/mem/snoop_filter.cc:137 #3 0x0099e3ec in CoherentXBar::recvTimingReq(Packet*, short) () at build/X86/mem/coherent_xbar.cc:192 #4 0x0134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*) () at build/X86/mem/cache/cache.cc:3528 #5 0x01341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket() () at build/X86/mem/cache/cache.cc:3731 #6 0x01417b41 in EventQueue::serviceOne() () at build/X86/sim/eventq.cc:228 #7 0x01426e08 in doSimLoop(EventQueue*) () at build/X86/sim/simulate.cc:219 #8 0x014274eb in simulate(unsigned long) () at build/X86/sim/simulate.cc:132 Best Regards, Thanks, Avais 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. ___ gem5-users mailing list gem5-users@gem5.org<mailto: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. ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Dynamic Associative cache in gem5
Dear Nikos, I have seen that we can bypass snoopfilter in "coherent_xbar.cc" file by passing snoopfilter variabels as nullptr. Is it good solution to avoid snoopfilter checking, if we do not care about coherence protocols in simulation. Best Regards, Thanks, Avais On Fri, May 4, 2018 at 2:28 PM, Muhammad Avais <avais.suh...@gmail.com> wrote: > Dear Nikos, > > Many thanks for your reply. Your suggestion are always helpful in > solving issues in gem5. I will try to use writeclean packets. > > Many thanks, > Kind Regards, > Avais > > On Thu, May 3, 2018 at 11:24 PM, Nikos Nikoleris <nikos.nikole...@arm.com> > wrote: > >> Hi Avais, >> >> >> >> I am not sure exactly what you mean by not invalidating but based on the >> assertion I am assuming that for some blocks you write back any dirty data >> and then you retain them in the cache, but it is not clear how you handle >> subsequent accesses and snoops to any of these blocks. >> >> >> >> I can only speculate about the problem, but this might help. I suppose >> that you use WritebackDirty packets to write dirty data to the memory >> below. WritebackDirty packets are treated as evicts and the snoop filter >> believes that the cache doesn’t have the data any longer. If you are on a >> reasonably recent version of gem5, you could try using WriteClean packets >> which have the exact same property of carrying dirty data without the >> additional property of implying an eviction. >> >> Nikos >> >> >> >> >> >> *From: *gem5-users <gem5-users-boun...@gem5.org> on behalf of Muhammad >> Avais <avais.suh...@gmail.com> >> *Reply-To: *gem5 users mailing list <gem5-users@gem5.org> >> *Date: *Thursday, 3 May 2018 at 06:44 >> *To: *gem5 users mailing list <gem5-users@gem5.org> >> *Subject: *[gem5-users] Dynamic Associative cache in gem5 >> >> >> >> Dear All, >> >>I am trying tom implement dynamic associative cache. I have found >> that after decreasing the associativity, if i do not invalidate blocks then >> following problem occurs. >> >> >> >> Actually, i do not want to invaliate blocks that are out of >> associativity, can anyone suggest some solution >> >> >> >> #0 0x76401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 >> >> #1 0x7640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6 >> >> #2 0x009c4327 in SnoopFilter::lookupRequest(Packet const*, >> SlavePort const&) () at build/X86/mem/snoop_filter.cc:137 >> >> #3 0x0099e3ec in CoherentXBar::recvTimingReq(Packet*, short) () >> at build/X86/mem/coherent_xbar.cc:192 >> >> #4 0x0134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*) >> () at build/X86/mem/cache/cache.cc:3528 >> >> #5 0x01341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket() >> () at build/X86/mem/cache/cache.cc:3731 >> >> #6 0x01417b41 in EventQueue::serviceOne() () at >> build/X86/sim/eventq.cc:228 >> >> #7 0x01426e08 in doSimLoop(EventQueue*) () at >> build/X86/sim/simulate.cc:219 >> >> #8 0x014274eb in simulate(unsigned long) () at >> build/X86/sim/simulate.cc:132 >> >> >> >> >> >> Best Regards, >> >> Thanks, >> >> Avais >> >> >> 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. >> >> ___ >> 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] Dynamic Associative cache in gem5
Dear Nikos, Many thanks for your reply. Your suggestion are always helpful in solving issues in gem5. I will try to use writeclean packets. Many thanks, Kind Regards, Avais On Thu, May 3, 2018 at 11:24 PM, Nikos Nikoleris <nikos.nikole...@arm.com> wrote: > Hi Avais, > > > > I am not sure exactly what you mean by not invalidating but based on the > assertion I am assuming that for some blocks you write back any dirty data > and then you retain them in the cache, but it is not clear how you handle > subsequent accesses and snoops to any of these blocks. > > > > I can only speculate about the problem, but this might help. I suppose > that you use WritebackDirty packets to write dirty data to the memory > below. WritebackDirty packets are treated as evicts and the snoop filter > believes that the cache doesn’t have the data any longer. If you are on a > reasonably recent version of gem5, you could try using WriteClean packets > which have the exact same property of carrying dirty data without the > additional property of implying an eviction. > > Nikos > > > > > > *From: *gem5-users <gem5-users-boun...@gem5.org> on behalf of Muhammad > Avais <avais.suh...@gmail.com> > *Reply-To: *gem5 users mailing list <gem5-users@gem5.org> > *Date: *Thursday, 3 May 2018 at 06:44 > *To: *gem5 users mailing list <gem5-users@gem5.org> > *Subject: *[gem5-users] Dynamic Associative cache in gem5 > > > > Dear All, > >I am trying tom implement dynamic associative cache. I have found > that after decreasing the associativity, if i do not invalidate blocks then > following problem occurs. > > > > Actually, i do not want to invaliate blocks that are out of associativity, > can anyone suggest some solution > > > > #0 0x76401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > > #1 0x7640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6 > > #2 0x009c4327 in SnoopFilter::lookupRequest(Packet const*, > SlavePort const&) () at build/X86/mem/snoop_filter.cc:137 > > #3 0x0099e3ec in CoherentXBar::recvTimingReq(Packet*, short) () > at build/X86/mem/coherent_xbar.cc:192 > > #4 0x0134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*) > () at build/X86/mem/cache/cache.cc:3528 > > #5 0x01341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket() > () at build/X86/mem/cache/cache.cc:3731 > > #6 0x01417b41 in EventQueue::serviceOne() () at > build/X86/sim/eventq.cc:228 > > #7 0x01426e08 in doSimLoop(EventQueue*) () at > build/X86/sim/simulate.cc:219 > > #8 0x014274eb in simulate(unsigned long) () at > build/X86/sim/simulate.cc:132 > > > > > > Best Regards, > > Thanks, > > Avais > > > 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. > > ___ > 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] Dynamic Associative cache in gem5
Hi Avais, I am not sure exactly what you mean by not invalidating but based on the assertion I am assuming that for some blocks you write back any dirty data and then you retain them in the cache, but it is not clear how you handle subsequent accesses and snoops to any of these blocks. I can only speculate about the problem, but this might help. I suppose that you use WritebackDirty packets to write dirty data to the memory below. WritebackDirty packets are treated as evicts and the snoop filter believes that the cache doesn’t have the data any longer. If you are on a reasonably recent version of gem5, you could try using WriteClean packets which have the exact same property of carrying dirty data without the additional property of implying an eviction. Nikos From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Muhammad Avais <avais.suh...@gmail.com> Reply-To: gem5 users mailing list <gem5-users@gem5.org> Date: Thursday, 3 May 2018 at 06:44 To: gem5 users mailing list <gem5-users@gem5.org> Subject: [gem5-users] Dynamic Associative cache in gem5 Dear All, I am trying tom implement dynamic associative cache. I have found that after decreasing the associativity, if i do not invalidate blocks then following problem occurs. Actually, i do not want to invaliate blocks that are out of associativity, can anyone suggest some solution #0 0x76401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x009c4327 in SnoopFilter::lookupRequest(Packet const*, SlavePort const&) () at build/X86/mem/snoop_filter.cc:137 #3 0x0099e3ec in CoherentXBar::recvTimingReq(Packet*, short) () at build/X86/mem/coherent_xbar.cc:192 #4 0x0134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*) () at build/X86/mem/cache/cache.cc:3528 #5 0x01341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket() () at build/X86/mem/cache/cache.cc:3731 #6 0x01417b41 in EventQueue::serviceOne() () at build/X86/sim/eventq.cc:228 #7 0x01426e08 in doSimLoop(EventQueue*) () at build/X86/sim/simulate.cc:219 #8 0x014274eb in simulate(unsigned long) () at build/X86/sim/simulate.cc:132 Best Regards, Thanks, Avais 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. ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Dynamic Associative cache in gem5
Dear All, I am trying tom implement dynamic associative cache. I have found that after decreasing the associativity, if i do not invalidate blocks then following problem occurs. Actually, i do not want to invaliate blocks that are out of associativity, can anyone suggest some solution #0 0x76401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x009c4327 in SnoopFilter::lookupRequest(Packet const*, SlavePort const&) () at build/X86/mem/snoop_filter.cc:137 #3 0x0099e3ec in CoherentXBar::recvTimingReq(Packet*, short) () at build/X86/mem/coherent_xbar.cc:192 #4 0x0134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*) () at build/X86/mem/cache/cache.cc:3528 #5 0x01341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket() () at build/X86/mem/cache/cache.cc:3731 #6 0x01417b41 in EventQueue::serviceOne() () at build/X86/sim/eventq.cc:228 #7 0x01426e08 in doSimLoop(EventQueue*) () at build/X86/sim/simulate.cc:219 #8 0x014274eb in simulate(unsigned long) () at build/X86/sim/simulate.cc:132 Best Regards, Thanks, Avais ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
