@SergeySerge11

Как в виртуальных процессорах устроена виртуальная память?

Смотрю код qemu и других виртуальных машин(посматриваю), не могу понять зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины? Зачем адрес куда-то в кеш записывать, если этот кеш 3 уровня, или регистр лежит с точки зрения внешней среды, там же где и ram и доступ должен быть одинаковым.

И второе. Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше. На бенчмаркинге доступ словарь как раз этот порядок показывает по сравнению с линейным массивом.
А для процессора абортивный словарь то же самое что и доступ к элементу. Если Можно ли так написать. За счет параллельности сравнивания битов. чего язык высоко уровня не может.
(Правда после этого всего, я начинаю понимать зачем там TLB буфера, хотя и сам поиск в TLB буфере на 1024 значений будет дольше).

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .
Но виртуальные процессоры работают быстрее, чем я ожидаю. А ожидаю, я раз так в 100 минимум медленнее исполнение.(При этом они реализуют то что вроде как не нужно)
Единственное, что, может быть, что вся это рутина, jit-ется. И после одного исполнения упрощается в одну команду. (Но это предположение пока)
  • Вопрос задан
  • 395 просмотров
Решения вопроса 1
jcmvbkbc
@jcmvbkbc
"I'm here to consult you" © Dogbert
зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины?

Фронт-енды QEMU реализуют большую часть наблюдаемого поведения моделируемого ими процессора. Одно большое исключение -- это процессорный кеш: QEMU не моделирует поведение процессорного кеша. TLB во многих архитектурах доступен для прямого чтения/записи через команды процессора, нельзя сказать что он "внутри машины".

Зачем адрес куда-то в кеш записывать, если этот кеш 3 уровня, или регистр лежит с точки зрения внешней среды, там же где и ram и доступ должен быть одинаковым.

Покажи пример, обсудим конкретику?

Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше.

Это какие-то очень странные допущения и прикидки, а то, что они не учитывают такие параметры как размер TLB и его ассоциативность, показывает их безосновательность.

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .

Нифига. В QEMU есть два уровня TLB -- один, моделируемый процессорным фронт-ендом, второй -- собственный TLB QEMU softmmu независимый от эмулируемого процессора, поиск по которому встроен в генерируемый JIT (который в QEMU называется TCG) код. Собственный TLB QEMU прямого отображения, т.е. поиск в этом TLB -- это всегда проверка одного элемента массива и загрузка одного отображения в случае успеха. Например вот так генерируется код для этого на хосте x86. В случае неудачи происходит вызов функции поиска в архитектурно-зависимом TLB. Вот так этот вызов генерируется, а вот пример его реализации во фронт-енде. Поскольку этот TLB моделирует конкретную архитектуру его ассоциативность может варьироваться в широких пределах, или он может вообще отсутствовать. В случае промаха или отсутствия TLB поиск может либо продолжаться дальше в таблицах страниц, например так, либо фронт-енд генерирует исключение доступа к памяти, например так.

В итоге операций при поиске трансляции для виртуального адреса может быть гораздо больше чем 32, которые ты предположил, в случае промахов, но цена промахов амортизируется тем, что чем более они дороги, тем более они редки. Но, конечно, задача намеренно обращающаяся к никогда не повторяющимся страницам памяти будет иметь очень низкую производительность при выполнении в QEMU softmmu.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы