Комментарии 68
Надо тебя к нам на JUG/CodeFreeze снова притащить или на одну из конференций :)
Летом? :)
да хоть в марте-апреле! Очень круто, что ты снова взялся за Фантом.
Интересно, что несколько проблем, которые казались просто неприступными, вдруг неожиданно разрешились. У меня из чужого кода были TCP/IP и USB stack, и в обоих колом стояли затыки, которые даже погружением в дебаггер на пару дней не были решены. А тут вдруг я их оба закрыл каждый за вечер. Взгляд "размылился", что ли...
А можно в общих чертах прокомментировать, как эта концепция дружит с энергонезависимой оперативной памятью? А то тут на днях рассказывали, что RRAM пойдёт на коммерциализацию и вообще обещают подвижки в этой области.
Конечно. Появление RRAM позволит снизить латентность снапшота (не уверен, что до нуля, но сильно). Но общая машинерия никуда не денется пока объём RAM меньше объёма диска. А вот потом… это совсем интересно. :)
Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.
Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.
Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.
Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.
Так ведь, насколько я понимаю, самое вкусное в перспективах такой памяти как раз в том, что исчезает разделение на оперативное и постоянное хранение, исчезает само понятие "диск" и производные, вроде "загрузки". Вот когда понадобятся во всю силу ОС, построенные на этих принципах.
Конечно.
Так вот и хотелось бы увидеть комментарии от вас, как от работающего в этом направлении человека, что будет в таких условиях. Каково это — когда сразу все программы и данные всегда "загружены" в память, когда нет и не нужно никакого "сохранения"? Как изменятся принципы написания программ, взаимодействия, хранения данных? Что станет с пользовательским интерфейсом? Какие ещё интересные изменения привнесёт это нововведение?
Поддержку NVDIMM уже добавили в UEFI 2.5, доступные реализации которого на подходе вместе со следующим поколением десктопных процессоров Intel с микроархитектурой Kaby Lake. По поводу железа — инженерные образцы уже циркулируют, но до открытой продажи еще примерно с год. Что со стороны ОС — пока не знаю, железо подходящее его не попадало в руки.
Насколько я помню поддержку подобной функциональности (суспенд отдельных процессов на диск и последующее оживление) анонсировали для Linux. Не знаю, довели до продакшена или нет.
CRIU?
Вот крутое демо, сервер Quake в контейнере переносят между датацентрами с сохранением состояния и сетевого подключения. https://www.youtube.com/watch?v=MHJmNZSRve0&feature=youtu.be&t=1328
У меня такое ощущение, что OS/400, к примеру, так и работает используя стандартную "оперативку" в качестве кэша.
https://geektimes.ru/post/251686/
Кроме того, одной из фишек ОС была способность откатывать, при сбое и ре-старте, ОС и задачи с последнего сохраненного места.
Примерно как сейчас делает это ноутбук – закрыл – открыл крышку – все задачи бегут, как будто не останавливались. Для этого в С добавилась возможность для каждой задачи сохранять промежуточные данные, с которых она могла ре-стартовать.
Кроме того, одной из фишек ОС была способность откатывать, при сбое и ре-старте, ОС и задачи с последнего сохраненного места.
Примерно как сейчас делает это ноутбук – закрыл – открыл крышку – все задачи бегут, как будто не останавливались. Для этого в С добавилась возможность для каждой задачи сохранять промежуточные данные, с которых она могла ре-стартовать.
dzavalishin Как часто в вашей ОС приходится менять HDD?
а вы вообще уверены, что Фантом увеличивает нагрузку на HDD/SDD и сокращает срок его службы?
Не знаю пока. Хорошо бы выйти на какое-то серийное применение, чтобы начать собирать такую статистику. Этот вопрос реально сложнее, чем может показаться. Например, объём ввода-вывода зависит от реализации аллокатора памяти. Тупой аллокатор при выделении памяти идёт "по кругу" и "трогает" всю память даже если программе в каждый момент времени хватает килобайта. Соответственно, система снапшотов будет считать её изменившейся и записывать, хотя ничего актуального там нет. Есть два выхода: дорабатывать аллокатор с тем, чтобы он работал более локально, и/или дорабатывать систему снапшотов, чтобы она не пыталась записывать память, которая была выделена и освобождена полностью между снапшотами. Эти доработки могут снизить нагрузку на диск на несколько порядков.
А если не секрет, как система снепшотов определяет изменения и как часто она дампится на диск?
Какой уж секрет — я ссылку на исходники дал. :)
Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.
Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.
Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.
Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.
А не было бы на порядки проще и эффективнее реализовать подобную концепцию не в виде ОС, а в виде user-space runtime environment в существующей ОС, например, под Линуксом на основе memory mapped файлов? Ну может ещё какой модуль ядра забахать.
х его з. может и да.
есть и третий вариант — сесть под микроядро L4
но не факт, что было бы проще. сам код ядра не так уж и велик.
изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.
Другое дело, что не было бы проблем с драйверами и пр.
есть и третий вариант — сесть под микроядро L4
но не факт, что было бы проще. сам код ядра не так уж и велик.
изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.
Другое дело, что не было бы проблем с драйверами и пр.
Ну я именно за вариант с реализацией в user space. И именно по причине того, что будет готовая абстракция от железа с огромным пластом драйверов. Отставание по количеству и качеству драйверов, написанных за десятки лет для Линукса в своей ОС нагнать нереально. Да и не нужно это, ведь цель не в этом, а в создании ортогонально персистентной среды. У вас же получается, что вместо полной концентрации на реализции этой концепции приходится распыляться на свою реализацию TCP/IP, USB и прочего бесконечно огромного и глубокого болота, с заведомо провальным результатом (извините, но взять любой из необходимых компонентов — тот же TCP/IP — чтобы его реализовать качественно, по всем спецификациям, производительно, без уязвимостей, так чтобы этой реализации доверяли и без опасений реально использовали в боевых проектах, необходимо огромное количество ресурсов на тестирование и разработку).
Есть простой ответ на этот вопрос — садиться на гипервизор. Но — да, частичный. Реализацию стека TCP он не заменяет.
Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.
Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.
Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.
В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.
(Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.
Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.
Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.
В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.
(Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
Это очень напоминает live migration виртуальных машин. :-) А кстати судя по описанию в Фантоме же по сути виртуальная машина и есть, с каким-нибудь JIT. Тогда, если там Generational GC, напрашивается совмещение персистера и вычисления диффов с собственно фазами GC, даже по названиям похоже.
В идеальном мире это и заработает, может быть. Когда напишут идеальные программы без утечек памяти.
А в реальном мире я вынужден два-три раза в день прибивать процесс Firefox, так как он начинает глючить и тормозить, отказывается загружать js и css, когда потребление памяти подбирается к 3 ГБ.
А в реальном мире я вынужден два-три раза в день прибивать процесс Firefox, так как он начинает глючить и тормозить, отказывается загружать js и css, когда потребление памяти подбирается к 3 ГБ.
Вы знаете, прогресс в IT постоянно лишает программистов какой-либо былОй халявы. Как было написано в какой-то книжке (Хакерз, чтоли?) — до "не пользуйся при программировании goto" было "не пользуйся при программировании паяльником". Когда-то надо научаться и с ресурсами работать. Перестать на Си писать, наконец. Ну ведь как-то удаётся делать Явские энтерпрайз-системы, которые работают месяцами под дикой нагрузкой и не текут. GC помогает, ну и определённое качество проектирования.
Опять таки, всё это очень здорово для серверов и каких-либо промышленных реализаций, где софт пишут на века. Но на обычном домашнем ПК, где софт частенько написан неким, кто вчера закончил универ и возомнил себя мега программистом, проблема с утечкой памяти приобретает нешуточный размах.
Да, в общем, тоже не обязательно. Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему? Потому что сборка мусора и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса. Что бы там внутри ни утекло — запрос заканчивается вместе со всеми вложенными данными.
Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему?
Потому что CGI. У php до сих пор скрипт как закончился, так умер. Скорость увеличивается за счет кеширования результатов интерпретации.
При этом тот же Firefox течёт довольно не слабо. Я люблю, когда открыто много вкладок, точнее они то открываются, то закрываются. В общем, при такой кутерме к концу дня до 1,5 ГиБ набегает. Это я к тому, что всех разом и резко не научишь писать без утечек, из чего вытекает логичный вывод: нужно это учитывать.
Кстати, ещё такой вопрос: при сбрасывании памяти на диск, он всю сбрасывает или только обновившиеся участки? И, если только обновившиеся, то как происходит эта проверка?
Кстати, ещё такой вопрос: при сбрасывании памяти на диск, он всю сбрасывает или только обновившиеся участки? И, если только обновившиеся, то как происходит эта проверка?
А кто вам сказал что это утекшая память? Скорее всего firefox просто кеширует загруженные картинки и другие ресурсы, на случай если вы снова откроете закрытую вкладку. Данные можно будет достать из кеша и сразу вам показать. 1.5Гб адресного пространства — это ничего в масштабах например 16Гб системной памяти. И зная FF — скорее всего в about:config есть флажки, которые помогут избежать такого жадного кеширования.
Так что если говорим о утечках — то лучше брать код, и конкретно показывать, мол утечка вот здесь и вот здесь. А страшные циферки в диспетчере задач ниразу не показатель.
Так что если говорим о утечках — то лучше брать код, и конкретно показывать, мол утечка вот здесь и вот здесь. А страшные циферки в диспетчере задач ниразу не показатель.
Вообще утечка памяти (адресного пространства) несущественна. Это утечка дискового пространства, которого вообще не жалко. Существенна утечка (разрастание) рабочего множества. В Фантоме, конечно. Хотя, по идее, в обычных ОС должно быть почти так же.
Рассуждения на эту тему наводит на мысль что можно ввести soft & hard limits для «локальных» данных программы. Это не решает вопрос с у течками, но позволяет убить программу как только она породило много данных. На серверах (в продакшене) такое скорей всего нуно будет отключть, но на десктопе и в разработке очень может пригодится (возможно). Но вопрос все таки в инструментарии, а не в самой проблемы (или концепции програмирования/дизайна).
и FF отожравший 1.5Gb нуно убить только потому что памяти не 1Tb -)
и FF отожравший 1.5Gb нуно убить только потому что памяти не 1Tb -)
Дмитрий, интересно было бы узнать об общем состоянии работ над ФантомОС: Как ведётся разработка, кто занимается проектом, кроме вас? Нужна ли помощь проекту (я имаю ввиду разработческая). Что сподвигло к продолжению работ над ОС? Появились инвесторы?)
Инвесторов не появилось, это по-прежнему некоммерческий опенсорсный проект.
Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.
У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)
Помощь разработческая нужна. Очень. Присоединяйтесь.
Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.
У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)
Помощь разработческая нужна. Очень. Присоединяйтесь.
DZ, удалось ли решить проблему "всемирного GC"? И если да — то как?
Боюсь показаться профаном, но хотел бы задать вопрос. Какие нагрузки сможет выдерживать данный механизм? Имеется ввиду случаи многопоточной обработки данных с постоянной записью в оперативку. Интересная статья и мысли. Сложно представить как диск угонится за ОЗУ, а даже если накапливать diff, то в случае постоянной записи в ОЗУ и медленной записи на диск, буффер diff'ов просто переполнится, это неизбежно. Да и аварийное выключение приведет к потере накопленного буфера diff'ов.
Размер diff-а не может быть больше физического объёма оперативной памяти. Ничего страшного.
Немного более развёрнуто. Рабочее множество всех процессов (суммарный объём активно используемой оперативной памяти) или меньше ОЗУ — тогда дифф тоже меньше ОЗУ, или больше ОЗУ — тогда в традиционной ОС возникает пейджинг. В Фантоме он тоже возникает, но он является частью предварительного процесса формирования снапшота. То есть если страница памяти изменилась но была вытеснена на диск — её не надо записывать ещё раз, её просто включают в состав снапшота автоматически.
То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
Вот да, для тяжелой математики нужно уметь отключать персистентность, или давать возможность иметь и не-персистентную память.
Например, декодирование видео на процессоре. Нет смысла писать на диск каждый декодированный кадр.
Например, декодирование видео на процессоре. Нет смысла писать на диск каждый декодированный кадр.
Каждый декодированный кадр и так ни при каких условиях не будет писаться на диск. Они, как правило, декодируются каждый раз в один и тот же буфер. Иметь неперсистентную память несложно, но тогда программе придётся помнить об этом и обрабатывать пропадание содержимого неперсистентной памяти. Вот если бы потребовать для каждого такого куска иметь строго функциональный генератор, который ОС сама могла бы вызвать для восстановления участка. Небанально.
Похожий вопрос, допустим, у меня матрица на несколько гигабайт и я её диагонализую (методом Якоби), много пишу, записи случайно распределены по адресному пространству.
Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
Как быть?
Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
Как быть?
Всё верно, это — худший сценарий.
Никак.
Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
Никак.
Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
Вообще такие вопросы — одна из причин, по которым я начал реализацию Фантома — к ним надо подойти и их порешать. Это могут быть разные варианты. Очевидный — уметь делать неперсистентные "анклавы". Что вообще легко и, практически, готово. Интереснее другое — уметь выделять в графе объектов замкнутые подмножества, для которых определять иные политики "фотографирования", но это — крайне небанально. Например, есть такой вариант подхода: уметь делать несколько параллельных виртуальных машин, которые видны друг другу условно прозрачно (как бы по сети), но имеющие обособленные адресные пространства и, соответственно, политики снапшотинга могут быть сильно разные. Это тоже интересный подход, но сильно тяжелее.
Т.е. пока снапшот не скинут на диск, продолжаете обновлять его, как только с некоторой периодичностью включается сброс снапшота на диск, вы его лочите, с этого момента создаете новый снапшот, который получает новые diff'ы, старый снапшот существует пока не записан на диск, как только записан — трете его. Так?
Может я чего-то не понимаю, но LXC и KVM поддерживают live migration уже давно. А коммерческие решения умеют и постоянно сохранять состояние, обеспечивая HA. И для этого вовсе не обязательно отказываться от концепции "файла".
Ну, вы уж не браните меня так строго за то, что эти мысли пришли в голову не только мне и применяются в других системах. Так ведь бывает, я ж не могу запретить людям думать.
Но если Вам угодно видеть разницу, то она — принципиальна. Фантом гарантирует прикладным программам персистентную среду, что позволяет отказаться от файлов (или не отказываться) и за счёт этого удешевить разработку ПО и сделать его более гибким. А костыли этого не гарантируют.
А задача-то именно в этом — дать программисту среду, с одной стороны, достаточно привычную, с другой — позволяющую во многом упростить жизнь.
Вот CRIU — это действительно куда ближе. Опять же, они ставят другие цели, но в мои цели отчасти попадают тоже. Случайно. :)
Но если Вам угодно видеть разницу, то она — принципиальна. Фантом гарантирует прикладным программам персистентную среду, что позволяет отказаться от файлов (или не отказываться) и за счёт этого удешевить разработку ПО и сделать его более гибким. А костыли этого не гарантируют.
А задача-то именно в этом — дать программисту среду, с одной стороны, достаточно привычную, с другой — позволяющую во многом упростить жизнь.
Вот CRIU — это действительно куда ближе. Опять же, они ставят другие цели, но в мои цели отчасти попадают тоже. Случайно. :)
Hewlett Packard Enterprise разрабатывает новую архитектуру под кодовым названием The Machine, главная идея которой — общая для узлов персистентная память. Возможно ли реализовать персистентную среду без необходимости сбрасывания снапшотов на диск? Ведь если память персистентная, диск больше не нужен.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Персистентная оперативная память