Какова разница между обычным и realtime ядром в контексте виртуализации?

Virtualbox с linux-rt совместим весьма плохо. Может работать прекрасно, но периодически модуль ядра виртуалбокса будет посылать ядро в ступор при загрузке. Это как минимум.

Да и еще куча граблей у rt есть.

Поэтому я использую обычное, а если надо обрабатывать звук - guitarix например, то тогда загружаюсь на rt.

А другие системы виртуализации?

Не в курсе, может с kvm и нет проблем.

Виртуализация и RT несовместимы.

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

Более того, тебе и современные Intel и AMD процессоры не дадут никакого RT, ибо говноME и говно_что_там_у_амд.

Тебе нужны старые атомы, процы до и включая Core2Duo, и аналогичное старьё от AMD. Ну или ARM/MIPS на платформах без зондов типа RPi.

Ну и используй себе на здоровье. А то что будет ио подтупливать в виртуалках, так у тебя же не продакшен сервера в них.

ТС вообще то спрашивал не о рт в виртуалках.

Поэтому никто даже и не пытался как-то обеспечить реальную работу RT ядер в гостях.

RT-XEN

Поэтому никто даже и не пытался как-то обеспечить реальную работу RT ядер в гостях

У меня _хост_ на rt-kernel, а не гости.

ТС вообще то спрашивал не о рт в виртуалках.

А о чём? Под RT ядром пускать например VirtualBox? Если RTAI - то плевать. Если это какое-нибудь дебиановское *-rt ядро - то можно огрести.

RT-XEN

Оно всего лишь RT-шедулит VM'ы. В какой-то степени это даст результат но только на очень длительных временных интервалах. Для обыного применения там, где используется RT непригодно.

Если RTAI - то плевать. Если это какое-нибудь дебиановское *-rt ядро - то можно огрести.

А чем rt-kernel в Debian отличается от RTAI?

У меня _хост_ на rt-kernel, а не гости.

Значит не так понял. Если RTAI - то пофиг. Если это обычно PREEMPT_RT ядро, то возможно огребёшь. Пробуй. Запусти какой-нибудь latency-test, напряги чем-нибудь твою виртуалку, да погляди.

У тебя процессор-то какой? Может это всё вовсе бессмысленно.

Intel i3 5005U

А нет способа отличить RTAI от PREEMPT_RT ядра?

А чем IntelME мешает RT?

А чем rt-kernel в Debian отличается от RTAI?

http://rtai.org

https://rt.wiki.kernel.org

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

/proc/config.gz посмотреть. Найдёшь там CONFIG_PREEMPT_RT если PREEMPT_RT или CONFIG_IPIPE если RTAI.

А чем IntelME мешает RT?

Останавливает работу процессора/процессоров на непредсказуемое и неконтролируемое время множа на нуль всю RT. Без отключения ME смысла в RT нет никакого.

Он это может, но он же не постоянно это делает?

Intel i3 5005U

Забей. Если Intel ME не отключен, RT тебе не нужен, достаточно CONFIG_RT_GROUP_SCHED в ядре и настрой для нужных задач. Ну или поставь PREEMPT_RT ядро и пользуй как обычное.

latency-plot запусти, например, из linuxcnc и всё увидишь. Скорее всего будет что-то типа этого: http://wiki.linuxcnc.org/uploads/mvprc-smi-latency.png

Есть всякие пляски с бубном, типа отключения SMI и пр, но на последних мамках и процах и они не работают.

Он это может, но он же не постоянно это делает?

ME делает дофига хрени, в том числе, например, и следит за температурой проца, чтобы вырубить при критическом перегреве. Есть даже специальное немаскируемое прерывание - System Management Interrupt, которое уже очень давно компостирует мозг всем, кто как-то с RT возится. Так что да, Intel ME делает это постоянно.

Увы:

vsevolod@hp15debian9:/boot$ cat config-4.9.0-4-rt-amd64 | grep PREEMPT
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT_COUNT=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TRACER is not set
vsevolod@hp15debian9:/boot$ cat config-4.9.0-4-rt-amd64 | grep IPIPE
vsevolod@hp15debian9:/boot$

Да мне RT и впрямь не нужен, просто на этом ядре (и на серии 3.x) snd_hda_intel не глючит. Спасибо за информацию.

Ну и не парься тогда - запусти свой VirtualBox, да посмотри что будет. Быстрей проверить, чем на лоре спрашивать.

Уже запускал — работает. Но из твоих слов я понял, что возможны плавающие баги, а я в нем хочу вирт. сервер и вирт. клиент для тренировок поднять, и мне важно знать, что это я ошибся, а не VirtualBox.

Так запусти в VirtualBox'е чего-ниубдь очень тяжёлое и сразу понятно станет - будут проблемы или нет.

Насколько тяжелое? Форк-бомба на bash в виртуалке сойдет?

Насколько тяжелое? Форк-бомба на bash в виртуалке сойдет?

Не очень. Оно скорее память сожрёт, чем проц нагрузит. Ядро компильни с -j 10 например.

То есть нужно нагрузить именно проц, без RAM или диска... А нет таких тестов? Просто я ещё не компилил ядра.

Эталонный Useless Use of Cat.

Не понял, что не так? Как ещё смотреть настройки ядра?

А зачем ME останавливает работу процессора? У него же свой процессор/процессоры.

Блин, забыл что grep это умеет.

Скажем так для софт-рт вполне пригодно, как и линуксовые рт ядра. Для хард-рт есть спецжелезо и спецоси.

У меня холодильник с ОСРВ, вот нихрена не пойму нафига это в холодильнике то :)

Для хард-рт есть спецжелезо и спецоси.

Linux + RTAI на пригодном железе вполне себе хард-рт, насколько он вообще возможен для ОС общего назначения на железе общего назначения. Лучше пока ничего нету.

А так, конечно да, какой-нибудь ATTiny8 или PIC12F508 пусть даже с минимальной ОС легко уделает по latency любой современный писюк.

говноME - это что? Intel Management Engine?

говноME - это что? Intel Management Engine?

Ага.

А зачем ME останавливает работу процессора? У него же свой процессор/процессоры.

А я откуда знаю чего он там делает? Может ему в памяти покопаться надо или ещё что.

Факт есть факт - на тех мамках где ME ещё можно было выключить совсем (мамки с ME для Core2Duo например) при включённом ME есть периодические задержки до сотен микросекунд, а то и до миллисекунд, при выключенном всё как по маслу, без малейших пиков при любой нагрузке jitter не превышаeт нескольких микросекунд.

На современных мамках эти периодические задержки ещё больше, что делает RT совершенно бессмысленным без полного изничтожения ME.

а как QNX работает в виртуалке? они ведь для разработчиков поставляли образы vmware.

а как QNX работает в виртуалке?

А она что, в виртуалке обеспечивает нужную latency? Хрен-то там. Работает и работает, как любая другая ОС в виртуалке - когда хост позволит. Для разработки и отладки достаточно, а протестировать продукт реально можно и на выделенном железе.

А как оно связано с реалтаймом?

Читай выше по треду.

А вы случайно не путаете IntelME с SMM (System Management Mode)?

SMM будет работать дальше даже при вычищенном IntelME.

А вы случайно не путаете IntelME с SMM (System Management Mode)?

Нет, SMM вместе с сраным SMI тоже говно ещё то, но на сотни миллисекунд систему не завешивает и, в общем-то, SMI несложно гарантированно отключить на любом железе.

А вот IntelME даёт на порядки большие лаги и отключить его на произвольно взятой железке пока что нереально.

Код SMM ведь грузится из BIOS в CPU Ring N -2?

Т.е. если BIOS заменить на Libreboot или Coreboot, то SMM работать не будет?

А как можно отключить SMM на материнках с BIOS?

Вроде бы отключение SMM обычно как-то связано с использованием ACPI?