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

Reply via email to