To implement multi-tier data movement we have increased size of CompressedPtr from 32 to 64 bits (so that we can encode tier ID inside CompressedPtr). This resulted in increasing CacheItem size. We have implemented a few workarounds in tests which started failing due to this increase in size.
Think whether we could avoid increasing CompressedPtr size. Keep in mind that originally CompressedPtr was only able to address 256GB of memory which might be to little when considering PMEM.
If keeping sizeof(CompressedPtr) == 4 is not possible then we should at least make the tests more generic so that they do not depend on size of the Item (right now, we have just added or subtracted some hardcoded value from item/pool sizes which are used in tests).
To implement multi-tier data movement we have increased size of CompressedPtr from 32 to 64 bits (so that we can encode tier ID inside CompressedPtr). This resulted in increasing CacheItem size. We have implemented a few workarounds in tests which started failing due to this increase in size.
Think whether we could avoid increasing CompressedPtr size. Keep in mind that originally CompressedPtr was only able to address 256GB of memory which might be to little when considering PMEM.
If keeping sizeof(CompressedPtr) == 4 is not possible then we should at least make the tests more generic so that they do not depend on size of the Item (right now, we have just added or subtracted some hardcoded value from item/pool sizes which are used in tests).