The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Второй выпуск свободного гипервизора Jailhouse, opennews (??), 11-Май-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "Второй выпуск свободного гипервизора Jailhouse"  –1 +/
Сообщение от vasa (??), 12-Май-15, 16:13 
Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначе, все равно должен пропускать черезз себя io, и т.д. а значит задержки и гарантии выполнения RTOS быть не может, может быть только максимально оптимизорованная установка, которую с тем же успехом можно сделать и на любом другом гипервизоре поддерживающем cpu pinning. Вон, Windriver вовсю продают решение на KVM, видимо классический RT уже не так сильно завязан на точность времени исполнения.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

29. "Второй выпуск свободного гипервизора Jailhouse"  +/
Сообщение от Val (??), 12-Май-15, 22:49 
> Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначе

Гипервизор должен настроить EPT/NPT, чтобы трансляция адресов выполнялась в железе. Это делается один раз при старте ячейки.

> все равно должен пропускать черезз себя io

Да, если он его эмулирует. Нет, если просто сегрегирует и пробрасывает - опять же, достаточно настроить I/O bitmap и таблицы VTD/AMD-Vi. И это опять же делается один раз.

В общем, если коротко: и Intel (в несколько большей степени), и AMD (в чуть меньшей) за последние пару-тройку лет худо-бедно продвинулись в направлении "Zero VM exits" - в смысле, выполнения гостя с минимальными (желательно, нулевыми) выходами в гипервизор.

Хотя в одном Вы правы - именно по этим причинам KVM не подходит для всех RT-задач. Кое для каких - подходит, и успешно работает. Собственно, если послушать первые презентации Jailhouse, там прямо говорится, что проект запустили после того, как не удалось решить на KVM все имеющиеся задачи.

Ответить | Правка | Наверх | Cообщить модератору

32. "Второй выпуск свободного гипервизора Jailhouse"  –1 +/
Сообщение от vasa (??), 13-Май-15, 00:12 
> Гипервизор должен настроить EPT/NPT, чтобы трансляция адресов выполнялась в железе. Это
> делается один раз при старте ячейки.

насколько я помню, все не так просто, особенно при учете NUMA, нестандартных размеров страниц и всяческих методик экономии памяти (ksm, balooning etc)

> Да, если он его эмулирует. Нет, если просто сегрегирует и пробрасывает -
> опять же, достаточно настроить I/O bitmap и таблицы VTD/AMD-Vi. И это
> опять же делается один раз.

сегрегация и проброс - все равно имеют оверхед. сейчас как раз работаю над vfio и наблюдаю все эти чудеса

> В общем, если коротко: и Intel (в несколько большей степени), и AMD
> (в чуть меньшей) за последние пару-тройку лет худо-бедно продвинулись в направлении
> "Zero VM exits" - в смысле, выполнения гостя с минимальными (желательно,
> нулевыми) выходами в гипервизор.

само собой, и именно поэтому нет смысла городить клоны KVM, с урезанным функционалом.

> Хотя в одном Вы правы - именно по этим причинам KVM не
> подходит для всех RT-задач. Кое для каких - подходит, и успешно
> работает. Собственно, если послушать первые презентации Jailhouse, там прямо говорится,
> что проект запустили после того, как не удалось решить на KVM
> все имеющиеся задачи.

объясните мне, в чем принципиальная разница jailhouse и kvm, помимо того что jailhouse сильно отстает по возможностям применения. что такого можно сделать с jailhouse, чего я не смогу сделать с KVM?

Ответить | Правка | Наверх | Cообщить модератору

43. "Второй выпуск свободного гипервизора Jailhouse"  +/
Сообщение от Val (??), 13-Май-15, 10:12 
> насколько я помню, все не так просто, особенно при учете NUMA, нестандартных размеров страниц и всяческих методик экономии памяти (ksm, balooning etc)

Правильно помните. И универсальный гипервизор (KVM, Xen или любой другой) должен это уметь. А специализированный, то есть Jailhouse, не должен - для задач, которые он призван решать, это не нужно. В итоге кодовая база и накладные расходы сокращаются - в этом одна из идей.

> сегрегация и проброс - все равно имеют оверхед. сейчас как раз работаю над vfio и наблюдаю все эти чудеса

vfio - это немножко не проброс и сегрегация, точнее, немножко не те проброс и сегрегация, о которых говорится выше. Речь шла примерно о следующем: вот две сетевушки (а в реальности, скорее - одна многопоротовая). Linux - бери порт 1, ячейка X - бери порт 2, а гипервизор последит, чтобы вы не выстрелили друг другу в ногу. Разумеется, IOMMU добавит накладных расходов, но как вы только что подтвердили, товарищи из Intel, AMD и прочих следят, чтобы они не выходили за рамки разумного. Тесты (и здравый смысл) показывают, что чисто аппаратные расходы существенно меньше, чем то, что добавляет KVM (Xen, ...), который должен уметь намного больше. Для интереса можете снять трейс с KVM, f потом запустить то же ядро в ячейке Jailhouse, и сравнить статистику выходов.

> объясните мне, в чем принципиальная разница jailhouse и kvm, помимо того что jailhouse сильно отстает по возможностям применения. что такого можно сделать с jailhouse, чего я не смогу сделать с KVM?

Объясняю (заодно отвечу на вопрос, зачем городить "клоны KVM с урезанным функционалом"). Принципиальная разница между Jailhouse и KVM, как между пушкой и единорогом: пушка сама по себе, единорог сам по себе. :-) Они не являются клонами друг друга ни архитектурно, ни на уровне кода, и не конкурируют по области применения. Более того, была идея запускать в Jailhouse-ячейках KVM для случаев, когда без него не обойтись - но за эту задачу пока никто толком не брался. Однако, в отличие от KVM, Jailhouse:

- Имеет предсказуемую latency в задачах реального времени, причем меньше ~300 мкс, до которых иногда деградирует KVM. Это удобно для индустриальных задач, телекома, NFV и т.п.
- Относительно легко формально верифицируется (что тоже хорошо для индустриальных применений). Справедливости ради, AFAIK никто не пробовал это сделать, но есть подозрение что заверифицировать ~10 тыс. изолированных строк (вопреки написанному в новости, Jailhouse использует ядро Linux только для загрузки себя, а далее полностью автономен) и связку KVM+ядро Linux (планировщик, virtio и пр.) - это немного разные задачи.

Подробнее можно почитать здесь: http://www.linux-kvm.org/images/b/b1/Kvm-forum-2013-Static-P.... Презентация старенькая, но годненькая.

Если задержек KVM вполне хватает (а есть много задач, где их хватает - даже ребята из Siemens, которые задумали Jailhouse, как-то худо-бедно дотянули до 2013 года) и формальная верификация не нужна - то и прекрасно. Мне вот в обычной жизни не нужно ни то, ни другое, так что я неплохо пользуюсь KVM для большинства (ключевое слово) своих задач.

Ну и в качестве резюме для желающих посравнивать KVM и Jailhouse. KVM - универсальный гипервизор, который (поскольку он универсальный) можно с разной степенью успешности доточить до любой задачи, включая RT-виртуализацию. Jailhouse - специализированный инструмент, созданный для того, чтобы хорошо решать одну конкретную задачу. Ни у кого, насколько мне известно, нет идей делать на его базе универсальный гипервизор.

Ответить | Правка | Наверх | Cообщить модератору

45. "Второй выпуск свободного гипервизора Jailhouse"  –1 +/
Сообщение от vasa_vasa (ok), 13-Май-15, 19:15 
> Правильно помните. И универсальный гипервизор (KVM, Xen или любой другой) должен это
> уметь. А специализированный, то есть Jailhouse, не должен - для задач,
> которые он призван решать, это не нужно. В итоге кодовая база
> и накладные расходы сокращаются - в этом одна из идей.

сокращаются - несомненно. но таблицы трансляции остаются, IO, даже при пробросе, все равно должны обработаться гипервизором, и т.д. (может я не уловил, и это не гипервизор а контейнер? тогда все станет намного логичнее, и возникнет совсем другое "зачем")

> vfio - это немножко не проброс и сегрегация, точнее, немножко не те
> проброс и сегрегация, о которых говорится выше. Речь шла примерно о
> следующем: вот две сетевушки (а в реальности, скорее - одна многопоротовая).
> Linux - бери порт 1, ячейка X - бери порт 2,
> а гипервизор последит, чтобы вы не выстрелили друг другу в ногу.
> Разумеется, IOMMU добавит накладных расходов, но как вы только что подтвердили,
> товарищи из Intel, AMD и прочих следят, чтобы они не выходили
> за рамки разумного.

само собой, и KVM (как и прочие) прекрасно это поддерживает, от IOMMU и до всяких локальных извращений типа 802.1Qbh

> Тесты (и здравый смысл) показывают, что чисто аппаратные
> расходы существенно меньше, чем то, что добавляет KVM (Xen, ...), который
> должен уметь намного больше. Для интереса можете снять трейс с KVM,
> f потом запустить то же ядро в ячейке Jailhouse, и сравнить
> статистику выходов.

хорошая идея кстати. проще конечно было бы, если бы имелся jailhouse_trace по типу kvm_trace, нагляднее. Но как я писал выше - пробросы, pinning и прочие оптимизации умеет и KVM, его не обязательно использовать в максимально универсальном режиме.

> Объясняю (заодно отвечу на вопрос, зачем городить "клоны KVM с урезанным функционалом").
> Принципиальная разница между Jailhouse и KVM, как между пушкой и единорогом:
> пушка сама по себе, единорог сам по себе. :-) Они не
> являются клонами друг друга ни архитектурно, ни на уровне кода, и
> не конкурируют по области применения. Более того, была идея запускать в
> Jailhouse-ячейках KVM для случаев, когда без него не обойтись - но
> за эту задачу пока никто толком не брался.

Тут опять возникает вопрос насчет "а не о контейнерах ли мы тут говорим?". Если так, то я свои вопросы перенаправлю в сторону LXC и всяческих надстроек нам ним

> Однако, в отличие от KVM, Jailhouse:
>  - Имеет предсказуемую latency в задачах реального времени, причем меньше ~300
> мкс, до которых иногда деградирует KVM. Это удобно для индустриальных задач,
> телекома, NFV и т.п.

за счет эксклюзивного доступа к ядру/треду плюс стабильный оверхед? если так, то как гарантируется эксклюзивность и стабильность?

>  - Относительно легко формально верифицируется (что тоже хорошо для индустриальных применений).
> Справедливости ради, AFAIK никто не пробовал это сделать, но есть подозрение
> что заверифицировать ~10 тыс. изолированных строк (вопреки написанному в новости, Jailhouse
> использует ядро Linux только для загрузки себя, а далее полностью автономен)
> и связку KVM+ядро Linux (планировщик, virtio и пр.) - это немного
> разные задачи.

т.е. jailhouse использует собственный планировщик в отличии от KVM который пользуется стандартным в ядре?

> Подробнее можно почитать здесь: http://www.linux-kvm.org/images/b/b1/Kvm-forum-2013-Static-P....
> Презентация старенькая, но годненькая.

спасибо, и впрямь полезно

> Если задержек KVM вполне хватает (а есть много задач, где их хватает
> - даже ребята из Siemens, которые задумали Jailhouse, как-то худо-бедно дотянули
> до 2013 года) и формальная верификация не нужна - то и
> прекрасно. Мне вот в обычной жизни не нужно ни то, ни
> другое, так что я неплохо пользуюсь KVM для большинства (ключевое слово)
> своих задач.

ну, как я уже писал, ребята из Windriver на жалуются

> Ну и в качестве резюме для желающих посравнивать KVM и Jailhouse. KVM
> - универсальный гипервизор, который (поскольку он универсальный) можно с разной степенью
> успешности доточить до любой задачи, включая RT-виртуализацию. Jailhouse - специализированный
> инструмент, созданный для того, чтобы хорошо решать одну конкретную задачу. Ни
> у кого, насколько мне известно, нет идей делать на его базе
> универсальный гипервизор.

мне как раз и было интересно, зачем городить специализированный гипервизор, если можно доточить KVM до того же состояния, все таки он уже 9 лет существует, оптимизирован и развивается очень быстро.

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

Ответить | Правка | Наверх | Cообщить модератору

46. "Второй выпуск свободного гипервизора Jailhouse"  +/
Сообщение от Val (??), 14-Май-15, 10:22 
> сокращаются - несомненно. но таблицы трансляции остаются,

Они и в KVM остаются, если специально не выключать - теневые таблицы страниц обходятся гораздо дороже. Только в KVM поверх них еще будут работать почти 5000 строк кода собственного программного MMU, поскольку он умеет вложенную виртуализацию и разные другие штуки. Впрочем, эту часть KVM я знаю постольку-поскольку.

> IO, даже при пробросе, все
> равно должны обработаться гипервизором, и т.д. (может я не уловил, и

Зачем? Гипервизор перехватывает обращения к PCI capabilities, т.е. участвует на моменте настройки устройства. DMA, безопасная доставка прерываний, обращение к портам происходит нативно.

> это не гипервизор а контейнер? тогда все станет намного логичнее, и
> возникнет совсем другое "зачем")

Я не знаю, что Вы имеете в виду под словом "контейнер" в данном контексте - обычно этот термин употребляется для изоляции на уровне процессов (т.е. гораздо выше, чем работает KVM и Jailhouse). Это статический гипревизор, нет resource overcommitting, нет виртуализации в чистом виде - т.е. нельзя взять одну сетевую карту и раздать пяти "гостям" как пять разных карт других моделей. Все устройства чисто физические, включая процессоры (в отличие от KVM/Xen/VirtualBox/whatever, который по сути создает под гостя vcpu).

> хорошая идея кстати. проще конечно было бы, если бы имелся jailhouse_trace по
> типу kvm_trace, нагляднее. Но как я писал выше - пробросы, pinning
> и прочие оптимизации умеет и KVM, его не обязательно использовать в
> максимально универсальном режиме.

jailhouse_trace существовать не может - за исключением загрузчика, Jailhouse не является частью ядра Linux и работает уровнем ниже него. Собственная статистика есть и доступна, инфраструктура, конечно, другая.

Говоря о Jailhouse как об альтернативе KVM для задач реального времени, разумеется, не имеют в виду "максимально универсальный" вариант. Речь об RT-ветках. Пиннинг спасает, но не до конца, потому что есть другие задачи (и еще прерывания), которые Linux может захотеть запустить на том же ядре. Гарантий (в смысле RT), которые здесь предоставляет Linux, может не хватить. Еще раз уточню - может и хватить, тогда все хорошо.

> Тут опять возникает вопрос насчет "а не о контейнерах ли мы тут
> говорим?". Если так, то я свои вопросы перенаправлю в сторону LXC
> и всяческих надстроек нам ним

Ответ выше. Если коротко повториться: в LXC запускаются процессы Linux. В Jailhouse Linux в качестве гостя запустили вообще шутки ради пару недель назад, а основная задача - запускать bare-metal приложения и ОС реального времени. Пока в LXC нельзя будет запустить, к примеру, RTEMS, сравнение будет бессмысленным. Есть ощущение, что нельзя будет всегда, поскольку LXC проектировали совсем не для этого.

Впрочем, если желаете, Jailhouse можно считать переложением идеи контейнера с уровня пользовательских процессов на уровень оборудования.

> за счет эксклюзивного доступа к ядру/треду плюс стабильный оверхед? если так, то
> как гарантируется эксклюзивность и стабильность?

Да, за счет гарантии, что "гостя" никто не потревожит. "Стабильность и эксклюзивность" гарантируется, как я уже писал, на аппаратном уровне - ядро просто "выводится" из Linux и целиком отдается ячейке (cell). С периферией та же история. В исходниках есть статья о том, как это работает, если интересны детали.

// По ходу изложения подумалось, что в контексте Jailhouse слово "cell" уместнее переводить как "клетка" или "камера". Надо будет над этим поразмышлять.

> т.е. jailhouse использует собственный планировщик в отличии от KVM который пользуется стандартным
> в ядре?

Т.е. jailhouse не использует планировщик by design. Задача планировщика - обеспечивать доступ нескольких задач к разделяемым вычислительным ресурсам (т.е. процессору). Дизайн Jailhouse - не разделять ресурсы. Если ядро процессора целиком отдано ячейке A, 99% времени на нем выполняется ячейка A. Остальное время - выходы в гипервизор по необходимости или из-за гипервызовов. И то и другое происходит по требованию, так что планировать нечего.

Это не отменяет того, что ОС, выполняющаяся в ячейке может иметь свой собственный планировщике со своими гарантиями времени отклика. Это уже не дело Jailhouse, важно лишь, что он этому планировщику мешает минимально (как минимум, меньше KVM).

> мне как раз и было интересно, зачем городить специализированный гипервизор, если можно
> доточить KVM до того же состояния, все таки он уже 9
> лет существует, оптимизирован и развивается очень быстро.

Ответ простой: потому что KVM доточить до "того же состояния" не получилось. О причинах можно почитать в презентации, на YouTube и видео доклада есть (это если уж совсем интересно).

Ответить | Правка | Наверх | Cообщить модератору

41. "Второй выпуск свободного гипервизора Jailhouse"  +/
Сообщение от Аноним (-), 13-Май-15, 09:17 
> Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначе,

Вообще-то пойнт аппаратной виртуализации - в том чтобы по максимуму выгрузить это на железо. В этом случае вполне можно увидеть >=95% производительности от bare metal по CPU и работе с памятью.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру