Экстремальный разгон процессора


Разбор полетов и крушений - часть 2


00000000: 33C9             XOR    ECX, ECX      ; (начальное значение ECX == 87h)

00000002: 33D2             XOR    EDX, EDX

00000004: 3BC2             CMP    EAX, EDX

Листинг 1 инструкция XOR ECX, ECX (для наглядности выделенная полужирным шрифтом) вызвала нарушение доступа, обратившись к памяти по адресу C23BD2BAh

Ничего не напоминает?! Постойте-постойте! Но ведь… адрес, вызывавший исключение, содержит в себе байты инструкции CMP EAX, EDX и частично XOR EDX, EDX, а если записать опкоды этих команд и сложить их со значением регистра ECX, получится: C23BD233h + 87h == C23BD2BAh, то есть тот самый непонятно откуда взявшийся адрес исключения (ну это раньше он был непонятным, теперь же все стало ясно). Записав инструкцию XOR ECX,ECX в двоичном виде (00011 0011 1100 100) и изменив всего один бит, превращающий C9h в 89h, мы получим… мы получим вот что!

00000000: 338933D23BC2     XOR    ECX,[ECX][0C23BD233]

Листинг 2 предыдущий фрагмент кода, в котором искажен всего один бит в инструкции XOR (C9h à 89h)

Оторвать мне хвост!!! Вот как оказывается в _действительности_ выглядела машинная команда, возбудившая исключение и вызвавшая сбой. Сразу видно, что АЛУ тут совершенно не причем. Процессор функционировал в общем-то исправно. Весь вопрос в том, почему Доктор Ватсон показал не "XOR ECX, [ECX][0C23BD233]", а "XOR ECX, ECX"?! Да потому, что искажение бита произошло в кэш-памяти первого уровня, а при составлении отчета Доктор Ватсон возвратил неискаженное содержимое кэш-памяти второго уровня!!! Откуда у меня такая уверенность, что все именно так и происходило? Так ведь процессор использует раздельную кэш память первого уровня для кода и данных, поэтому, прочитать истинное содержимое инструкции, вызывавшей сбой, Доктор Ватсон просто физически не в состоянии и это можно установить только косвенным путем.

Так, значит, главный виновник — это кэш? Дальнейшие эксперименты показали, что все обстоит именно так.Причем, сбои происходят в кэш памяти обоих уровней и вероятность их возникновения напрямую связана с интенсивностью кэш-промахов (т. е когда приложение обновляет большое количества кода/данных). С другой стороны, длительное хранение кода/данных без их модификации, создает другую угрозу — угрозу "загнивания" байт, особенно часто случающуюся при некачественном питании.

Изменить тактовую частоту кэш-модуля невозможно, но… если пораскинуть хвостом, можно найти довольно простое и элегантное решение.




Начало  Назад  Вперед



Книжный магазин