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

[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

[Jason Lowe-Power]

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

mem-cache: Return evictions along with victims

mem-cache: Use ReplaceableEntry in findBlockBySetAndWay

mem-cache: Make tag a pointer


Thanks,
Jason

On Tue, May 29, 2018 at 4:15 AM 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
___
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

[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

[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

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

[Jason Lowe-Power]

Hi,

While I'm not sure I can directly answer your question, I know there's been
significant changes recently to the tag structure in the caches to support
creating new compressed caches. See this set of changesets (some of which
have been merged) in gerrit (our code review site).
https://gem5-review.googlesource.com/c/public/gem5/+/9741 (Note: supporting
sector caches is one step towards supporting compressed caches.)

Cheers,
Jason

On Sat, May 19, 2018 at 12:20 AM 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 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

[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