Вообще такие вопросы — одна из причин, по которым я начал реализацию Фантома — к ним надо подойти и их порешать. Это могут быть разные варианты. Очевидный — уметь делать неперсистентные "анклавы". Что вообще легко и, практически, готово. Интереснее другое — уметь выделять в графе объектов замкнутые подмножества, для которых определять иные политики "фотографирования", но это — крайне небанально. Например, есть такой вариант подхода: уметь делать несколько параллельных виртуальных машин, которые видны друг другу условно прозрачно (как бы по сети), но имеющие обособленные адресные пространства и, соответственно, политики снапшотинга могут быть сильно разные. Это тоже интересный подход, но сильно тяжелее.
Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
Да, в общем, тоже не обязательно. Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему? Потому что сборка мусора и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса. Что бы там внутри ни утекло — запрос заканчивается вместе со всеми вложенными данными.
Какой уж секрет — я ссылку на исходники дал. :)
Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.
Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.
Очевидно. Но, по сути, (как и в процессоре) операции записи нас волнуют примерно никак (степень их отложенности — только вопрос надёжности), а операции чтения мы можем хинтовать — достаточно из параллельной нити трогать данные, которые нам вскорости понадобятся, и пейджинг их подгонит. В этом смысле ничего не меняется по сравнению с "ручной" работой с диском, нет?
Каждый декодированный кадр и так ни при каких условиях не будет писаться на диск. Они, как правило, декодируются каждый раз в один и тот же буфер. Иметь неперсистентную память несложно, но тогда программе придётся помнить об этом и обрабатывать пропадание содержимого неперсистентной памяти. Вот если бы потребовать для каждого такого куска иметь строго функциональный генератор, который ОС сама могла бы вызвать для восстановления участка. Небанально.
Есть простой ответ на этот вопрос — садиться на гипервизор. Но — да, частичный. Реализацию стека TCP он не заменяет.
Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.
Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.
Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.
В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.
(Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
Это же люди из Parallels делают. Недавно общался с ними, то ли на OS Day, то ли на семинаре Петренко в МГУ, не помню. Отличная работа, очень полезная в прикладном смысла. Но там тоже нельзя сделать снапшот без остановки процесса.
Немного более развёрнуто. Рабочее множество всех процессов (суммарный объём активно используемой оперативной памяти) или меньше ОЗУ — тогда дифф тоже меньше ОЗУ, или больше ОЗУ — тогда в традиционной ОС возникает пейджинг. В Фантоме он тоже возникает, но он является частью предварительного процесса формирования снапшота. То есть если страница памяти изменилась но была вытеснена на диск — её не надо записывать ещё раз, её просто включают в состав снапшота автоматически.
То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
Инвесторов не появилось, это по-прежнему некоммерческий опенсорсный проект.
Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.
У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)
Помощь разработческая нужна. Очень. Присоединяйтесь.
Вы знаете, прогресс в IT постоянно лишает программистов какой-либо былОй халявы. Как было написано в какой-то книжке (Хакерз, чтоли?) — до "не пользуйся при программировании goto" было "не пользуйся при программировании паяльником". Когда-то надо научаться и с ресурсами работать. Перестать на Си писать, наконец. Ну ведь как-то удаётся делать Явские энтерпрайз-системы, которые работают месяцами под дикой нагрузкой и не текут. GC помогает, ну и определённое качество проектирования.
есть и третий вариант — сесть под микроядро L4
но не факт, что было бы проще. сам код ядра не так уж и велик.
изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.
Другое дело, что не было бы проблем с драйверами и пр.
Не знаю пока. Хорошо бы выйти на какое-то серийное применение, чтобы начать собирать такую статистику. Этот вопрос реально сложнее, чем может показаться. Например, объём ввода-вывода зависит от реализации аллокатора памяти. Тупой аллокатор при выделении памяти идёт "по кругу" и "трогает" всю память даже если программе в каждый момент времени хватает килобайта. Соответственно, система снапшотов будет считать её изменившейся и записывать, хотя ничего актуального там нет. Есть два выхода: дорабатывать аллокатор с тем, чтобы он работал более локально, и/или дорабатывать систему снапшотов, чтобы она не пыталась записывать память, которая была выделена и освобождена полностью между снапшотами. Эти доработки могут снизить нагрузку на диск на несколько порядков.
Никак.
Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.
Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.
Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.
Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.
Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.
В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.
(Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.
У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)
Помощь разработческая нужна. Очень. Присоединяйтесь.
есть и третий вариант — сесть под микроядро L4
но не факт, что было бы проще. сам код ядра не так уж и велик.
изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.
Другое дело, что не было бы проблем с драйверами и пр.
Но делать это на уровне задачи можно только в режиме старт-стоп — прозрачное сохранение без останова кода так сделать нельзя.
Наверное, со временем напишу.