I'm getting the following error over and over and exactly at the same cycle.
I even modified the code. Instead of returning NULL in
findVictim->allocateBlock-> I added a dummy block to the TagStore class.
When I want the prevent address B from replacing A,
I return the dummy block in handleFill for B. In 'insertBlock' function if I
see the dummy variable eliminate most operations (except, for example,
setting dummyBlk->tag since it will be checked later).

********************************************************************************************
panic: M5 panic instruction called at pc=0xfffffc00000138a0.
 @ cycle 7221328000
[execute:build/ALPHA_FS/arch/alpha/atomic_simple_cpu_exec.cc, line 11282]
Memory Usage: 736760 KBytes
For more information see: http://www.m5sim.org/panic/116b925c
Program aborted at cycle 7221328000
********************************************************************************************

I really need your suggestion (due to my deadline) and I appreciate your
help.

Regards,
Navid.

On Mon, Dec 6, 2010 at 12:21 PM, Navid Farazmand <[email protected]>wrote:

> Hi,
> I am trying to implement some cache replacement/management in M5.
> I have problem with one of them which is quite simple and involves little
> modification.
>
> It's called dynamic exclusion policy. Based on some history of the
> accesses, I want to prevent some accesses to replace the corresponding
> block.
> I just need direct mapped cache. So, let's say, normally after a miss on B,
> B is fetched from next level cache (or memory) and the replaces A.
> Assume that I know that I don't want B to replace A.
> After a miss is satisfied from the memory, using 'handleFill' data would be
> replaced.
> ***************************************************************************
> } else if (bus_pkt->isRead() ||
>                            bus_pkt->cmd == MemCmd::UpgradeResp) {
>                     // we're updating cache state to allow us to
>                     // satisfy the upstream request from the cache
>                     blk = handleFill(bus_pkt, blk, writebacks);
>                     satisfyCpuSideRequest(pkt, blk);
> }
> ***************************************************************************
>
> And here is the relevant part in handle fill:
>
>
> ***************************************************************************
>     if (blk == NULL) {
>         // better have read new data...
>         assert(pkt->hasData());
>         // need to do a replacement
>         blk = allocateBlock(addr, writebacks);
>         if (blk == NULL) {
>             // No replaceable block... just use temporary storage to
>             // complete the current request and then get rid of it
>             assert(!tempBlock->isValid());
>             blk = tempBlock;
>             tempBlock->set = tags->extractSet(addr);
>             tempBlock->tag = tags->extractTag(addr);
>             DPRINTF(Cache, "using temp block for %x\n", addr);
>         } else {
>             int id = pkt->req->hasContextId() ? pkt->req->contextId() : -1;
>             tags->insertBlock(pkt->getAddr(), blk, id);
>         }
>
> ***************************************************************************
> Since it has been a miss, the first blk==NULL is satisfied. I thought that,
> whenever I want to prevent B from replacing A I can simply return a NULL
> pointer in allocateBlock.
> Is this gonna work? For example, assume that findVictim always returns NULL
> meaning that no replacement is carried out (Cache lines/blocks are filled
> only when they are empty/invalid).
> Shouldn't all requests become satisfied from memory and simulation run
> correctly? I just modified findVictim to always return NULL to test this
> characteristic. Neither this way, nor when I
> selectively return NULL for findVictim (and hence for allocateBlock) it
> works. I expected that using tmpBlock the requests are satisfied in these
> cases.
> If my expectation is incorrect, anybody knows how can I prevent a based on
> the address of the new request and the current resident of the block?
>
> Thank you,
> Navid.
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to