Здравствуйте, Евгений Музыченко, Вы писали:
C>>Десятки тысяч операций в секунду получаются легко и непринуждённо. ЕМ>Для обмена сетевыми пакетами с драйвером до сих пор не придумали прямого способа, вроде разделяемого кольцевого буфера? Мрак. Для звука придумали больше десяти лет назад.
Тогда потом придётся весь TCP и прочие реализовать в userspace. Ни одна из БД этого не делает.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Много — это само собой. А каким виртуалкам в устоявшемся режиме работы потребны тысячи-десятки тысяч обращений к ядру хоста?
Здравствуйте, Sharov, Вы писали:
ЕМ>>каким виртуалкам в устоявшемся режиме работы потребны тысячи-десятки тысяч обращений к ядру хоста?
S>На которых крутятся бд, например.
Можно пример типичной (то есть, весьма распространенной) БД, которой большинство из [десятков] тысяч запросов в секунду нужно проводить именно в транзакционной форме? На мой взгляд, бОльшая часть запросов к любой БД — это таки чтение, которое хорошо буферизуется и не требует тразакционности.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Sharov, Вы писали:
S>>Для работы с железом. Их может быть много.
ЕМ>Много — это само собой. А каким виртуалкам в устоявшемся режиме работы потребны тысячи-десятки тысяч обращений к ядру хоста?
Виртуальные машины часто обрабатываются в ядре хоста, например при page-fault и при эмуляции устройств. В последнем случае часто обращаются еще и в user-level хоста.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Виртуальные машины часто обрабатываются в ядре хоста, например при page-fault и при эмуляции устройств.
Хороший VMM (а плохих в профессиональном применении не держат) не позволяет VM генерировать PF без крайней необходимости. Встретив первое обращение к регистру/памяти эмулируемого устройства, он заменяет его на обычный вызов функции поддержки, так что все остальные обращения из того же места идут без лишних расходов. В устоявшемся режиме он дергает ядро хоста только по необходимости (например, для обращения к хостовым устройствам, файлам за пределами буферизации и т.п.).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Хороший VMM (а плохих в профессиональном применении не держат) не позволяет VM генерировать PF без крайней необходимости.
page fault в хост выполняется при любом обращении к диску + Copy-on-Write при запуске программ.
EM>Встретив первое обращение к регистру/памяти эмулируемого устройства, он заменяет его на обычный вызов функции поддержки, так что все остальные обращения из того же места идут без лишних расходов.
То, что ты пишешь — очень странно. Такого не может быть, т.к. даже без виртуальных машин память ввода-вывода устройств не кешируется ни в коем случае.
EM>В устоявшемся режиме он дергает ядро хоста только по необходимости (например, для обращения к хостовым устройствам, файлам за пределами буферизации и т.п.).
Про обращение к хостовым устройствам в режиме pass-through точно не скажу, но, скорее всего, эти вызовы проходят через ядро хоста.
А эмулируемые устройства в большинстве случаев вообще обрабатываются в user-mode хоста. По-крайней мере, в kvm(кроме vhost-net? которое обрабатывается в хостовом ядре).
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>page fault в хост выполняется при любом обращении к диску + Copy-on-Write при запуске программ.
Верно. Но в грамотно организованной для эффективной работы системе программы не запускаются заново даже сотни раз в секунду, не говоря уже о тысячах. И работа с файлами (хоть обычными, хоть БД) прилично буферизована, так что не требуется тысячи раз в секунду обращаться к физическому диску.
lpd>даже без виртуальных машин память ввода-вывода устройств не кешируется ни в коем случае.
На хосте — конечно, не кэшируется. Я и писал исключительно об эмуляции устройств VM в VMM.
lpd>Про обращение к хостовым устройствам в режиме pass-through точно не скажу, но, скорее всего, эти вызовы проходят через ядро хоста.
Ну да.
lpd>А эмулируемые устройства в большинстве случаев вообще обрабатываются в user-mode хоста.
Именно, о чем и речь. Поэтому мне и странно видеть утверждения о том, что любая нагруженная VM якобы обязана тысячи и десятки тысяч раз в секунду дергать ядро хоста.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, lpd, Вы писали:
lpd>>А эмулируемые устройства в большинстве случаев вообще обрабатываются в user-mode хоста.
ЕМ>Именно, о чем и речь. Поэтому мне и странно видеть утверждения о том, что любая нагруженная VM якобы обязана тысячи и десятки тысяч раз в секунду дергать ядро хоста.
Обращения к user-mode хоста все равно проходят через ядро хоста. По моим наблюениям, когда VM нагружена на 100%(компиляция), процесс виртуальной машины на хосте грузит проц процентов на 120-150. Т.е. на хосте немало операций выполняются.
А что passthrough устройств распространено на серверах я далеко не уверен.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Тогда потом придётся весь TCP и прочие реализовать в userspace. ЕМ>Зачем?
Если хочется реализовывать прямое общение с сетевой картой. Сокеты и кольцевые буферы как-то вместе не особо живут.
Здравствуйте, lpd, Вы писали:
lpd>Обращения к user-mode хоста все равно проходят через ядро хоста.
Что такое "обращения к user-mode хоста", и для чего им непременно проходить через его ядро?
lpd>По моим наблюениям, когда VM нагружена на 100%(компиляция), процесс виртуальной машины на хосте грузит проц процентов на 120-150. Т.е. на хосте немало операций выполняются.
Какой смысл смотреть на загрузку процессора? Он-то всегда будет загружен при активной работе, иначе невозможно. Смотрите частоту переключений в ядро.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> ЕМ>>каким виртуалкам в устоявшемся режиме работы потребны тысячи-десятки тысяч обращений к ядру хоста? ЕМ> S>На которых крутятся бд, например. ЕМ> Можно пример типичной (то есть, весьма распространенной) БД, которой большинство из [десятков] тысяч запросов в секунду нужно проводить именно в транзакционной форме? На мой взгляд, бОльшая часть запросов к любой БД — это таки чтение, которое хорошо буферизуется и не требует тразакционности.
OLAP vs OLTP?
Первый — больше чтений, второй — больше записей.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, lpd, Вы писали:
lpd>>Обращения к user-mode хоста все равно проходят через ядро хоста.
ЕМ>Что такое "обращения к user-mode хоста", и для чего им непременно проходить через его ядро?
По крайней мере в kvm, большинство виртуальных устройств(кроме драйверов vhost, эмулируемых ядром хоста) эмулируются user-level программой на хосте. VM сначала переключается в kernel-mode хоста, генерирует событие, которое ждет user-level эмулятор; после этого user-level эмулятор добавляется в очередь планировщика и он обработает запрос к устройству, когда в него переключится контекст.
Насколько это замедлится из-за исправления meltdown/spectre я судить не берусь.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Сокеты и кольцевые буферы как-то вместе не особо живут. ЕМ>Что именно могло бы помешать им жить вместе?
Со стороны userspace нужен или постоянный polling или те же события. А если использовать события, то один фиг разницы уже нет — ядро всё равно вовлечено.
Для звука придумали больше десяти лет назад.
