gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Sector tags

MN
Mr Nazmus Sakib
Mon, Apr 22, 2024 3:14 PM

Hello. I was going over the files for sector tags and trying to figure out how they are supposed to be working.
What I can understand is, compared with a set associative cache, the "sets" are sets of "sectors" instead of "ways", each sector having one or more subsectors (which are the actual cache block).
I have 2 questions:

  1. in sector_tags.cc, the invalidate() does not invalidate all blocks of a sector, as other blocks might be using the tag. Same in the moveblocks(). However in findvictim(), all blocks of a sector are evicted. So, in terms of replacement, all blocks of a sector is read from the downstream cache ? In ther words, the granularity of data movement is "sector" ?
    But in insertBlock(), only single blocks are inserted. Does this mean, after an eviction,  the timing for a "sector" to be "filled" is the sum of the timing of all individual cache blocks in that sector ?
  2. In the regenerateBlkAddr(), I got how sector address was calculated. But generate the location within sector, "sector offset" was shifted by "sectorShift". I was assuming this "sectorShift" will reflect the "number of bits required to represent number of blocks in a sector".
    However, "sectorShift" was initialized as "sectorShift(floorLog2(blkSize))". Now, from Tags.py, I can see that blkSize is the cacheline size. How does cacheline size relates to "number of bits required to represent number of blocks in a sector ?
Hello. I was going over the files for sector tags and trying to figure out how they are supposed to be working. What I can understand is, compared with a set associative cache, the "sets" are sets of "sectors" instead of "ways", each sector having one or more subsectors (which are the actual cache block). I have 2 questions: 1. in sector_tags.cc, the invalidate() does not invalidate all blocks of a sector, as other blocks might be using the tag. Same in the moveblocks(). However in findvictim(), all blocks of a sector are evicted. So, in terms of replacement, all blocks of a sector is read from the downstream cache ? In ther words, the granularity of data movement is "sector" ? But in insertBlock(), only single blocks are inserted. Does this mean, after an eviction, the timing for a "sector" to be "filled" is the sum of the timing of all individual cache blocks in that sector ? 2. In the regenerateBlkAddr(), I got how sector address was calculated. But generate the location within sector, "sector offset" was shifted by "sectorShift". I was assuming this "sectorShift" will reflect the "number of bits required to represent number of blocks in a sector". However, "sectorShift" was initialized as "sectorShift(floorLog2(blkSize))". Now, from Tags.py, I can see that blkSize is the cacheline size. How does cacheline size relates to "number of bits required to represent number of blocks in a sector ?