[gem5-users] Regarding ruby prefetcher requestIssued and requestCompleted bitset
In the ruby prefetcher, requestIssued and requestCompleted bitsets are present to track the prefetch requests that are issued and completed. Where are these bits getting set and reset? These are only referenced by the observeMiss() function. -- Thanks and regards, Kavya ___ 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] Re: Handling a cache miss in gem5
Hi Daniel, Thanks for your response! As I understand from the code, the access latency for parallel-access cache (meaning the cache look up happens in parallel) is determined in gem5 by max(lookup latency, data latency), and for sequential access-mode it becomes (lookup latency + data latency). I was particularly interested in observing what numbers of cycles is spent in classic cache for handling a miss. gem5 code designates two such latencies: *lookup latency* and *forward latency*. *Both of them are exactly equal to the tag latency*. When a cache miss occurs, gem5 assigns "*lat = lookupLatency*", where "lat" is gem5's internal latency variable to hold the value of appropriate latency in terms of clock cycles. This assignment is quite intuitive, and it *creates an impression that whatever value lookup latency contains is used to handle a cache miss*. If I pass any value "X" cycles into lat by "lat = X", it does not get reflected in the system. But if I force forward latency to be "X", I see it being reflected in the system handling the cache miss. *So, I find even though the assignment "lat = lookupLatency" created an impression that "lookupLatency" is used to handle a miss, "forwardLatency" is actually used.* All these things do not matter because lookup latency = forward latency = tag latency (by default). Regards, Aritra On Fri, Sep 25, 2020 at 3:42 PM Daniel Carvalho wrote: > Hello Aritra, > > It seems that the tag lookup latency is indeed disregarded on misses > (except for SW prefetches). The cache behaves as if a miss is always > assumed to happen and "pre-prepared" in parallel with the tag lookup. I am > not sure if this was a design decision, or an implementation consequence, > but my guess is the latter - there is no explicit definition of the cache > model pursued by the classic cache. > > Regards, > Daniel > Em sexta-feira, 25 de setembro de 2020 11:00:39 GMT+2, Aritra Bagchi via > gem5-users escreveu: > > > Just a humble reminder. Any comment would be highly solicited. > > Thanks, > Aritra > > On Thu, 24 Sep, 2020, 12:22 PM Aritra Bagchi, > wrote: > > Hi all, > > While experimenting with gem5 classic cache, I tried to find out how an > access miss is handled and with what latency. > > Even if in *cache/tags/base_set_assoc.hh*, the access (here a miss) > handling latency *"lat"* gets assigned to the *"lookupLatency"*, the > actual latency that is used to handle a miss (in *cache/base.cc: > handleTimingReqMiss( )* method) is the *"forwardLatency"*. This is my > observation. > > Both *"lookupLatency"* and *"forwardLatency"* are assigned to the cache > *"tag_latency"*, which is okay! But I experimented with different values > for them and observed that the value of *"forwardLatency"* actually gets > reflected ( in terms of the clock cycle delay from the *cpu_side* port to > the *mem_side* port) into the system for handling a cache miss. > > Could someone please confirm whether my observation and understanding is > correct or not? > > Regards, > Aritra > > ___ > 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] Add FLUSH in MESI prtocol
In Ruby System, it is only supported flush by MOESI_hammer coherence protocol, flush isn’t supported by MESI_*. This means that some protocols cannot be used when checkpointing or switching from detailed to less detailed timing modes. How can add flush in MESI_Three_Level protocol? as I know, adding flush is hard. There are many states and events that need to be considered to support flush in the protocol, are there any good ideas to add flush to the protocol? It takes fundamentally updating the coherence protocol, ___ 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] MOESI_CMP_directory coherence protocol
MOESI_CMP_directory-L1cache.sm , what is the difference between the events
Writeback_Ack_Data and Writeback_Ack?
Writeback_Ack, desc="Writeback O.K. from directory";
Writeback_Ack_Data, desc="Writeback O.K. from directory";
When the Writeback_Ack is triggered, there is no qq_sendWBDataFromTBEToL2, why
the state
is still converted to I ?
transition({SI, OI, MI}, Writeback_Ack, I) {
g_sendUnblock;
s_deallocateTBE;
l_popForwardQueue;
}
transition({SI, OI, MI}, Writeback_Ack_Data, I) {
qq_sendWBDataFromTBEToL2; // always send data
s_deallocateTBE;
l_popForwardQueue;
}
___
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] Re: Handling a cache miss in gem5
Hello Aritra, It seems that the tag lookup latency is indeed disregarded on misses (except for SW prefetches). The cache behaves as if a miss is always assumed to happen and "pre-prepared" in parallel with the tag lookup. I am not sure if this was a design decision, or an implementation consequence, but my guess is the latter - there is no explicit definition of the cache model pursued by the classic cache. Regards,DanielEm sexta-feira, 25 de setembro de 2020 11:00:39 GMT+2, Aritra Bagchi via gem5-users escreveu: Just a humble reminder. Any comment would be highly solicited. Thanks,Aritra On Thu, 24 Sep, 2020, 12:22 PM Aritra Bagchi, wrote: Hi all, While experimenting with gem5 classic cache, I tried to find out how an access miss is handled and with what latency. Even if in cache/tags/base_set_assoc.hh, the access (here a miss) handling latency "lat" gets assigned to the "lookupLatency", the actual latency that is used to handle a miss (in cache/base.cc: handleTimingReqMiss( ) method) is the "forwardLatency". This is my observation. Both "lookupLatency" and "forwardLatency" are assigned to the cache "tag_latency", which is okay! But I experimented with different values for them and observed that the value of "forwardLatency" actually gets reflected ( in terms of the clock cycle delay from the cpu_side port to the mem_side port) into the system for handling a cache miss. Could someone please confirm whether my observation and understanding is correct or not? Regards,Aritra ___ 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] Re: Handling a cache miss in gem5
Just a humble reminder. Any comment would be highly solicited. Thanks, Aritra On Thu, 24 Sep, 2020, 12:22 PM Aritra Bagchi, wrote: > Hi all, > > While experimenting with gem5 classic cache, I tried to find out how an > access miss is handled and with what latency. > > Even if in *cache/tags/base_set_assoc.hh*, the access (here a miss) > handling latency *"lat"* gets assigned to the *"lookupLatency"*, the > actual latency that is used to handle a miss (in *cache/base.cc: > handleTimingReqMiss( )* method) is the *"forwardLatency"*. This is my > observation. > > Both *"lookupLatency"* and *"forwardLatency"* are assigned to the cache > *"tag_latency"*, which is okay! But I experimented with different values > for them and observed that the value of *"forwardLatency"* actually gets > reflected ( in terms of the clock cycle delay from the *cpu_side* port to > the *mem_side* port) into the system for handling a cache miss. > > Could someone please confirm whether my observation and understanding is > correct or not? > > Regards, > Aritra > > ___ 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
