Just code IT

Тайминги на Intel — плавают!

Ни для кого не секрет, что время исполнения инструкций или их последовательностей в общем случае не детерминировано на процессорах Intel. Всему виной сложный многоступенчатый конвейер, а также его начальное состояние к моменту исполнения макроинструкции (то есть инструкции из x86 ISA, которая превращается внутри ядра в набор микроинструкций для конкретной микроархитектуры).

Есть ли гипертрединг? Какая заполненность таблицы переименования регистров? Какая очередь на буфере переупорядочивания? Сколько свободных скорбордов? Все это сильно влияет на время нахождения макроинструкции на конвейере. Есть, кстати, интересные случаи, когда макроинструкция будет находиться на конвейере 0 тактов – например, когда происходит склеивание инструкции сравнения и перехода (cmp + jxx) в одну микроинструкцию.

А еще есть нюки (nukes). Это асинхронные события, которые стопорят весь конвейер. Простой пример - # PF при фетче памяти в инструкции mov. Примеры посложнее – это когда в эррате пишут «Under complex microarchitectural conditions».

Если выходить на макроуровень – у нас есть различные «режимы» работы процессора. Все, наверное, знают про ring0 и ring3. Часто при этом забывают про ортогональные режимы (или еще хуже – называют их ring -1 -2 и т.п.). Это, например, vmx (виртуализация); smm (system management mode), который до сих пор популярен в том же управлении питанием; sgx – анклавы, smx, probe mode и много-много других. Переход в эти режимы вытесняет исполнение в предыдущем: физическое ядро ведь одно и то же! И эти вытеснения в общем случае могут происходить когда угодно.

В общем, не удивляйтесь, если вы исполняетесь в наиболее привилегированном, по вашему мнению, режиме и внезапно теряете где-то тысячи тиков tsc. Это нормально, и все операционные системы давно к этому приспособились.

#digest

👍8

www.tgoop.com/justcodeit_channel/46

1.36K viewsedited  Jun 9, 2022 at 10:02

Тайминги на Intel — плавают!

Ни для кого не секрет, что время исполнения инструкций или их последовательностей в общем случае не детерминировано на процессорах Intel. Всему виной сложный многоступенчатый конвейер, а также его начальное состояние к моменту исполнения макроинструкции (то есть инструкции из x86 ISA, которая превращается внутри ядра в набор микроинструкций для конкретной микроархитектуры).

Есть ли гипертрединг? Какая заполненность таблицы переименования регистров? Какая очередь на буфере переупорядочивания? Сколько свободных скорбордов? Все это сильно влияет на время нахождения макроинструкции на конвейере. Есть, кстати, интересные случаи, когда макроинструкция будет находиться на конвейере 0 тактов – например, когда происходит склеивание инструкции сравнения и перехода (cmp + jxx) в одну микроинструкцию.

А еще есть нюки (nukes). Это асинхронные события, которые стопорят весь конвейер. Простой пример - # PF при фетче памяти в инструкции mov. Примеры посложнее – это когда в эррате пишут «Under complex microarchitectural conditions».

Если выходить на макроуровень – у нас есть различные «режимы» работы процессора. Все, наверное, знают про ring0 и ring3. Часто при этом забывают про ортогональные режимы (или еще хуже – называют их ring -1 -2 и т.п.). Это, например, vmx (виртуализация); smm (system management mode), который до сих пор популярен в том же управлении питанием; sgx – анклавы, smx, probe mode и много-много других. Переход в эти режимы вытесняет исполнение в предыдущем: физическое ядро ведь одно и то же! И эти вытеснения в общем случае могут происходить когда угодно.

В общем, не удивляйтесь, если вы исполняетесь в наиболее привилегированном, по вашему мнению, режиме и внезапно теряете где-то тысячи тиков tsc. Это нормально, и все операционные системы давно к этому приспособились.

#digest

BY Just code IT