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: https://gem5-review.googlesource.com/c/public/gem5/+/9741.
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 <https://gem5-review.googlesource.com/c/public/gem5/+/9741/5> mem-cache: Return evictions along with victims <https://gem5-review.googlesource.com/c/public/gem5/+/10142/4> mem-cache: Use ReplaceableEntry in findBlockBySetAndWay <https://gem5-review.googlesource.com/c/public/gem5/+/10141/5> mem-cache: Make tag a pointer <https://gem5-review.googlesource.com/c/public/gem5/+/9963/7> Thanks, Jason 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
