Multi tier shm attach

[byrnedj]

I disabled slab release in test due to some error with pruneFreeAllocations - we can discuss if there is a simple solution to storing multi-tier/single tier compressed pointer in the FreeLists (see AllocationClass.cpp and pruneFreeAllocations method.

The test also sporadically fails due to difficulties in estimating multi-tier LRU size. The current estimation method inserts an new item to the cache and waits for it to be evicted after a number of successive allocations of new arbitrary objects. The problems are the following:

• new item could fail being allocated in tier 0 so it is allocated in tier 1 and therefore will be evicted more quickly causing LRU size estimate to be too small.
• new item could fail being moved from tier 0 so it is evicted from cache, causing estimate to be too small again.

I'm open to suggestions on how to improve the LRU estimation or test.

---

This change is 

[igchor]

@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?

Also, I think you should split the testMultiTierSerialization into 2 tests.

[byrnedj]

@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, the problem is that in multi-tier the entire LRU (compared to single tier) is split between tier 0 and tier 1, and if we fail to move an item from tier 0 to tier 1, it gets evicted, so the estimation technique will think LRU size is however many items it took for that item to get evicted. And because it was evicted out of tier 0 - then the estimation will too small. Because actual LRU size (tier 0 + tier 1) would be when the item gets evicted out of tier 1.

Also, I think you should split the testMultiTierSerialization into 2 tests.
Will do.

[igchor]

@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, the problem is that in multi-tier the entire LRU (compared to single tier) is split between tier 0 and tier 1, and if we fail to move an item from tier 0 to tier 1, it gets evicted, so the estimation technique will think LRU size is however many items it took for that item to get evicted. And because it was evicted out of tier 0 - then the estimation will too small. Because actual LRU size (tier 0 + tier 1) would be when the item gets evicted out of tier 1.

Also, I think you should split the testMultiTierSerialization into 2 tests.
Will do.

But why does moving the items fail? Can't we perform item insertion deterministically?

[byrnedj]

@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, the problem is that in multi-tier the entire LRU (compared to single tier) is split between tier 0 and tier 1, and if we fail to move an item from tier 0 to tier 1, it gets evicted, so the estimation technique will think LRU size is however many items it took for that item to get evicted. And because it was evicted out of tier 0 - then the estimation will too small. Because actual LRU size (tier 0 + tier 1) would be when the item gets evicted out of tier 1.

Also, I think you should split the testMultiTierSerialization into 2 tests.
Will do.

But why does moving the items fail? Can't we perform item insertion deterministically?

Using only 1 class removes the tests LRU estimation failure. I updated the test accordingly.

I don't think it makes sense to split into two cases since testMultiTierSerialization should create a cache and then try to reattach to it (verifying the expected state).