Daniel Byrne

Hi, I can confirm the following tests are failing on Ubuntu 18.04 with gcc 8.4 - NvmCacheTest.EvictToNvmGet - NvmCacheTest.EvictToNvmGetCheckCtime  I did not get BaseAllocatorTest/2.LruRecordAccess to fail.

I just added that functionality to the latest version.

I rebased the PR, the outstanding issues from the review to address are: [cachelib/allocator/MemoryTierCacheConfig.h line 72 at r1](https://reviewable.io/reviews/intel/cachelib/10#-NAye4mmD4yawkN90N6S:-NAye4mn9cWG8xCV_-L0:b-6k9cji) ([raw file](https://github.com/intel/cachelib/blob/138f33ad6fa700735076282a4a1e7e015be91eee/cachelib/allocator/MemoryTierCacheConfig.h#L72)): } // TODO: move it to MMContainer config Looks like...

> _[`cachelib/allocator/CacheAllocator-inl.h` line 2508 at r2](https://reviewable.io/reviews/intel/cachelib/10#-NCR_OCe5XSabzOogFk0:-NCR_OCe5XSabzOogFk1:b-6sx5o0) ([raw file](https://github.com/intel/cachelib/blob/3181c63d6b8366565b77233310ab0d49ebc59ac3/cachelib/allocator/CacheAllocator-inl.h#L2508)):_ > > > ```objc > > : 0); > > for (TierId tid = 0; tid < getNumTiers(); tid++) { > >...

> @byrnedj Is the problem with LRU estimation caused by the fact that we allocate items with different sizes? Could we just use single allocation size for this test? No,...

> > > @byrnedj Is the problem with LRU estimation caused by the fact that we allocate items with different sizes? Could we just use single allocation size for this...

Great! Do you mind posting the performance numbers that you get from running your with your config (strategy == "dynamic") and without dynamic thresholding?