2012-04-19 2 views
0

все.Clock-Pro замена кэша

Я прочитал много статей о алгоритме замены кэша ClockPro - улучшена версия замены часов. Для удобства сначала я использовал Clock. Теперь я хочу реализовать в Java Clock-Pro 2 руки (горячая и холодная, а не 3 руки в реальном алгоритме). Я нашел описание:

The ClockPro Algorithm 

On Start(): 
    cold_block = first block 
    hot_block = first block 

On Memory Lookup(): 
    curr_block = NULL 
    If block is in cache: 
     Set clock bit 
     Return block to CPU 
    Else: 
     While curr_block == NULL: 
      If cold_block.clockbit == 0: 
       curr_block = cold_block 
      Else if cold_block.test == 1 : 
       Turn cold hand block hot 
       Unset the clockbit 
       Run Hot Hand Algorithm 
      Else: 
       cold_block.clockbit = 0 
      cold_block = cold_block.next 

    If curr_block is dirty : write 
    Find accessed block in memory 
    Return fetched block to the CPU 
    Replace curr_block with fetched one 

Hot Hand Algorithm() : 
    curr_block = NULL 
    While curr_block == NULL: 
     If hot_block is cold : 
      hot_block.text = 0 
     Else if hot_block.clockbit == 0 : 
      Turn the block cold 
     Else : 
      hot_block.clockbit = 0 
     hot_block = hot_block.next 

Если кто-нибудь пробовал, пожалуйста, ответить на некоторые вопросы:

Что тест период? Когда он начнется и какой тип мы можем использовать для него. Это немного, что может сказать нам, находится ли объект в тестовом периоде или нет, или это счетчик? Могут ли обе руки указывать на один блок за несколько секунд?

Если кто-нибудь, пожалуйста, помогите мне смоделировать такое поведение алгоритма в простом примере. Спасибо.

ответ

1

Этот код является очень неполным. По крайней мере две важные части отсутствуют: 1) Тест руки (тест руки) 2) Горячая/холодная страница reatio адаптивность

Я должен сказать, что первоначальный документ по этому вопросу действительно не хватает многих важных деталей.

В настоящее время я пишу реализацию Python, но я еще не выпустил источник, потому что качество еще недостаточно.

URL проекта: https://bitbucket.org/samilehtinen/pyclockpro

Даже когда код выпущен, я совершенно уверен, что есть небольшие, но важные детали, которые могут потребовать тонкой настройки.

Нравится: 1) Коэффициент распределения памяти при горячем/холодном режиме при инициализации, я настроил так, что для холодных страниц назначается 100% памяти. 2) Что делать, если горячее распределение настроено так низко, что горячая рука должна пройти холодную руку. Я предполагаю, что в этой ситуации горячее распределение просто игнорируется, потому что горячая рука, проходящая мимо холодной руки, сломает все. В этой ситуации рука hot также очищает все страницы-нерезиденты.

Основываясь на данных испытаний, моя реализация, похоже, очень хорошо настроена.

Ответы на ваши вопросы: Период испытания - это когда ключ хранится, но значение отбрасывается. На циферблате вы увидите эти записи между холодом и тестом. Я использовал int для типа страницы, 0 нерезидентную холодную страницу (тестовую страницу), 1 для холодных страниц и 2 для горячих страниц. Если вы используете указатели на данные, если указатель Null, тогда страница является нерезидентной страницей, потому что у вас есть только ключ без данных (значение).

Да, обе и все руки могут указывать на один блок в разы. Главный вопрос заключался в том, могут ли руки пройти мимо друг друга. Я подумал, что если это случится, все сломается. Таким образом, в основном горячая рука может подталкивать тестовую руку, и она может подталкивать холодную руку. В зависимости от того, как вы реализуете вещи. Или, если вы сделаете это, как в бумаге, рука горячая может пройти мимо тестовой руки, но в этой ситуации она перетаскивает тестовую руку вместе с ней. И, насколько я знаю, рука не может пройти мимо холодной руки, или если вы ее реализуете, то это делает работу холодной руки, но все еще тянет холодную руку с горячей рукой.

Трудно сделать простой пример, потому что это не просто. Существуют также некоторые краевые случаи, которые требуют обработки, по крайней мере, упомянутых здесь ситуаций.Также адаптивность добавляет граничные случаи, потому что во время итеративной обработки память может меняться. Поддержание 100% -ного распределения в этих ситуациях требует некоторых дополнительных проверок. Если вы разрешаете +/- несколько блоков в размере кеша, реализация проще.

Обновление, исходный код и документация на Python теперь выпущены. Итак, в Python есть полная рабочая модель.