Hi Srajan,

Could you post this on our code review site so the patch creator (Daniel)
can take a look? You can register on the site with a google account (e.g.,
your gmail). Then, you can post a reply on this page:

One possible source of your problem is that you have to apply all of the
patches in the relation chain. In this case that would be:
Relation chain
mem-cache: Create Sector Cache
mem-cache: Return evictions along with victims
mem-cache: Use ReplaceableEntry in findBlockBySetAndWay
mem-cache: Make tag a pointer


On Tue, May 29, 2018 at 4:15 AM Srajan Khare <rsk...@gmail.com> wrote:

> Hi Jason,
> As per your suggestion I included the recently committed patch (for
> creating sector cache) with my gem5 version. Then after, just to get an
> idea of Sector Cache performance, I ran simulation for *bzip2 *SPEC
> CPU2006 benchmark with 1B fast forward and then executing 500M instruction
> in DerivO3CPU mode.
> Only modification I did to simulate it, was to take 4 blocks per sector
> instead of default configuration in src/mem/cache/tags/tags.py.
> I got following assertion failed after sometime due to which simulation
> got aborted.
> --------------------ASSERTION FAILED!------------------------
> gem5.opt: build/X86/mem/cache/write_queue.cc:60: WriteQueueEntry*
> WriteQueue::allocate(Addr, unsigned int, PacketPtr, Tick, Counter):
> Assertion `!freeList.empty()' failed.
> -------------------------------------------------------------
> Could you please have some directions on this failed assertion so that I
> can go ahead with my actual compressed cache implementation?
> Thanks a lot in advance!
> ~Srajan Khare
> On Tue, May 29, 2018 at 3:12 PM, Srajan Khare <rsk...@gmail.com> wrote:
>> Thank you Jason for your quick reply!
>> On Sat, May 19, 2018 at 12:50 PM, Srajan Khare <rsk...@gmail.com> wrote:
>>> Hi friends,
>>> I have been implementing Cache Compression algorithm in gem5.
>>> So in order to tap data for all the writes into L3 cache I have been
>>> using handleFill() function in cache.cc file. I have been using following
>>> command to transfer data in compressed format into L3 cache.
>>> ---------------*Code snippet*-----------------
>>> //Only for L3 cache
>>> uint8_t *dataofCacheLine;
>>> memcpy(dataOfCacheLine, pkt->getConstPtr<uint8_t>(), blkSize);
>>> compr_Info = compressionAlgo (dataOfCacheLine, .................,
>>> .................);
>>> //compr_Info contains compressed data and new size.
>>> //compressed data is then transferred into blk->data in the following way
>>> memcpy(blk->data, compr_info.comprData, compr_info.comprSize);
>>> --------------------------------------------
>>> Doing this leads to SIGABRT signal which terminates the execution with a
>>> panic ("Tried to read unmapped address 0x100000000a8"). I debugged it with
>>> gdb and log files and got myself zero'd down to error in memcpy statement.
>>> Could any of you let me know why there is a crash due to second memcpy
>>> statement provided compressed data I am storing is consistent with the
>>> actual data referenced by the block?
>>> Does any addressing gets disturbed when I am doing it like this? If Yes,
>>> could you please give me some inputs on this??
>>> Thanks a lot in advance!
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
gem5-users mailing list

Reply via email to