Dear Nikos,
Many thanks for your help. Actually i have not handled snoops for
blocks retained outside associativity and this was causing snoop filter
problem.Your suggestion proved helpful for me in solving this problem,
Best Regards,
Thanks,
Avais
On Fri, May 4, 2018 at 7:43 PM, Nikos Nikoleris <nikos.nikole...@arm.com>
wrote:
> 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>
> 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 0x00007ffff6401035 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>
> #1 0x00007ffff640479b in abort () from /lib/x86_64-linux-gnu/libc.so.6
>
> #2 0x00000000009c4327 in SnoopFilter::lookupRequest(Packet const*,
> SlavePort const&) () at build/X86/mem/snoop_filter.cc:137
>
> #3 0x000000000099e3ec in CoherentXBar::recvTimingReq(Packet*, short) ()
> at build/X86/mem/coherent_xbar.cc:192
>
> #4 0x000000000134117a in Cache::sendWriteQueuePacket(WriteQueueEntry*)
> () at build/X86/mem/cache/cache.cc:3528
>
> #5 0x0000000001341a61 in Cache::CacheReqPacketQueue::sendDeferredPacket()
> () at build/X86/mem/cache/cache.cc:3731
>
> #6 0x0000000001417b41 in EventQueue::serviceOne() () at
> build/X86/sim/eventq.cc:228
>
> #7 0x0000000001426e08 in doSimLoop(EventQueue*) () at
> build/X86/sim/simulate.cc:219
>
> #8 0x00000000014274eb 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
>
>
>
>
> 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
