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
