Hi Prof. Jason,

After your suggestion, I added other patches too and it worked. I also
tested for bzip2, cactusADM, gcc
and GemsFDTD. They all worked till the end without any issue.

Although, addition of patches 9963, 10141 and 10142 respectively was
fine without any
conflict, but, when I added final patch 9741 for creating sector cache
on top of all, there
were some file merger issues which I resolved following this
approachhttps://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

And yes, I'll post it in review site as well!

Thanks again!
Regards,

Srajan Khare,




On Tue, May 29, 2018 at 4:44 PM, 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

Reply via email to