Hi Varun,
I imagine there are other code paths that writeback dirty data. The cache
code is pretty complicated so I can't tell you exactly where to look off
the top of my head. One thing you could do is put an inform (or use debug
flags) at the memory controller. Here, you can see when there are writes to
memory (which are cache writebacks).
Another thing to check is to make sure you're using timing (not atomic)
simulation.
Cheers,
Jason
On Tue, Feb 27, 2018 at 9:20 PM Saivarun R <rsvaru...@gmail.com> wrote:
> Hi,
>
> I want to track the number of dirty blocks during the simulation. And
> after running a spec cpu2006 benchmark, calculix, I found that the number
> of dirty blocks is zero.
>
> So I put an inform statement in the function allocateBlock as follows:
>
> if (blk->isDirty() || writebackClean) {
> // Save writeback packet for handling by caller
> // correlate[sector_index]++;
> // predicted[i] = 1;
> inform("Block is Dirty");
> writebacks.push_back(writebackBlk(blk));
> } else {
> writebacks.push_back(cleanEvictBlk(blk));
> }
>
> And through out the simulation not even one block was declared as dirty.
> What could be reason or is it that blocks are not dirty at all??
>
> Can any one help me out with a reason for such an observation?
>
> Thank you
> Varun
> _______________________________________________
> 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
