Re: [gem5-users] Issues in handling compressed data for L3 cache

2018-05-30 Thread Srajan Khare
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  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  wrote:
>
>> Thank you Jason for your quick reply!
>>
>>
>> On Sat, May 19, 2018 at 12:50 PM, Srajan Khare  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(), 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 0x1a8"). 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

Re: [gem5-users] Issues in handling compressed data for L3 cache

2018-05-29 Thread Srajan Khare
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  wrote:

> Thank you Jason for your quick reply!
>
>
> On Sat, May 19, 2018 at 12:50 PM, Srajan Khare  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(), 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 0x1a8"). 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

Re: [gem5-users] Issues in handling compressed data for L3 cache

2018-05-29 Thread Srajan Khare
Thank you Jason for your quick reply!


On Sat, May 19, 2018 at 12:50 PM, Srajan Khare  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(), 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 0x1a8"). 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] Issues in handling compressed data for L3 cache

2018-05-19 Thread Srajan Khare
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(), 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 0x1a8"). 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