16 марта 2016 в 16:35

Персистентная оперативная память

Сегодня — рассказ про одну из ключевых концепций ОС Фантом. Впрочем, сама концепция, конечно, существовала и до Фантома — фактически, у Танненбаума в конце книги, там, где он позволяет себе фантазировать, просматриваются очертания почти всех особенностей Фантома, так что, в целом, подход довольно очевиден для тех, кто хотя бы задумывается о будущем систем вообще.

Персистентная оперативка — очень простая и очень непростая вещь.

В целом, всё просто: представьте себе, что содержимое оперативной памяти не пропадает. Никогда. Например, при выключении компьютера. Или, например, при… исчезновении компьютера. «И души умерших программ носятся над водою».

Ну, действительно — неважно: если мы смогли спасти состояние компьютера перед его отключением, то можно восстановить это состояние в другом. Таком же. Вообще таком же? Прямо до микросхемы? А если в нём видеокарта другая — уже нельзя?

Можно, потому что мы говорим не о том, чтобы заперсистить, сохранить всё состояние компьютера, а только его оперативную память. Но тогда в этом нет пользы, скажет внимательный читатель — уже хотя бы регистры надо бы сохранить? Иначе восстановление только памяти не позволит программе работать как если бы ничего не происходило.

А задача — именно такова. Обеспечить программе среду, в которой остановка ОС и остановка компьютера для программы выглядели исключительно как нажатие на кнопку «пауза» при просмотре фильма. Во время паузы «под программой» можно даже компьютер поменять, но надо как-то обеспечить ситуацию, в которой продолжение работы для программы будет совершенно прозрачным.

Это недостижимо, если требование доводить до абсолюта. Состояние хардвера сохранить и полностью восстановить нельзя. Но и не надо. Программе не нужна видеокарта, ей нужен тот же API и сохранённая картинка на экране, а это — можно.

Что вырисовывается: сохранить состояние только оперативки — мало, а всего компьютера — нереально.

Инженерная смекалка говорит нам, что нужно специфицировать для программы некоторую среду, которой во-первых, достаточно для самой программы, а во-вторых, в рамках такой среды должно быть возможно выполнить сохранение консистентного состояния программы и всего, что она «видит».

Легко видеть, что такой средой является спецификация операционной системы. Ну — не любой. Хорошей операционной системы. Системы, которая достаточно качественно скрывает от приложения детали аппаратуры (и вообще бренности окружающего мира).

Следовательно, вообще-то, говорит надо не о персистентной (виртуальной) памяти, а о персистентной среде исполнения = персистентной ОС. Собственно, это и есть проект ОС Фантом, но сегодня я принципиально ограничусь, всё же, вопросом только оперативки, иначе статью не получится дописать к утру.

Итак, мы понимаем, что персистентная память окружена другими персистентными сервисами, и пока откладываем их в сторону.

Ясна так же и цель войны. Ясна? Нет?

Цель — упростить жизнь программиста до неприличия. Избавить его от работы по сериализации стейта программы. И от ограничений, которые он на себя накладывает, проектируя внутреннее представление данных в программе, держа в уме, что всё это рано или поздно придётся втискивать в прокрустово ложе потока байт, которым является файл.

Ну — вот простой пример: habrahabr.ru/company/2gis/blog/198564

Вместо того, чтобы воевать с ФС, можно просто забыть про неё как про страшный сон. Очевидно, что это вызывает массу вопросов про обмен данными, но, вообще-то, признаемся себе, что обмен тоже давно уже происходит не через файлы, а через REST/SOAP/whatever, и тоже не в формате сериализации дерева в байт-стрим, а в виде запросов объектов или «ветвей» дерева объектов. Что, очевидно, соответствует вовсе не «файловой» семантике, а тому представлению данных, которое сподручно для самой программы.

Хорошо, цель ясна. Теперь средство. Как же записать память на диск?

Ну, write( fd, (void *)0, get_mem_size() ), верно?

Конечно, нет. По многим причинам. И потому, что в памяти могут быть «дырки» — не отображённые никуда области, доступ к которым запрещён. И потому, что совсем незачем записывать то, что не менялось. Да тот же код — зачем? Да и, главное, потому, что это дико дорого.

И уж совсем важно, что программу во время записи придётся остановить. А вот это уже никуда не гоже вообще.

Дело тут вот в чём. Если мы хотим (а мы хотим), чтобы прикладная программа нам доверяла и правда не пыталась для спокойствия всё-таки записаться в файл (а это убивает всю идею вообще), надо ей гарантировать, нет ГАРАНТИРОВАТЬ, что мы её обязательно сохраним. Может быть, не совсем в последнем состоянии (это не так важно — она повторит часть вычислений), но в целостном и не позавчерашнем.

То есть — состояние программы (чуть позже мы выясним, что это состояние всех программ вообще) нельзя сохранять по старинке — перед выключением компьютера или по ctrl-s, это надо делать постоянно. Или, как минимум, достаточно регулярно. И нередко.

Вряд ли пользователь, а тем более — управляемый компьютером технологический процесс будет доволен сообщением «сохраняю оперативную память» на минутку-другую.

Надо научиться сохранять состояние в фоновом режиме, потихоньку, прямо «под» работающей программой.

Но тогда оно будет неконсистентным! Мы сохранили левую половину состояния программы, а когда начали сохранять правую, программа уже наработала что-то новенькое — половины «не срастутся» при рестарте. Программа добавит в левую половину объект, поставит на него ссылку из правой половины, а в «фотографии» состояния окажется, что ссылка есть, а объекта — нет.

Сохранённое состояние должно быть строго, абсолютно, консистентным. Но делать его надо последовательно.

Можно?

Можно.

Есть множество эвристик, которые позволяют удешевить и облегчить такой процесс, но в основе лежит обычный COW, copy on write.

Если утрировать до предела, то фотографирование состояния сводится к мгновенному переключению всей памяти в read only — это единственная (и крайне недорогая) операция, которую нужно сделать атомарно. (Заранее оговоримся, что перед ней нужно загнать программы в состояние, которое полностью представлено в памяти. А не в регистрах процессора. Что тоже несложно и недорого).

Это, собственно, «точка фотографирования».

Дальше процесс обретает известную медитативность и может быть выполнен без вырывания волос из естественных впадин организма, спокойно и с расстановкой. Страницы памяти можно спокойно записывать на диск одна за одной. А что ж программа? Она, конечно, не будет ждать и попробует в какую-то страницу памяти таки записать что-то. Такая страница разделяется на пару — старая, неизменная копия встаёт в очередь на запись на диск (поближе к началу), а новая используется и модифицируется программой. Когда запись на диск закончится, старые копии будут уничтожены.

Как я уже говорил, это только черновик. Есть масса деталей. (Желающие взорвать мозг могут заглянуть в код прямо сейчас.)

Очевидная оптимизация — записывать только diff-ы. С прошлого раза поменялось очень не всё.

Столь же очевидная, но более спорная и требующая эвристик оптимизация — что-то записать до точки фотографирования (и переключить в r/o), в надежде, что оно не изменится. Тогда можно будет просто использовать готовый записанный блок на диске, не повторяя дисковой операции для этой страницы памяти.

Понятно так же, что рабочее множество программы (точнее, его не read only часть) потенциально удвоится за время записи снапшота: если нам не повезёт, то пока мы будем записывать состояние, программа «перетрогает», перезапишет все свои странички и всем им придётся выделить вторую физическую страницу оперативной памяти. То есть при невезении затраты оперативки удвоятся во время снапшота. Реально ситуация всегда мягче, но «спрос» на оперативку во время снапшота неизбежно возрастает. Чтобы его удовлетворить, не останавливая программы по причине нехватки оперативки, хорошо бы перед снапшотом немного подготовиться, позаписывать на диск странички, которые изменились — тогда у них можно будет «отобрать» физическую страницу памяти, если она срочно потребуется в другом месте. Опять же, внимательный читатель увидит, что выше уже сказано про позаписывать на диск превентивно, но в других целях.

Превентивная запись улучшает и другой показатель. Латентность снапшота — время между «фотографированием» и окончанием записи фотографии на диск.

Отмечу, что всё это на сегодня вполне реализовано и работает в ядре ОС.

В этом месте поставим точку с запятой. Через некоторое время я постараюсь написать статью, которая связывает предыдущую тему — примитивы синхронизации — и эту. То есть написать о проблемах реализации примитивов синхронизации в персистентной памяти.

И это уже будет статья о том, что до сих пор как следует не сделано. То есть, в существенной степени она будет состоять из вопросов.
Дмитрий Завалишин @dzavalishin
карма
79,0
рейтинг 80,7
Архитектор
Самое читаемое Разработка

Комментарии (68)

  • +1
    Надо тебя к нам на JUG/CodeFreeze снова притащить или на одну из конференций :)
    • +2
      Летом? :)
      • +2
        да хоть в марте-апреле! Очень круто, что ты снова взялся за Фантом.
        • +1
          Интересно, что несколько проблем, которые казались просто неприступными, вдруг неожиданно разрешились. У меня из чужого кода были TCP/IP и USB stack, и в обоих колом стояли затыки, которые даже погружением в дебаггер на пару дней не были решены. А тут вдруг я их оба закрыл каждый за вечер. Взгляд "размылился", что ли...
          • 0
            наверное. Отдохнул, переключился.
  • 0
    А можно в общих чертах прокомментировать, как эта концепция дружит с энергонезависимой оперативной памятью? А то тут на днях рассказывали, что RRAM пойдёт на коммерциализацию и вообще обещают подвижки в этой области.
    • +4
      Конечно. Появление RRAM позволит снизить латентность снапшота (не уверен, что до нуля, но сильно). Но общая машинерия никуда не денется пока объём RAM меньше объёма диска. А вот потом… это совсем интересно. :)

      Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.

      Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.
      • 0
        Так ведь, насколько я понимаю, самое вкусное в перспективах такой памяти как раз в том, что исчезает разделение на оперативное и постоянное хранение, исчезает само понятие "диск" и производные, вроде "загрузки". Вот когда понадобятся во всю силу ОС, построенные на этих принципах.
        • 0
          Конечно.
          • +2
            Так вот и хотелось бы увидеть комментарии от вас, как от работающего в этом направлении человека, что будет в таких условиях. Каково это — когда сразу все программы и данные всегда "загружены" в память, когда нет и не нужно никакого "сохранения"? Как изменятся принципы написания программ, взаимодействия, хранения данных? Что станет с пользовательским интерфейсом? Какие ещё интересные изменения привнесёт это нововведение?
            • +1
              Предмет отдельной серии статей. Где бы достать ещё часов 10-12 в сутки. :)
              Наверное, со временем напишу.
  • 0
    Поддержку NVDIMM уже добавили в UEFI 2.5, доступные реализации которого на подходе вместе со следующим поколением десктопных процессоров Intel с микроархитектурой Kaby Lake. По поводу железа — инженерные образцы уже циркулируют, но до открытой продажи еще примерно с год. Что со стороны ОС — пока не знаю, железо подходящее его не попадало в руки.
  • 0
    Насколько я помню поддержку подобной функциональности (суспенд отдельных процессов на диск и последующее оживление) анонсировали для Linux. Не знаю, довели до продакшена или нет.
    • 0
      CRIU?
      • 0
        Ага, точно, оно. Даже развивается активно, не ожидал. И на ванильном ядре работает.
        • +1
          Это же люди из Parallels делают. Недавно общался с ними, то ли на OS Day, то ли на семинаре Петренко в МГУ, не помню. Отличная работа, очень полезная в прикладном смысла. Но там тоже нельзя сделать снапшот без остановки процесса.
    • 0
      Вот крутое демо, сервер Quake в контейнере переносят между датацентрами с сохранением состояния и сетевого подключения. https://www.youtube.com/watch?v=MHJmNZSRve0&feature=youtu.be&t=1328
      • 0
        Ну, это не совсем то же самое. Это скорее аналог vMotion и подобных ей технологий, которые уже достаточно много лет присутствуют в виртуализации.
        • 0
          На видео состояние сохраняется и восстанавливается как раз через CRIU. Они используют runc checkpoint, который в свою очередь работает через CRIU.
      • 0
        Это супер старая возможность. Ещё в Multics была реализована.
  • 0
    У меня такое ощущение, что OS/400, к примеру, так и работает используя стандартную "оперативку" в качестве кэша.
  • 0
    https://geektimes.ru/post/251686/

    Кроме того, одной из фишек ОС была способность откатывать, при сбое и ре-старте, ОС и задачи с последнего сохраненного места.

    Примерно как сейчас делает это ноутбук – закрыл – открыл крышку – все задачи бегут, как будто не останавливались. Для этого в С добавилась возможность для каждой задачи сохранять промежуточные данные, с которых она могла ре-стартовать.
    • 0
      :) Интересно, спасибо.
      Но делать это на уровне задачи можно только в режиме старт-стоп — прозрачное сохранение без останова кода так сделать нельзя.
    • 0
      Но, стоит отметить, перезагружать время от времени всё равно приходится. Хотя бы из-за утечек памяти.
  • 0
    dzavalishin Как часто в вашей ОС приходится менять HDD?
    • +1
      а вы вообще уверены, что Фантом увеличивает нагрузку на HDD/SDD и сокращает срок его службы?
      • 0
        Нет, Алексей. Я в этом не уверен, поэтому и спрашиваю.
        Но в любом случае, следуя логике, операции записи на HDD/SSD должно стать больше. Отсюда и моё предположение.
    • +1
      Не знаю пока. Хорошо бы выйти на какое-то серийное применение, чтобы начать собирать такую статистику. Этот вопрос реально сложнее, чем может показаться. Например, объём ввода-вывода зависит от реализации аллокатора памяти. Тупой аллокатор при выделении памяти идёт "по кругу" и "трогает" всю память даже если программе в каждый момент времени хватает килобайта. Соответственно, система снапшотов будет считать её изменившейся и записывать, хотя ничего актуального там нет. Есть два выхода: дорабатывать аллокатор с тем, чтобы он работал более локально, и/или дорабатывать систему снапшотов, чтобы она не пыталась записывать память, которая была выделена и освобождена полностью между снапшотами. Эти доработки могут снизить нагрузку на диск на несколько порядков.
      • 0
        А если не секрет, как система снепшотов определяет изменения и как часто она дампится на диск?
        • 0
          Какой уж секрет — я ссылку на исходники дал. :)
          Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.

          Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.
          • 0
            Понятно. Исходники конечно хорошо, но там кода мама не горюй)
            А почему не сделает «реактивное» изменение? Боитесь упереться в пропускную способность жесткого носителя?

            Если стоит пауза в 100, то есть очень большой шанс получить не консистентность данных на выходе.
  • +1
    А не было бы на порядки проще и эффективнее реализовать подобную концепцию не в виде ОС, а в виде user-space runtime environment в существующей ОС, например, под Линуксом на основе memory mapped файлов? Ну может ещё какой модуль ядра забахать.
    • 0
      х его з. может и да.

      есть и третий вариант — сесть под микроядро L4
      но не факт, что было бы проще. сам код ядра не так уж и велик.

      изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.

      Другое дело, что не было бы проблем с драйверами и пр.
      • 0
        Ну я именно за вариант с реализацией в user space. И именно по причине того, что будет готовая абстракция от железа с огромным пластом драйверов. Отставание по количеству и качеству драйверов, написанных за десятки лет для Линукса в своей ОС нагнать нереально. Да и не нужно это, ведь цель не в этом, а в создании ортогонально персистентной среды. У вас же получается, что вместо полной концентрации на реализции этой концепции приходится распыляться на свою реализацию TCP/IP, USB и прочего бесконечно огромного и глубокого болота, с заведомо провальным результатом (извините, но взять любой из необходимых компонентов — тот же TCP/IP — чтобы его реализовать качественно, по всем спецификациям, производительно, без уязвимостей, так чтобы этой реализации доверяли и без опасений реально использовали в боевых проектах, необходимо огромное количество ресурсов на тестирование и разработку).
        • 0
          Есть простой ответ на этот вопрос — садиться на гипервизор. Но — да, частичный. Реализацию стека TCP он не заменяет.

          Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.

          Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.

          Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.

          В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.

          (Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
  • +1
    Это очень напоминает live migration виртуальных машин. :-) А кстати судя по описанию в Фантоме же по сути виртуальная машина и есть, с каким-нибудь JIT. Тогда, если там Generational GC, напрашивается совмещение персистера и вычисления диффов с собственно фазами GC, даже по названиям похоже.
    • +1
      О. Вы всё верно сказали. Идите к нам GC писать. :)
  • +3
    В идеальном мире это и заработает, может быть. Когда напишут идеальные программы без утечек памяти.
    А в реальном мире я вынужден два-три раза в день прибивать процесс Firefox, так как он начинает глючить и тормозить, отказывается загружать js и css, когда потребление памяти подбирается к 3 ГБ.
    • 0
      Вы знаете, прогресс в IT постоянно лишает программистов какой-либо былОй халявы. Как было написано в какой-то книжке (Хакерз, чтоли?) — до "не пользуйся при программировании goto" было "не пользуйся при программировании паяльником". Когда-то надо научаться и с ресурсами работать. Перестать на Си писать, наконец. Ну ведь как-то удаётся делать Явские энтерпрайз-системы, которые работают месяцами под дикой нагрузкой и не текут. GC помогает, ну и определённое качество проектирования.
      • 0
        Опять таки, всё это очень здорово для серверов и каких-либо промышленных реализаций, где софт пишут на века. Но на обычном домашнем ПК, где софт частенько написан неким, кто вчера закончил универ и возомнил себя мега программистом, проблема с утечкой памяти приобретает нешуточный размах.
        • 0
          Да, в общем, тоже не обязательно. Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему? Потому что сборка мусора и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса. Что бы там внутри ни утекло — запрос заканчивается вместе со всеми вложенными данными.
          • 0
            Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему?

            Потому что CGI. У php до сих пор скрипт как закончился, так умер. Скорость увеличивается за счет кеширования результатов интерпретации.
            • 0
              "и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса."
          • 0
            При этом тот же Firefox течёт довольно не слабо. Я люблю, когда открыто много вкладок, точнее они то открываются, то закрываются. В общем, при такой кутерме к концу дня до 1,5 ГиБ набегает. Это я к тому, что всех разом и резко не научишь писать без утечек, из чего вытекает логичный вывод: нужно это учитывать.
            Кстати, ещё такой вопрос: при сбрасывании памяти на диск, он всю сбрасывает или только обновившиеся участки? И, если только обновившиеся, то как происходит эта проверка?
            • 0
              А кто вам сказал что это утекшая память? Скорее всего firefox просто кеширует загруженные картинки и другие ресурсы, на случай если вы снова откроете закрытую вкладку. Данные можно будет достать из кеша и сразу вам показать. 1.5Гб адресного пространства — это ничего в масштабах например 16Гб системной памяти. И зная FF — скорее всего в about:config есть флажки, которые помогут избежать такого жадного кеширования.
              Так что если говорим о утечках — то лучше брать код, и конкретно показывать, мол утечка вот здесь и вот здесь. А страшные циферки в диспетчере задач ниразу не показатель.
              • 0
                Вообще утечка памяти (адресного пространства) несущественна. Это утечка дискового пространства, которого вообще не жалко. Существенна утечка (разрастание) рабочего множества. В Фантоме, конечно. Хотя, по идее, в обычных ОС должно быть почти так же.
                • 0
                  Рассуждения на эту тему наводит на мысль что можно ввести soft & hard limits для «локальных» данных программы. Это не решает вопрос с у течками, но позволяет убить программу как только она породило много данных. На серверах (в продакшене) такое скорей всего нуно будет отключть, но на десктопе и в разработке очень может пригодится (возможно). Но вопрос все таки в инструментарии, а не в самой проблемы (или концепции програмирования/дизайна).

                  и FF отожравший 1.5Gb нуно убить только потому что памяти не 1Tb -)
  • 0
    Дмитрий, интересно было бы узнать об общем состоянии работ над ФантомОС: Как ведётся разработка, кто занимается проектом, кроме вас? Нужна ли помощь проекту (я имаю ввиду разработческая). Что сподвигло к продолжению работ над ОС? Появились инвесторы?)
    • +1
      Инвесторов не появилось, это по-прежнему некоммерческий опенсорсный проект.
      Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.

      У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)

      Помощь разработческая нужна. Очень. Присоединяйтесь.
  • +1
    DZ, удалось ли решить проблему "всемирного GC"? И если да — то как?
    • +1
      Концепция есть давно, реализация пока не актуальна.
  • 0
    Боюсь показаться профаном, но хотел бы задать вопрос. Какие нагрузки сможет выдерживать данный механизм? Имеется ввиду случаи многопоточной обработки данных с постоянной записью в оперативку. Интересная статья и мысли. Сложно представить как диск угонится за ОЗУ, а даже если накапливать diff, то в случае постоянной записи в ОЗУ и медленной записи на диск, буффер diff'ов просто переполнится, это неизбежно. Да и аварийное выключение приведет к потере накопленного буфера diff'ов.
    • 0
      Размер diff-а не может быть больше физического объёма оперативной памяти. Ничего страшного.
    • 0
      Немного более развёрнуто. Рабочее множество всех процессов (суммарный объём активно используемой оперативной памяти) или меньше ОЗУ — тогда дифф тоже меньше ОЗУ, или больше ОЗУ — тогда в традиционной ОС возникает пейджинг. В Фантоме он тоже возникает, но он является частью предварительного процесса формирования снапшота. То есть если страница памяти изменилась но была вытеснена на диск — её не надо записывать ещё раз, её просто включают в состав снапшота автоматически.

      То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
      • 0
        Вот да, для тяжелой математики нужно уметь отключать персистентность, или давать возможность иметь и не-персистентную память.
        Например, декодирование видео на процессоре. Нет смысла писать на диск каждый декодированный кадр.
        • 0
          Каждый декодированный кадр и так ни при каких условиях не будет писаться на диск. Они, как правило, декодируются каждый раз в один и тот же буфер. Иметь неперсистентную память несложно, но тогда программе придётся помнить об этом и обрабатывать пропадание содержимого неперсистентной памяти. Вот если бы потребовать для каждого такого куска иметь строго функциональный генератор, который ОС сама могла бы вызвать для восстановления участка. Небанально.
          • 0
            Похожий вопрос, допустим, у меня матрица на несколько гигабайт и я её диагонализую (методом Якоби), много пишу, записи случайно распределены по адресному пространству.
            Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
            Как быть?
            • 0
              Всё верно, это — худший сценарий.

              Никак.

              Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
            • 0
              Вообще такие вопросы — одна из причин, по которым я начал реализацию Фантома — к ним надо подойти и их порешать. Это могут быть разные варианты. Очевидный — уметь делать неперсистентные "анклавы". Что вообще легко и, практически, готово. Интереснее другое — уметь выделять в графе объектов замкнутые подмножества, для которых определять иные политики "фотографирования", но это — крайне небанально. Например, есть такой вариант подхода: уметь делать несколько параллельных виртуальных машин, которые видны друг другу условно прозрачно (как бы по сети), но имеющие обособленные адресные пространства и, соответственно, политики снапшотинга могут быть сильно разные. Это тоже интересный подход, но сильно тяжелее.
      • 0
        Т.е. пока снапшот не скинут на диск, продолжаете обновлять его, как только с некоторой периодичностью включается сброс снапшота на диск, вы его лочите, с этого момента создаете новый снапшот, который получает новые diff'ы, старый снапшот существует пока не записан на диск, как только записан — трете его. Так?
        • 0
          В целом — да. Собственно, "обновлять его" — это просто работать в памяти. В остальном — всё точно так.
  • 0
    Может я чего-то не понимаю, но LXC и KVM поддерживают live migration уже давно. А коммерческие решения умеют и постоянно сохранять состояние, обеспечивая HA. И для этого вовсе не обязательно отказываться от концепции "файла".
    • 0
      Ну, вы уж не браните меня так строго за то, что эти мысли пришли в голову не только мне и применяются в других системах. Так ведь бывает, я ж не могу запретить людям думать.

      Но если Вам угодно видеть разницу, то она — принципиальна. Фантом гарантирует прикладным программам персистентную среду, что позволяет отказаться от файлов (или не отказываться) и за счёт этого удешевить разработку ПО и сделать его более гибким. А костыли этого не гарантируют.

      А задача-то именно в этом — дать программисту среду, с одной стороны, достаточно привычную, с другой — позволяющую во многом упростить жизнь.

      Вот CRIU — это действительно куда ближе. Опять же, они ставят другие цели, но в мои цели отчасти попадают тоже. Случайно. :)
      • 0
        Очень перекликается с идеологией Smalltalk, где прогамма тоже живет в памяти постоянно в процессе ее разработки и не перезапускается. На Хабре были видео, где человек показывает, как это происходит — довольно интересно.
  • 0
    Hewlett Packard Enterprise разрабатывает новую архитектуру под кодовым названием The Machine, главная идея которой — общая для узлов персистентная память. Возможно ли реализовать персистентную среду без необходимости сбрасывания снапшотов на диск? Ведь если память персистентная, диск больше не нужен.
    • 0
      Конечно. Правда, я бы всё равно сбрасывал для надёжности, но можно это делать реже.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Да играться-то особо не с чем, не готова она ещё для прикладного применения. :(

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.