Hi gem5 community,
Any suggestions on this topic?
On Thu, May 27, 2021 at 11:29 AM Chongzhi Zhao <cz_z...@tamu.edu> wrote:
> Update:
> To enforce strict inclusivity, I changed BaseCache::handleEvictions() to
> below (changes in bold font). I also added "fully_incl" to Enum in
> Cache.py.
> Would this make caches strictly inclusive by back invalidation upon
> eviction?
>
> bool
> BaseCache::handleEvictions(std::vector<CacheBlk*> &evict_blks,
> PacketList &writebacks)
> {
> bool replacement = false;
> for (const auto& blk : evict_blks) {
> if (blk->isValid()) {
> replacement = true;
> const MSHR* mshr =
> mshrQueue.findMatch(regenerateBlkAddr(blk),
> blk->isSecure());
> if (mshr) {
> // Must be an outstanding upgrade or clean request on a
> block
> // we're about to replace
> assert((!blk->isSet(CacheBlk::WritableBit) &&
> mshr->needsWritable()) || mshr->isCleaning());
> return false;
> }
> }
> }
>
> // The victim will be replaced by a new entry, so increase the
> replacement
> // counter if a valid block is being replaced
> if (replacement) {
> stats.replacements++;
>
> // Evict valid blocks associated to this victim block
> for (auto& blk : evict_blks) {
> if (blk->isValid()) {
>
>
>
>
>
>
>
>
>
>
>
>
> * // Before evicting this victim block, snoop upper-level
> caches // and attempt to invalidate existing same blocks if
> inclusive cache if (clusivity == Enums::fully_incl) {
> RequestPtr req = std::make_shared<Request>(
> regenerateBlkAddr(blk), blkSize, 0, Request::invldRequestorId);
> if (blk->isSecure())
> req->setFlags(Request::SECURE);
> req->taskId(blk->getTaskId()); PacketPtr invl_pkt = new
> Packet(req, MemCmd::InvalidateReq);
> invl_pkt->setExpressSnoop(); invl_pkt->senderState =
> nullptr; cpuSidePort.sendTimingSnoopReq(invl_pkt);
> }*
>
> evictBlock(blk, writebacks);
> }
> }
> }
>
> return true;
> }
>
>
> On Thu, May 13, 2021 at 8:41 PM Chongzhi Zhao <cz_z...@tamu.edu> wrote:
>
>> Hi gem5 community,
>>
>> TL;DR:
>>
>> 1. In "classic" memory, the current 2 options, mostly_incl and
>> mostly_excl, seem to apply only to cache fill but NOT eviction. As a
>> result, blocks evicted from L2 may be still present in L1. Is my
>> understanding correct?
>> 2. What would be a reasonable way to enforce strict inclusivity and
>> exclusivity?
>>
>> ----------------------
>>
>> Details:
>> This link may provide some background:
>> https://m5-dev.m5sim.narkive.com/qRrXUtt7/gem5-dev-review-request-3156-mem-add-cache-clusivity-to-steer-behaviour-on-fill
>>
>> 1. In the case of a replacement eviction, BaseCache::allocateBlock()
>> finds a victim and then calls BaseCache::handleEvictions() >>
>> BaseCache::evictBlock() >> Cache::evictBlock(). As a result, a packet is
>> pushed into writebacks list. doWritebacks() doesn't seem to bother
>> upstream
>> caches that hold the same block.
>> 2. To implement strict inclusivity, the most obvious way to me is
>> letting doWritebacks() send an invalidation packet through cpuSidePort.
>> But
>> I don't know how to stitch these things together without breaking other
>> stuff.
>>
>>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
