0

I want to learn more about the cache replacement algorithm. For example, I want to know when the cache is replaced, what data is replaced, and what data is brought to the cache. It is a good choice to output this information using the debug flag in gem5. I use classic cache. I created a debug flag to output this information. But I found that when performing the replacement algorithm, it is easy to output the data in which set and way, but it is difficult to output the data in the cacheline. Because I found that only valid, invalid, set, way information is recorded in the replacement algorithm.

  1. I later found uint8_t *data in gem5/src/mem/cache/cache_blk.hh. This should be cache block data, but why is there only one byte, isn't a cachline 64 bytes?
  2. What I don't understand is that when replacing, it will first find the set where the data is located according to the address. Then look for a cacheline based on the replacement algorithm. But I found that the getPossibleEntries function of the gem5/src/mem/cache/tags/indexing_policies/set_associative.cc file, return sets[extractSet(addr)]; sometimes returns four addresses, sometimes 8 are returned. Shouldn't it always return every cacheline of the cache set where the address is located? That is 8 addresses?

By the way, I use the DerivO3CPU Thanks for all related answers.

Gerrie
  • 736
  • 3
  • 18
  • This may help: https://stackoverflow.com/questions/63193082/how-to-trace-the-data-that-is-going-through-caches-and-dram-memory-in-gem5 – Ciro Santilli Nov 22 '20 at 20:05
  • When you ask questions about the cache, please inform which cache model you are talking about. Ruby or Classic? Also, I don't understand the goal of your question. Do you want to know about the replacement data, or the data block's contents? In any case, you can create a new debug flag and print whatever you want whenever you find pertinent (I'd need answers to those previous questions to be able to give more details). – Daniel Carvalho Nov 22 '20 at 21:42
  • Thank you for your suggestion, I provided more details – Gerrie Nov 23 '20 at 01:34
  • You haven't answered any of my questions and the details have nothing to do with the original question. Anyway, I will assume you are using the Classic model (src/mem/cache). uint8_t* is a pointer to the first byte of cache line data. There are many tutorials on C/C++ pointers on the internet, so I will not enter into details. "Shouldn't it always return every cache line of the set?" Correct. "That is, 8 addresses?" No, that depends on your configurations. You probably added a print to the cache class, and while you are thinking of a 8-way L2, your L1s are probably 4-way, which are printed too – Daniel Carvalho Nov 23 '20 at 08:32
  • thank you for your reply. I pointed out in the question that it is the classic cache. It may not be conspicuous, I will bold it later. It is common to use char * as the first address, but it is strange to use uint8_t as the first address. In this case, do I need printf("%s",(char*)uint8_t_data) ? And I see it sometimes shows 4 addresses, sometimes 8 addresses. I saw it in the output size of RandomRP::getVictim(const ReplacementCandidates& candidates) – Gerrie Nov 23 '20 at 09:02

1 Answers1

1

As a general note, there is a debug flag called CacheRepl. You may want to print whatever information you need from replacements using it.

1 - The data pointer is a pointer to the first byte of the data. It is not a string; it does not have a null marker at the end. This means that you cannot %s it right off the bat; you need to iterate through every byte using the blkSize (cache line size) to print it with %x (e.g., for (int i = 0; i < blkSize; i++) printf("%x ", blk->data[i])).

The following question can help if you want to print it as a string: Convert C++ byte array to a C string

2 - When you print anything in the Replacement Policy (RP), every object that uses that given RP will print. This includes prefetchers, buffers, tags, etc.

I don't know what is your system configuration, but you probably have at least two different tables that use the RandomRP: at least one with a 4-way associativity, and at least one with a 8-way associativity. When there are four addresses, these are the candidates for the 4-way associative table. When there are 8, it is the 8-way associative.

If, for example, you want to study the replacement information of the L2 cache, and you know that it is the only table that is 8-way associative, then you can just ignore the results that only have four addresses, since they'd refer to the replacement of other tables.

Daniel Carvalho
  • 473
  • 1
  • 5
  • 17
  • You are so wise. I just checked and the output of four is icache, and the output of 8 is dcache. – Gerrie Nov 23 '20 at 11:18