.. (לתיקייה המכילה) | ||
The limit of 6 memory lists is too restrictive for the specific algorithm we want to use, can we use more? | |
The motivation for restricting the number of lists is to keep your algorithms simple and manageable. If your algorithm cannot work with 6 lists only and you can justify the use of more lists, then you can use up to _10_ lists. Make sure that you meet all the other constraints, and explain your needs clearly. |
The HW PDF states that we should return a hit for a read request if its LBA or fingerprint are in the cache, but the code does not search for the fingerprint in the cache. Is this a bug? | |
The code is correct. When you receive a read request for LBA A, you do not know the content of the requested block. Your only way to know that the content of block A is identical to some other block B is if the metadata for A points to B or to its fingerprint. For this, you need to find the metadata for A in the cache (see slide 17 in lecture 10). |
Follow-up: so why do the read requests in the traces contain fingerprints? | |
They are there to help you verify that your code is correct and the cache “returns” the correct content. |
The HW PDF states that "the total number of FP-items should not exceed the cache size X 2", and "the total number of LBA-items should not exceed the cache size X 2", but the code only checks that the total number of metadata items does not exceed the cache size X 4. | |
No. The requirements in the PDF hold. Your implementation should enforce the "cache size X 2" limit on each item type. |