Весовой коэффициент для определения виртуальных ядер для виртуальной машины - PullRequest
0 голосов
/ 14 июня 2019

Постановка задачи (с примером)

Мне нужно разработать алгоритм, который решит назначить виртуальные ядра для VM.

например. У меня есть 2 варианта для создания machines. Это может быть физическим / виртуальным. Давайте рассмотрим 2 случая:

  • Если мне требуется 1 ядро ​​2.3 GHz, это означает, что мне требуется процессор, способный выполнять инструкции
    2.3 * 10^9. В случае назначения процессора, обладающего этими возможностями, физической машине, это нормально.
  • Но когда я хочу назначить 1 ядро ​​2.3 GHz виртуальной машине, я хочу использовать константу weight-factor со значением 0,8. Я делю «количество инструкций», т. Е. 2,3 * 10 ^ 9, с весовым коэффициентом 0.8. Таким образом, требуемые возможности обработки для виртуальной машины должны быть масштабированы по этому коэффициенту. Значение оказывается 2,875 * 10 ^ 9.

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

Если да, существуют ли какие-либо связанные исследования или доказательства концепций использования этого механизма определения числа процессоров, требуемых для виртуальной машины?

1 Ответ

1 голос
/ 14 июня 2019

в общем; для SMT (например, гиперпоточность) на 80x86 процессорах; со всеми логическими процессорами внутри ядра, выполняющими работу:

  • Если все логические ЦП используют разные ресурсы (например, может, один использует инструкции SSE, а другой - целочисленные инструкции общего назначения); каждый логический процессор может работать так же быстро, как если бы это был единственный логический процессор, использующий ядро ​​

  • Если все логические ЦП борются за один и тот же ресурс / с, производительность ядра может быть поровну поделена на логические ЦП (например, с 2 логическими ЦП на ядро, каждый логический ЦП может получить половину производительности). было бы, если бы это был единственный логический процессор, использующий ядро).

Обратите внимание, что это также может относиться к AMD Bulldozer (даже если он не считается SMT), где FPU распределяется между ядрами, а остальная часть ядра - нет (другими словами, если оба ядра стучат по FPU на в это же время будет работать производительность обоих ядер).

Это означает, что (например) для ядра 2.3 GHz с 2 логическими ЦП на ядро ​​каждый логический ЦП может получить (в грубом эквиваленте) что-нибудь от 0,75 ГГц до 3,4 ГГц; в зависимости от точного кода, который выполняется каждым логическим процессором, и различных условий управления питанием (термическое регулирование, турбонаддув и т. д.).

Однако фактическая производительность также зависит от таких вещей, как кеши (и совместное использование кеша), пропускная способность микросхемы ОЗУ и накладные расходы виртуальных машин (которые варьируются от «экстремальных» для кода, вызывающего огромное количество VMEXIT, почти до нуля). Имея это в виду (например, для 2.3 GHz ядра), каждый логический ЦП может получить (грубый эквивалент) что угодно от нескольких сотен МГц до 3,4 ГГц; в зависимости от многих факторов.

По существу; ваш «вес» должен быть любым случайным числом от 0,1 до 1,0, в зависимости от того, что вы не можете / не будете знать.

К счастью, любой код, работающий внутри виртуальной машины, скорее всего, предназначен для работы с различными процессорами с разными скоростями; поэтому достаточно просто назначить любой ЦП для виртуальной машины и позволить программному обеспечению, работающему на виртуальной машине, адаптироваться к любой производительности, которой она была предоставлена.

В качестве альтернативы (если вам нужно гарантировать какую-то производительность или вы хотите попытаться скрыть разницу во времени, чтобы код в ВМ не знал, что он не работает на реальном оборудовании); Вы можете отслеживать «виртуальное время» и «время настенных часов» и пытаться примерно синхронизировать это время. Например, если «виртуальное время» движется слишком медленно (например, потому что код внутри ВМ вызывает много VMEXIT), вы можете притвориться, что виртуальный ЦП перегрелся и начал термическое регулирование, чтобы создать правдоподобное / реалистичное оправдание, которое позволяет «виртуальному» время "догнать" время настенных часов "; и если что-то может произойти раньше, чем должно (например, вы знаете, что гость ждет виртуального таймера, который истекает через 100 миллисекунд и может делать вид, что прошло 100 миллисекунд, когда это не произошло), вы можете намеренно замедлять работу виртуальной машины до тех пор, пока "" Настенные часы "догоняет" виртуальное время ". В этом случае было бы неплохо дать себе место для перемещения (представьте, что виртуальный процессор медленнее, чем мог бы быть, потому что виртуальную машину легче замедлить, чем ускорить). Конечно, это также может быть использовано для скрытия различий во времени, вызванных SMT, и может скрыть разницу во времени, вызванную совместным использованием ЦП между виртуальными машинами (например, когда виртуальных ядер больше, чем реальных ядер).

Примечание: «альтернативная альтернатива» состоит в том, чтобы сказать, что «виртуальное время» не имеет никакого отношения к «настенным часам» вообще. Это позволяет (например,) эмулировать процессор с частотой 6 ГГц, когда все, что у вас есть, это старый процессор с частотой 1 ГГц - это просто означает, что на 1 «виртуальную секунду» уходит около 6 «секунд настенных часов».

Также обратите внимание, что со всеми проблемами безопасности за последние 18+ месяцев (например, призрак) Я бы настоятельно рекомендовал использовать «ядра» в качестве минимально назначаемой единицы , чтобы в любой момент времени Виртуальная машина получает все логические процессоры, принадлежащие ядру, или ни один из логических процессоров, принадлежащих ядру (и отказывается разрешить одновременное назначение логических процессоров в одном и том же ядре разным виртуальным машинам, поскольку данные, вероятно, будут утекать через любую из множество побочных каналов от одной виртуальной машины к другой).

...