В преддверии очередного релиза CRIU

[pfactum]

А задумывался ли кто-либо о применении CRIU на десктопе? Вместо того, чтобы закрывать приложение полностью, сохраняем его состояние, а потом открываем сразу вместе со всеми ранее открытыми документами. Эдакая мини-гибернация, избирательно для отдельно взятого приложения.

[avagin]

Да, мы думаем об этом, но сейчас все ресурсы брошены на «серверные» нужды. Если у вас есть желание, вы можете поресерчить, как дампить иксовые приложения.
На затравку у нас есть небольшое видео, где дампится видеоплеер youtu.be/j4wlYY7lTDw. Правда тут он был запущен в vncserver-е. Таким же образом мы проверяли, что CRIU может дампить Open Office, Gimp. Вот тут есть небольшая инструкция, как это все делать criu.org/VNC

[konoplin]

Подскажите, а как обрабатываются ситуации с многопоточными приложениями? Чаще всего приложение считывает системную информацию при старте и дальше использует её в работе. Соответственно, при «переезде» приложения с ноды с бОльшим количеством CPU/ядер на ноду с меньшим количеством CPU/ядер, приложение завершится с ошибкой? Или же есть какие-то решения в этой области?

[avagin]

Можете сформулировать проблему более конкретно. Количество потоков приложения может быть больше, чем количество ядер на машине, это достаточно обычное дело. Если посмотреть глубже, то сейчас количество ядер на машине, может меняться во время работы. На пример следующая команда выключает один из «процессоров».
echo 0 > /sys/devices/system/cpu/cpu1/online
Бывают ситуации, когда приложения привязываются к конкретным процессорам из соображения оптимизации. Таких приложения не много и если их отвязать от процессора, то они продолжат работать.

[konoplin]

Бывают ситуации, когда приложения привязываются к конкретным процессорам из соображения оптимизации.

Да, я именно это и имел в виду. Т.е. происходит ли смена маски (CPU affinity mask) в случае, если она не удовлетворяет условиям на новой ноде?

[avagin]

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

[avagin]

Прав в чем? В том, что мы сумасшедшие? Так все мы тут не без греха. Какой нормальный человек будет отвечать вам в третьем часу ночи. А вот в том, что это когда-то заработает, я думаю, уже никто не сомневается, оно уже работает!

Что касается Plesk-а, поверьте мне, команда разработчиков CRIU не написала в нем ни одной строчки кода и он абсолютно чист от наших сумасшедших идей;). Я бы не судил о компании по одному продукту. Да и тот же плеск в последнее время идет на поправку.

[serjs]

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

[avagin]

Не врете. Принял и продолжает принимать. К слову большую часть интерфейсов удается сделать универсальными, т е не специфичными для CRIU и их не оборачивают в макрос про который говорил Линус.
Вот тут можно ознакомиться с изменениями в ядре от CRIU команды: criu.org/Commits