A quick and easy way to achieve this, would be to actually use the tempBlock to
fill-in the dcache. The tempBlock will be automatically written back to the L2
as soon as the WriteReq is satisfied. This solution would actually incur a bit
of extra traffic between the L1 and L2 but at least it won’t trigger any
replacements/evictions in the L1 and it will fill the L2.
Alternative solutions would require changes to the way we handle coherence. A
needsWritable MSHR that handles WriteReq misses becomes the point of ordering
and not filling in the L1 at all would cause problems with ordering.
From: gem5-users on behalf of Muhammad Avais
Reply-To: gem5 users mailing list
Date: Tuesday, 24 April 2018 at 12:33
To: gem5 users mailing list
Subject: [gem5-users] Write non allocate policy for L2 cache
I want to implement write-non-allocate policy in gem5. Can any one
give some hint?
In "bool Cache::access(PacketPtr pkt, CacheBlk *, Cycles , PacketList
writebacks) " function, inside cache.cc file, where blocks are allocated, i
have added following line
but it gives following error
gem5.opt: build/X86/mem/coherent_xbar.cc:303: bool
CoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion
`routeTo.find(pkt->req) == routeTo.end()' failed.
Program aborted at tick 56513387376
Can anyone suggest any problem or guide about better solution?
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