Sampad,

I thought the L3 would be inclusive too, but the code reads otherwise, it
only caches entries on a writeback (always) or writethrough (if enabled).

I am considering changing it to be inclusive for my own purposes (I don't
know if that is something the community would want or not). Which I guess
would just entail caching on reads as well as WB/WT.

I've attached the patch. I've run it on the gcn3-staging branch (+some of
my own changes) but I haven't run it on the develop branch (this patch is
on top of the develop branch for your convenience).

You will notice some comments about certain hitsProfiling calls for stores
not being right.
>From what i can tell when the corepair has ownership (M/O/E states) of a
block, when one of the cores stores to that block even if the block isn't
in that corepair's L1, it instantaneously puts that cache block into
Modified state for that core's L1.
I didn't want to fix the instantaneousness when I was working on this, so
since performance-wise it's a hit, I just profiled it as such.
You could split those transitions up for a storeMiss and a storeHit (they
could be the same save for the profiling action call)

Let me know if this works for you.

Cheers,

Dan

On Tue, Aug 18, 2020 at 11:09 AM Sampad Mohapatra <su...@psu.edu> wrote:

> Hi Daniel,
>
> I am just starting out so it would be really helpful if you could kindly
> provide your patches.
> Have you verified the changes, otherwise I will try to verify them.
>
> Also, isn't the L3 inclusive ?
>
> Thank you,
> Sampad
>
> On Tue, Aug 18, 2020 at 9:57 AM Daniel Gerzhoy <daniel.gerz...@gmail.com>
> wrote:
>
>> Hi Sampad,
>>
>> I've added corepair profiling to MOESI_AMD_BASE-CorePair.sm if you
>> haven't already done so. I can create a patch for you (or I'd be happy to
>> review if you end up submitting one).
>>
>> I was confused about the L3Cache in the <...>-dir.sm file as well.
>> The MOESI_AMD_Base-L3cache.sm file doesn't actually do anything. The L3
>> Cache file is implemented alongside the directory.
>> It acts as a victim cache for the L2s.
>>
>> I also noticed that the MRU isn't being updated for the L3, so I added
>> that....except it's all commented out in my code right now and I'm not sure
>> why, so I am going to investigate that.
>>
>> Cheers,
>>
>> Dan Gerzhoy
>>
>> On Tue, Aug 18, 2020 at 12:04 AM Matt Sinclair via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Sampad,
>>>
>>> The AMD folks that are CC'd are better people to comment than me, but I
>>> believe the L3 cache is a "memory side" cache, and thus doesn't need to
>>> maintain coherence.
>>>
>>> If you have a fix to add hits/misses for any of these files, and are
>>> willing to contribute it back, it would be great if you could submit a
>>> patch for it.
>>>
>>> Matt
>>>
>>> On Mon, Aug 17, 2020 at 11:00 PM Sampad Mohapatra <su...@psu.edu> wrote:
>>>
>>>> Hi Matt,
>>>>
>>>> I am currently trying to add the stats by myself. I also noticed that
>>>> neither hit nor miss stats are updated for L3 Cache.
>>>>
>>>> But, I am facing a different issue now. The directory ctrl (DirCntrl)
>>>> in GPU_VIPER.py has a L3 cache (L3Cache).
>>>> But, there is also a separate L3Cntrl class which inherits from
>>>> L3Cache_Controller, but it is unused.
>>>> The L3Cache_Controller is generated from MOESI_AMD_Base-L3cache.sm,
>>>> which is a part of the Viper protocol.
>>>>
>>>> If the L3Cache_Controller isn't used, then why is it a part of the
>>>> Viper protocol ?
>>>> Does the L3 Cache not maintain any coherency ?
>>>> Is this the intended behaviour of the default configuration ?
>>>>
>>>> Thanks and Regards,
>>>> Sampad
>>>>
>>>> On Thu, Aug 13, 2020 at 5:40 PM Matt Sinclair via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>>> Hi Sampad,
>>>>>
>>>>> I'm not aware of a patch for this.  There was recently a patch to add
>>>>> similar support for the VIPER protocol:
>>>>> https://gem5-review.googlesource.com/c/public/gem5/+/30174.  If the
>>>>> AMD folks (CC'd) don't have a patch, then the next best thing would be to
>>>>> do something similar to the VIPER patch (although yes, the Core Pair
>>>>> changes would be a little more complicated).
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>> On Tue, Aug 4, 2020 at 4:53 PM Sampad Mohapatra via gem5-users <
>>>>> gem5-users@gem5.org> wrote:
>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> MOESI AMD Base - CorePair state machine is missing the actions for L1
>>>>>> and L2 hit statistics.
>>>>>> The stats are present, but since no "action" is created nor used
>>>>>> (actions to update misses are present for both L1 and L2), the stats stay
>>>>>> at 0.
>>>>>>
>>>>>> I am not clear as to which state transitions should
>>>>>> update the hit stats. Is there a patch for this ?
>>>>>>
>>>>>> Thank You,
>>>>>> Sampad Mohapatra
>>>>>>
>>>>>>
>>>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>>>>  Virus-free.
>>>>>> www.avg.com
>>>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>>>> <#m_-2989848144765992876_m_-1553455650359693535_m_5415016674414042555_m_-7676868930208282950_m_-8358212102347321869_m_-6648754351699623829_m_1723920294658796898_m_-8550086026140872479_m_-203124547492808951_m_-2486225155787835700_m_2217726199504402898_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>> _______________________________________________
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>

Attachment: corePairHitProfiling.patch
Description: Binary data

_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to