KCC 하계 학술대회가 끝난지도 벌써 2달이 지나고 이런 저런 일 (가정사, 다른 일 등등)로 인해 cache 연구는 좀 쉬어가게 되었다.
KCC 대회에 논문을 제출할 때도 연구에 아쉬운 부분이 많아서 추가로 진행할 연구 방향을 계획하였다.
해결하지 못한 문제
- 메모리 Overhead
- 실시간으로 데이터를 처리해야하는 캐시 특성상 모델의 주기적인 학습이 필요하다. 하지만 학습을 위한 모델이 가볍지 않을 뿐더러 학습을 위해 필요한 feature을 계산, 추출하는데에 많은 overhead가 발생한다.
- 이를 해결하기 위해 feature의 중요도를 계산하고 불필요한 feature를 학습에서 제외
- 경량 모델을 사용
- feature 계산을 위한 코드 최적화
- trace의 특성에 일반화된 캐시 구현
- cache에 접근하는 데이터들의 패턴은 상시 변한다. 따라서 학습을할 때 여러 trace의 특성에도 잘 예측할 수 있는 모델을 구현해야 한다.
- 본 연구 또한 Microsoft research의 hm서버에서 생성된 trace 에서는 LRU보다 Hit ratio가 향상되었지만 다른 13개의 서버중 5정도의 서버에서 생성된 trace뿐만 아니라 FIU, Systor17등 다른 workload의 trace에서도 성능이 향상되지 않았다.
- 이러한 문제가 나타나는 가능성이 몇가지 있다.
- LRU의 recency정보와 예측하려는 reusedistance의 충돌로 인해 성능이 향상되지 않았다.
- 모델의 정확도가 낮아 제대로 예측되지 않았기 때문에 다른 trace에서는 성능이 향상되지 않았다.
문제를 해결하기 위한 앞으로의 계획
당장 모든 문제를 해결하기에는 개인의 기술적인 한계가 있다..ㅜ 하나씩 차근차근 해결해보고자 앞으로의 계획을 구상했다.
#### reusedistance를 잘 예측하는것이 중요! (reusedistance만 잘 예측한다면 Hit ratio가 향상되지 않을 이유가 없다)
- 모델을 구성할 때 loss를 조절하여 feature중 reusedistance std의 값이 크면 분산이 크다는 의미이므로 reusedistance mean의 가중치를 낮추고 reusedistance std의 값이 작으면 reusedistance mean의 가중치를 높이는 방식으로 학습
(reusedistance next를 예측함에 있어 이전 reusedistance의 표준편차가 작다면 계속 비슷한 값으로 나오고 있다는 의미이기 때문에 reusedistance mean과 비슷한 값으로 예측하는 것이 좋다)
- LRU로 후보군 추출 –> Belady(예측 x , 실제)로 실험을 하였을 때 LRU와 Hit ratio 비교 - LRU보다 Hit ratio가 작게 나타난다면 LRU의 recency정보와 Belady의 reusedistance 특징이 충돌한다는 의미
- 예측 Belady로만 했을 때 Hit ratio 비교 - LRU보다 작으면 그냥 예측이 잘 안되어서 그런것
- 1인 경우 LRU 뺴고 * 만으로 학습 시켜보기 –> 캐시의 구조도 바꿔야할 것
- 2인 경우 LRU 넣고 * 로 학습 시켜보기