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

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-bounces(a)gem5.org> on behalf of Muhammad Avais <avais.suhail(a)gmail.com>
Reply-To: gem5 users mailing list <gem5-users(a)gem5.org>
Date: Thursday, 3 May 2018 at 06:44
To: gem5 users mailing list <gem5-users(a)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.

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-bounces(a)gem5.org> on behalf of Muhammad Avais <avais.suhail(a)gmail.com>
Reply-To: gem5 users mailing list <gem5-users(a)gem5.org>
Date: Friday, 4 May 2018 at 11:16
To: gem5 users mailing list <gem5-users(a)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.suhail(a)gmail.commailto:avais.suhail(a)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.Nikoleris(a)arm.commailto:Nikos.Nikoleris(a)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-bounces(a)gem5.orgmailto:gem5-users-bounces(a)gem5.org> on behalf of Muhammad Avais <avais.suhail(a)gmail.commailto:avais.suhail(a)gmail.com>
Reply-To: gem5 users mailing list <gem5-users(a)gem5.orgmailto:gem5-users(a)gem5.org>
Date: Thursday, 3 May 2018 at 06:44
To: gem5 users mailing list <gem5-users(a)gem5.orgmailto:gem5-users(a)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(a)gem5.orgmailto:gem5-users(a)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.