URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 92828
[ Назад ]

Исходное сообщение
"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."

Отправлено opennews , 25-Ноя-13 21:47 
Представлен (https://lkml.org/lkml/2013/11/25/479) первый значительный релиз проекта CRIU 1.0 (http://criu.org/), развивающего для Linux набор средств для манипуляции snapshot-ами приложений в пространстве пользователя. Разработанный в рамках проекта инструментарий позволяет организовать создание контрольных точек, с  заморозкой состояния запущенных приложений, и последующего восстановления работы с сохранённой позиции. Выпуск CRIU 1.0 ознаменовал собой включение в состав ядра Linux всех необходимых для полноценной работы патчей и перевод проекта из разряда экспериментальных прототипов в полнофункциональный продукт.


Система позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе  после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Из популярных приложений, для которых протестирована корректная заморозка, можно выделить MySQL, Apache httpd, MongoDB, nginx, GCC, make, tar, bz2, ssh/sshd, screen + bash + top, частично реализована поддержка sendmail, git и java. При использовании VNC-сервера tigervnc протестирована заморозка GUI-приложений LibreOffice, IceWM, GIMP, Inkscape, Blender, Mplayer, Eclipse, SuperTux. Поддерживается работа как на системах с архитектурой x86 и ARM.


Из областей применения технологии CRIU отмечается обеспечение перезагрузки ОС без нарушения непрерывности выполнения длительно выполняемых процессов, Live-миграция изолированных контейнеров, ускорение запуска медленных процессов (можно начать работу с состояния, сохранённого после инициализации), проведение обновлений ядра без перезапуска сервисов, периодическое сохранение состояния долговыполняемых вычислительных задач для возобновления работы в случае краха, балансировка нагрузки на узлы в кластерах, дублирование процессов на другую машину (fork на удалённую систему), создание снапшотов пользовательских приложений в процессе работы для их анализа на другой системе или на случай если потребуется отменить дальнейшие действия в программе. Возможно создание на базе CRIU решений для миграции активных десктоп-сеансов с одной машины на другую или переноса консольных процессов в окружение утилиты screen.


Поддерживается заморозка как отдельных процессов, так и  изолированных групп процессов (контейнеров), созданных с использованием инструментариев LXC и OpenVZ . CRIU поддерживает любые состояния процессов и возможность работы на немодифицированной ОС, содержащей стандартное ядро Linux и системные библиотеки. Создаваемые ранее аналогичные проекты обладали ограниченной поддержкой состояний процессов, требовали модификации ядра или системных библиотек. CRIU базируется на технологиях, уже присутствующих в современных ядрах Linux, и позволяющих обеспечить заморозку групп процессов и сессий, состояния маппинга памяти, нитей, открытых файлов, блокировок, дескрипторов FANotify, именованных и неименованных каналов, сокетов, TCP-соединений (позволяет обеспечить миграцию процесса без разрыва соединения), IPC и т.п.  Для координации работы между системами разработан специальный эффективный RPC-протокол (http://criu.org/RPC), позволяющий обращаться к удалённым сервисам на базе CRIU.


URL: https://lkml.org/lkml/2013/11/25/479
Новость: http://www.opennet.me/opennews/art.shtml?num=38519


Содержание

Сообщения в этом обсуждении
"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Dcow , 25-Ноя-13 21:47 
А кто может подсказать, как происходить переброс TСP соединения?

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 25-Ноя-13 21:57 
Надо полагать, вместе с сетевым стеком контейнера, включая IP-адрес.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 25-Ноя-13 21:59 
http://www.opennet.me/opennews/art.shtml?num=34387  Релиз ядра Linux 3.5
Поддержка интерфейса для восстановления TCP-соединений, позволяющего зафиксировать контрольную точку с которой можно возобновить остановленное соединение. Наиболее интересным практическим применением указанной функции является возможность предотвратить разрыв соединений в результате перезагрузки системы или перемещения серверного процесса на другой хост. Например, в системах виртуализации упрощается решение таких задач как миграция работающих процессов с одного сервера на другой, незаметно для приложения на другой стороне соединения;

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 15:40 
IP тот же остается или можно поменять на другой?

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 17:24 
> IP тот же остается или можно поменять на другой?

По всей видимости, тот же. Он привязан к виртуальному стеку контейнера (netns) и передается вместе с ним.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 25-Ноя-13 22:12 
>  А кто может подсказать, как происходить переброс TСP соединения?

Ну вот так:
- Траффик заворачивается на другую железяку.
- Ядру хинтят состояние TCP стека.

Ничему такому особо не противоречит если состояние сетевого стека восстановить.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 15:00 
> Ну вот так:
> - Траффик заворачивается на другую железяку.
> - Ядру хинтят состояние TCP стека.

Узнаю нашего старого доброго user294 - ни слова по делу, зато рунглиш из всех щелей :)


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 22:00 
кого-то таки достал полурабочий cryopid? похвально. и вообще, давно хочу такую штуку, чтобы полноценно работала.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 25-Ноя-13 22:01 
Надо ещё на systemd-logind протестировать его.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 22:06 
> Надо ещё на systemd-logind протестировать его.

зачем? поцтеринг вам напишет свою реализацию. кривую, косую, хреново документированую и интегрированую в системды по самое дальше некуда.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 25-Ноя-13 23:23 
Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 23:39 
> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.

а-а-а. тогда да, одобряю.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 14:55 
> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.

Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого проблемы сваливаешь на Поттеринга.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 15:07 
> Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого
> проблемы сваливаешь на Поттеринга.

Еще можно нажать Alt+SysRq+B и потом придти скандалить в LKML "ваш линyпс убил все мои данные".
Вот только Линус не Леннарт, может и наxер послать.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено 1 , 26-Ноя-13 08:15 
кривые только руки твои, сачок )
коль не осилил, так на себя пенять надо

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено 1 , 26-Ноя-13 08:17 
вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:25 
> вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас

Вообще-то 294-й достаточно нормально относится к идее чего-то типа systemd. По крайней мере upstart мне пришелся вполне по вкусу и мне с ним как-то сильно проще получается добавлять новые кастомные демоны в систему. Ну и systemd освою, если из него выбьют дурь и так получится что ему суждено стать новым иниицализатором в большинстве пингвинов. А пока пусть на кошках^W федористах и арчеводах тренируются и обезглючивают.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:43 
> По крайней мере upstart мне пришелся вполне по вкусу

Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги при малейшей ошибке в синтаксисе.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 27-Ноя-13 20:52 
> Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги
> при малейшей ошибке в синтаксисе.

Ну я как бы не возражаю что оно должно бы чертыхнуться куда-нибудь в лог. Багу своему гарри поттеру вы написали уже? Или как обычно? И если уж мы про ошибки - вот уж знаете ли, в классическом ините ловить ошибки форменный головняк. Там вообще никакого логинга нет, так что что и почему обломалось - как хочешь так и узнавай. Сам логгинг допишешь, фигли.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 14:56 
> кривые только руки твои, сачок )
> коль не осилил, так на себя пенять надо

Такие, как он, всегда видят корень своих проблем в окружающих. И просто неспособны осознать факт кривизны своих рук. Что ариса, что поттеринг, одна фигня.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 15:02 
> Надо ещё на systemd-logind протестировать его.

Скорее наоборот, это в systemd будут тестировать фичи CRIU.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Vee Nee , 25-Ноя-13 22:10 
Даже на офсайте сходу не удалось понять, с какой версии ядра все необходимое в состав ядра включено?

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 25-Ноя-13 22:29 
3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 22:32 
> 3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

это необязательная фича, вообще-то.

p.s. насколько я понял из текста на офсайте, на практике не проверял.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 22:31 
> Даже на офсайте сходу не удалось понять, с какой версии ядра все
> необходимое в состав ядра включено?

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


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 25-Ноя-13 23:17 
тьфу, распронаедрит налево! пересобирал ядро, перезагружался — а эта бесполезная фигня только для x86_64.

ненужно.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 00:20 
> x86 ненужно

профиксил


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 00:36 
> профиксил

херово и неверно.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 14:58 
>> профиксил
> херово и неверно.

Все правильно он починил. Ни замшелое гoвно, ни его адепты в этом мире никому не нужны.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 20:24 
а обосновать сможешь?

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 00:57 
> а обосновать сможешь?

тысячу тысяч раз уже говорено.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 21:31 
все правильно. Устаревшие архитектуры ненужны.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 00:57 
> все правильно. Устаревшие архитектуры ненужны.

я согласен, x86 и x86_64 обе — устарели и нафиг не нужны.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено kurokaze , 26-Ноя-13 01:45 
>только для x86_64

Отлично, я еще 8 лет назад перешел исключительно на 64 бита


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 05:07 
> Отлично, я еще 8 лет назад перешел исключительно на 64 бита

мне очень важно было это узнать, спасибо.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено ABATAPA , 26-Ноя-13 12:21 
Так же, как нам - что Вам "не нужно".

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено гость , 27-Ноя-13 18:41 
Любка, ты чтоль?

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 15:10 
> мне очень важно было это узнать, спасибо.

А нам очень интересно было прочитать про ваши половые трудности с 64-битными системами.
Продолжайте держать нас в курсе.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 15:05 
> Отлично, я еще 8 лет назад перешел исключительно на 64 бита

Да уже несколько лет как большая часть x86 железа ушла на свалки. Так что на 32 битах нынче сидят разве что виндyзятники и фимозники в терминальной стадии.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:29 
> Да уже несколько лет как большая часть x86 железа ушла на свалки.

Ну так 64-битные процессоры появились чуть ли не десятилетие назад. А при современных ценах нагревать себя на оперативку - просто глупо. Даже если программам столько нафиг не упало, большой дисковый буфер сделает работу с машиной не в пример приятнее. Когда все оглавление всех дисков висит в оперативе и никогда не выжимается, а все рабочие наборы целиком прокешированы - работать с машиной становится заметно приятнее. Просто потому что практически все операции происходят как выстрел из пушки.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:00 
о, виндузятник пришёл. это у вас в винде 32-битная икспишечка не может в больше четырёх гигов памяти. 32–битный линукс вполне может.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Проходимец , 27-Ноя-13 08:50 
ХР SP1 может адресовать до 16GB из 32 возможных в 36-битном адресном пространстве.
Только не спрашивайте, куда дел 36-й бит и еще 32GB.

Патч весьма простой, помогает и следующим сервиспакам


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 09:15 
ссылку на то, где m$ его раздаёт?

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 27-Ноя-13 21:09 
> о, виндyзятник пришёл.

Аж 294 раза. По что ругаешься, Кэп? (форум считает данное слово бранным, что конечно правильно, но усложняет ответ).

> это у вас в винде 32-битная икспишечка не может
> в больше четырёх гигов памяти. 32–битный линукс вполне может.

Все несколько проще. Раскуривать сорцычтобы самому найти ответ мне было дико обломно: мне и так есть чем заняться и экскурсия в управление кэшом на такую глубину без причины меня не соблазнила. А конфигов с 32-битным процом где более 4Гб памяти у меня элементарно нет, т.к. я не сторонник извращений типа PAE и прочая и полагаю что если в системе есть более 4 гигз памяти то и 64 бита на указатель можно выкроить как-нибудь и не развалиться при этом. Система которая не может напрямую адресовать свою память без извращений - дрянь. Спасибо, всякие схемы банкинга и прочие костыли мне уже давно сидят в печенках. Да, я люблю линейные адресные пространства, где можно просто получить то что хотелось а не заниматься фигурным костылестроением. Надо же, какой я негодяй :).


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:19 
> По что ругаешься, Кэп?

я не ругался, я обзывался. как будто я тебя не узнал.

> форум считает данное слово бранным

«почто»?


про всё остальное. была же задумка x32 (или как там её) — издохла, что ли? это как раз здравая идея же: профиты в виде расширеного регистрового пространства и отсутствие дебилизма с указателями.

а ещё ваша 48-битовая фигня еле-еле поместилась в double nan. с ужасом жду, когда очередной модный-молодёжный скажет, что 48 бит для указателя мало, придумает очередную дикую схему адресации и указатели перестанут в double nan влазить.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Led , 28-Ноя-13 05:08 
> про всё остальное. была же задумка x32 (или как там её) —
> издохла, что ли? это как раз здравая идея же: профиты в
> виде расширеного регистрового пространства и отсутствие дебилизма с указателями.

Нет, не "издохла". Вот только она касается только юзерспейса - ядро там всё равно используется стандартное x86_64, а у тебя на него аллергия:)


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 05:30 
> Нет, не «издохла». Вот только она касается только юзерспейса - ядро там
> всё равно используется стандартное x86_64, а у тебя на него аллергия:)

у меня на него аллергия, когда оно без толку суётся. в x32 я толк вижу — в отличие от 64-битного ядра с 32-битным остальным или полной 64-битности.

p.s. сайт у них ужасен, у меня глаза болят и щека дёргается.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 28-Ноя-13 07:17 
> про всё остальное. была же задумка x32 (или как там её) —
> издохла, что ли? это как раз здравая идея же: профиты в
> виде расширеного регистрового пространства и отсутствие дебилизма с указателями.

Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 07:52 
> Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти.

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


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Kibab , 26-Ноя-13 01:52 
А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной версии которого не существует? :-)

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 05:09 
> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной
> версии которого не существует? :-)

а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? а, и ещё чтобы multilib держать, а то одной копии дистрибутива мне мало?


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Led , 26-Ноя-13 06:02 
>> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной
>> версии которого не существует? :-)
> а зачем мне 64-битная система, если у меня нет софта, которому требуется
> больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были?
> а, и ещё чтобы multilib держать, а то одной копии дистрибутива
> мне мало?

А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 06:10 
> А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?

не знаю, у меня ядро 32-битное, так что проверить не могу.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:30 
> не знаю, у меня ядро 32-битное, так что проверить не могу.

А у тебя и пямяти меньше 4 гигз? Или мсье нравятся феерические костыли типа PAE? И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:45 
> И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?

«Дисковый кэш — кривая хрень, которой пользуются только законченные идиoты» ©arisu


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:02 
>> не знаю, у меня ядро 32-битное, так что проверить не могу.
> А у тебя и пямяти меньше 4 гигз?

а какое отношение?

> Или мсье нравятся феерические костыли типа PAE?

а мне без разницы, я это руками не делаю.

> И кстати может ли 32-битное ядро скажем дисковый
> кэш скажем в 8Гб сделать?

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


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 27-Ноя-13 21:17 
> а мне без разницы, я это руками не делаю.

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

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

Ну а я не против запустить пару виртуалок и загрузить все оглавление дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM drive все-таки.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:22 
>> а мне без разницы, я это руками не делаю.
> Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким
> костылем.

тогда тебе исключительно в real mode. потому что в protected ты вообще адресуешь некую виртуальную сущность.

> Ну а я не против запустить пару виртуалок и загрузить все оглавление
> дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM
> drive все-таки.

да на здоровье — я тебе запрещаю, что ли? как я уже говорил — x32 было бы хорошим вариантом. но увы — модные-молодёжные не привыкли экономить ресурсы.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 28-Ноя-13 07:20 
> тогда тебе исключительно в real mode. потому что в protected ты вообще
> адресуешь некую виртуальную сущность.

Дело не в этом. Дело в костылях в виде сегментов или оконной загрузки страниц. На данный момент это именно костыль, поскольку основное API ОС расчитывает на линейную адресацию.

В long mode, тьфу-тьфу, "виртуальную сущность" упростили именно до линейной адресации, без сегментации. Вполне себе хватает и того, что страницы можно подключать в произвольном порядке. Это, кстати, на производительности тоже сказывается.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 07:54 
> Дело не в этом. Дело в костылях в виде сегментов или оконной
> загрузки страниц.

вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? нет, не видишь.

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


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 28-Ноя-13 20:11 
> вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь?
> нет, не видишь.

Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86-32. Правда, я этого в рабочем режиме не сделаю никогда, потому что из ума еще не выжил :)


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 29-Ноя-13 02:58 
> Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86–32.

это, без сомнения, рутинная домашняя задача. все так делают, каждый день.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 29-Ноя-13 07:25 
> это, без сомнения, рутинная домашняя задача. все так делают, каждый день.

Задача-то не домашняя, но вот работает она каждый день... И вполне себе рутинная, кстати :)


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 29-Ноя-13 10:24 
я (десктоп) писал (десктоп) о (десктоп) несколько (десктоп) других (десктоп) областях (десктоп).

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 26-Ноя-13 07:40 
>>> а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт

x64 - это не только снятие лимита в 3 гигабайта. Это еще набор из 8 дополнительных доступных софту РОН и регистров SSE, увеличенная ширина регистров по умолчанию и несколько прочих плюшек, типа возможности работать с оффсетами относительно RIP.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 08:26 
ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при создании кода — мне пофигу. вот что мне точно не надо — два установленых дистрибутива.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Led , 26-Ноя-13 08:55 
> ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при
> создании кода — мне пофигу. вот что мне точно не надо
> — два установленых дистрибутива.

Достаточно добавить 64-битное ядро


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 09:03 
> Достаточно добавить 64-битное ядро

для чего? 32-битный софт остаётся 32-битным.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Led , 26-Ноя-13 10:46 
>> Достаточно добавить 64-битное ядро
> для чего? 32-битный софт остаётся 32-битным.

Например, для CRIU. Да и "32-битного софта" можно запустить больше.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 11:38 
> Например, для CRIU.

например, само ядро больше памяти слопает.

> Да и «32-битного софта» можно запустить больше.

с чего бы вдруг? 32-битное ядро ни разу не ограничено четырьмя гб памяти. а если в системе закончились пиды — то тут не ядро менять надо, а прокладку.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:36 
> например, само ядро больше памяти слопает.

На машинах где 64 бита имеют смысл это как правило не принципиально. Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь уж существенно. И вообще, пристрелив какую-нить дрянь на питоне или чем там еще - можно сразу в 20 раз больше памяти отыграть, если уж так хочется.

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

А еще в 64-битном режиме 64-разрядная математика работает быстрее. А поскольку например лимит в 4 гига при работе с файлами нас не устроит - 64-битная математика нынче в каждом закоулке. И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. А на х86 у которого регистров полторы штуки это выливается в кошмар. А в 64-битном режиме есть нормальный набор регистров и прочая и это даже уже похоже на нормальный процессор немного, а не кусок шита из ранних 80-х.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:41 
> И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку.

Как будто это что-то плохое.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 19:47 
> Как будто это что-то плохое.

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


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:08 
использовать 64-битные указатели для адресации пары гигов памяти — вот это и есть дурь несусветная.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 27-Ноя-13 21:19 
> использовать 64-битные указатели для адресации пары гигов памяти — вот это и
> есть дурь несусветная.

Да. Но я не вижу почему мне должно быть нельзя юзать всю доступную память из 1 процесса, опять же. Какое-то очередное "640К хватит всем". В то что 2^64 хватит на ближайшее время - я еще готов поверить даже.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:23 
> Да. Но я не вижу почему мне должно быть нельзя юзать всю
> доступную память из 1 процесса, опять же.

потому что ядро тебе не разрешит. даже 64-битное.

> всем». В то что 2^64 хватит на ближайшее время — я
> еще готов поверить даже.

2^48. остальные биты вашего огромного указателя тупо ничего не делают и копируются из 47-го.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:07 
> На машинах где 64 бита имеют смысл это как правило не принципиально.
> Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь
> уж существенно.

зато кэш процессора — существенно. указателей в ядре много, все указатели в два раза больше.

> И вообще, пристрелив какую-нить дрянь на питоне

чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное.

> Еще ядро на машинах с большой памятью больше на служебные нужды забирает.

почти два гигабайта ему вполне достаточно.

> А еще в 64-битном режиме 64-разрядная математика работает быстрее.

через libastral, ALU боги послали?

> А поскольку например лимит в 4 гига при работе с файлами нас не устроит
> — 64-битная математика нынче в каждом закоулке.

это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления — они мегатормозят.

> И если 64-битному процу это 1 операция, на 32-битном это выливается

…в ту же одну операцию на том же ALU. а данные для неё благодаря спекулятивке и параллельному исполнению уже давно в камне.

> на х86 у которого регистров полторы штуки

ну и фиг с ним. компилятор разберётся. а обращение к памяти для тасования регистров всё равно закэшировано.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 27-Ноя-13 22:01 
> зато кэш процессора — существенно. указателей в ядре много, все указатели в
> два раза больше.

Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение длины регистров - неплохой шаг.

>> А еще в 64-битном режиме 64-разрядная математика работает быстрее.
> через libastral, ALU боги послали?

Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; в) бОльший размер регистров - не забываем, что i?86 ядро ничего о расширенном наборе явно доступных регистров и их увеличенной длине не знает. Если уж хочется сократить объем памяти под указатели - есть x86-64/x32, хотя пользы от него кот наплакал.

>> — 64-битная математика нынче в каждом закоулке.
> это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления
> — они мегатормозят.

Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее число явно доступных регистров позволяет меньше лазить в память при вычислениях, и оперировать бОльшими блоками, что позитивно влияет на кеширование.

>> И если 64-битному процу это 1 операция, на 32-битном это выливается
> …в ту же одну операцию на том же ALU

Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно оптимально в условиях конвееризации.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:32 
> Кэши тоже растут

и поэтому надо сильней забивать их мусором!

> По вычислениям остаётся только распараллеливание — и увеличение
> длины регистров — неплохой шаг.

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

> Если уж хочется сократить объем памяти под указатели — есть
> x86–64/x32, хотя пользы от него кот наплакал.

да нет его, увы. пересобирать руками всю систему и скакать по граблям я как-то не особо готов.

> Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8.

да пофигу им, пофигу. не заметишь ты разницы — разве что если твоя программа два часа ничем другим не занимается, кроме как усердно копирует стомегабайтную строку.

> Большее
> число явно доступных регистров позволяет меньше лазить в память при вычислениях,
> и оперировать бОльшими блоками, что позитивно влияет на кеширование.

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

>>> И если 64-битному процу это 1 операция, на 32-битном это выливается
>> …в ту же одну операцию на том же ALU
> Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно
> оптимально в условиях конвееризации.

и всё это по-прежнему нифига не заметно.

не надо мне доказывать, что много регистров — хорошо: я это и так знаю. однако на практике разница в скорости между x86 и x86_64 на десктопе не заметна. а gcc у меня большой проект ещё и медленней собирал, зараза (подозреваю, что у него как раз немножко кончилась RAM).


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 28-Ноя-13 07:30 
> честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений.
> а плавающим числам и вовсе плевать на целочисленые регистры, у них
> своя подсистема.

Вообще-то в режиме x86-64 и SSE-регистров поболе.

> да пофигу им, пофигу. не заметишь ты разницы

Даже на банальном веб-сервере разница есть. Там как раз в основном программы и занимаются тем, что тасуют строки...

> и всё это по-прежнему нифига не заметно.

Кому как. На десктопах с аськой и браузером, наверное, действительно будет незаметно. А вот если кодированием видео заняться - тут уже разница вылезет.

Когда что-то на сервере ворочается - заметно. В свое время переход с x86-32 на x86-64 дал где-то 5-7% производительности по LAMP, за данный момент не скажу - ни одного сервера с x86-32 просто не осталось, и даже x86-32 библиотек ни на одном нет. Тестировать не на чем.

Из личного хобби еще был MaNGOS - тому вообще сильно похорошело (где-то на четверть упала нагрузка на CPU).

MySQL (и прочие движки БД) прекрасно умеет юзать и любит более 4Гб памяти.

Так что если кто-то конкретный не может задействовать фичи x86-64 - это не значит, что x86-64 не нужен.

Компиляция больших проектов GCC, кстати, именно что имеет обратную разницу между x86-32 и x86-64, c 99% вероятностью из-за того, что в сумме упирается в диск. Дисковых операций тут получается (в основном из-за выравнивания мелких структур, + объем кода на x86-64 несколько больше) несколько больше, соответственно процесс идет несколько дольше. Тут, правда, ccache может спасти очень даже неплохо хоть на x86-32, хоть на x86-64.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 08:00 
> Вообще-то в режиме x86–64 и SSE-регистров поболе.

ссе — вовсе не панацея для всех случаев. но да, возможно.

>> да пофигу им, пофигу. не заметишь ты разницы
> Даже на банальном веб-сервере разница есть. Там как раз в основном программы
> и занимаются тем, что тасуют строки…

значит, говнокодеры писали. не надо в веб-серверах постоянно строки тасовать.

> А вот если кодированием видео заняться — тут уже разница вылезет.

я где-то писал, что ежедневно видео кодирую? это *не десктопная* задача. а я вёл речь про десктопы. ну, вот мой, например, где чаще всего запускается gcc. и нет, я пробовал: никакого мегавыигрыша переход на 64-битную систему мне не дал.

> Когда что-то на сервере ворочается — заметно.

мне в каждом посте после каждого слова в скобках писать «десктоп»? я *не вёл речи* про специализированные задачи изначально.

ну и да, традиционно: ламп говно. очень сильно — из-за последей «п».

всё остальное поскипал, потому что там после каждого слова надо было скобочки с «десктоп» вписывать.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 28-Ноя-13 20:12 
>> Вообще-то в режиме x86–64 и SSE-регистров поболе.
> ссе — вовсе не панацея для всех случаев. но да, возможно.

Ну какбэ вместо команд FPU GCC для float уже давно юзается SSE.

>> Когда что-то на сервере ворочается — заметно.
> мне в каждом посте после каждого слова в скобках писать «десктоп»?

Да. Потому что десктопное применение Linux - это очень узкая ниша...


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 29-Ноя-13 03:00 
>>> Когда что-то на сервере ворочается — заметно.
>> мне в каждом посте после каждого слова в скобках писать «десктоп»?
> Да. Потому что десктопное применение Linux — это очень узкая ниша…

ну (десктоп), извини (десктоп), я (десктоп) думал (десктоп), что (десктоп) простые (десктоп) вещи (десктоп) очевидны (десктоп).


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 29-Ноя-13 07:34 
А в целом идея неплоха, скобочки с десктопом несколько освежают текст. Стоит продолжать.

Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером ты просто не заметишь разницы между x86-32 и x86-64. В случае видео (не важно - проигрывания, кодирования, с участием аппаратной части для (де)кодера или без) - уже косвенно заметишь эти самые 5-15% разницы, хотя бы через температуру CPU при проигрывании и время работы при кодировании. В офисном пакете - вряд ли заметишь. Но легко заметишь при обработке изображений - inner loop фильтров неплохо оптимизируются числом и жирностью регистров.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 29-Ноя-13 10:26 
> Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером
> ты просто не заметишь разницы между x86–32 и x86–64.

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

вариант «да поставь ещё один дистрибутив, хитро замаскированый словом multilib» — не предлагать.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 28-Ноя-13 00:17 
> два раза больше.

У современных процессоров кэши тоже большие. А всякие PAE тоже прямизны в работе с памятью не добавляют. И скорость работы IIRC сажают. Ну и вообще - примеры где 32-битные системы по скорости лучше 64-битных будут?

> чтобы продать что-нибудь ненyжное, надо сначала купить что-нибудь ненyжное.

Я думаю что при таком зуде вполне можно что-нибудь объявить ненyжным, чтобы не засоряло память и кэши процессора :). Можно какой-нибудь bash например расстрелять за то что слишком жирный.

> почти два гигабайта ему вполне достаточно.

Что за 2 гигабайта? И почему именно 2?

>> А еще в 64-битном режиме 64-разрядная математика работает быстрее.
> через libastral, ALU боги послали?

Через регистры, мля. В 32-битном режиме вывешивается жалкий обрубок от ALU, с мизером куцых 32-битных регистров. И то что в 64-битном режиме записывается как 1 регистровая операция, в 32-битном будет немеряной этажеркой с тасовкой регистров и спасибо если без пушпопов которые в сумме равны NOPам и являют собой "необходимое зло" (которое вообще не часть логики программы).

> это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления
> — они мегатормозят.

Учитывая сколько регистров у х86 уродца - там не больно пошикуешь, программа наполовину состоит из сохранения-восстановления тасуемых в процессе счета регистров. Даже просто вызов функции - пушпоп по любому. В 64-битном режиме ABI передает все через регистры, если параметров не сильно много (в большинстве функций так и есть). Так что там еще и основания для более быстрого вызова функций есть - действий меньше.

> …в ту же одну операцию на том же ALU. а данные для
> неё благодаря спекулятивке и параллельному исполнению уже давно в камне.

Данный тезис не объясняет тот факт что 64-битные как правило программы быстрее. Не, конечно можно накапать море пипеткой, а 64-битную математику - 32-битными командами. Но вот оптимальность этого действия вызывает некоторые вопросы.

> ну и фиг с ним. компилятор разберётся. а обращение к памяти для
> тасования регистров всё равно закэшировано.

Тем не менее, в среднем по больнице 64-битные программы как-то быстрее получаются обычно. Хотя может SSE2 еще как-то влияет.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:43 
> У современных процессоров кэши тоже большие.

см. #108.

> примеры где 32-битные системы по скорости лучше 64-битных будут?

см. #108, последний абзац.

> Я думаю что при таком зуде вполне можно что-нибудь объявить ненyжным, чтобы
> не засоряло память и кэши процессора :). Можно какой-нибудь bash например
> расстрелять за то что слишком жирный.

а, то есть, гвидобейсика у меня нет, случился облом. алгоритм слетел с нарезки и пошёл рандомно тыкать в софт. круто.

>> почти два гигабайта ему вполне достаточно.
> Что за 2 гигабайта? И почему именно 2?

потому что это примерный объем свободной RAM в моей рабочей технике. остальное занято.

> и спасибо если без пушпопов которые в сумме равны NOPам

и по скорости тоже. давно уже это мегадёшево, но некоторые гики до сих пор упарываются. а если ваших 64-битных регистров не хватит (а их не хватит), то push/pop, исходя из твоей логики, ещё больше всё тормознут. гыг.

> и являют собой «необходимое зло» (которое вообще не часть логики программы).

прикинь: в любом машинном коде такого «необходимого зла» дофига. иначе «декомпиляция» была бы тривиальной задачей.

> Учитывая сколько регистров у х86 уродца — там не больно пошикуешь, программа
> наполовину состоит из сохранения-восстановления тасуемых в процессе счета регистров.

в x86_64 их не намного больше. и все их надо радостно перезагружать после вызова функции (или не менее радостно терять). а поскольку вызовы функций — дело очень частое, то получается, что ваш x86_64 ВНИЗАПНА! даёт выигрыш только говнокодерам, которые пишут портянки на десять экранов без единого обращения «наружу». гыг. спасибо, в таком разрезе я об этом раньше не думал.

> Так что там еще и основания для более быстрого вызова функций есть — действий меньше.

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

а регистров у x86_64 не настолько много, чтобы всё было так уж красиво.

> Данный тезис не объясняет тот факт что 64-битные как правило программы быстрее.

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

> Не, конечно можно накапать море пипеткой, а 64-битную математику — 32-битными
> командами. Но вот оптимальность этого действия вызывает некоторые вопросы.

необходимость тоже. умножение/деление 64 на 32 давно уже одной командой делается. в подавляющем большинстве случаев этого достаточно.

> Тем не менее, в среднем по больнице 64-битные программы как-то быстрее получаются
> обычно.

см. выше.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 19:52 
> 32-битный софт остаётся 32-битным.

Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. И, кстати, разница за счет размеров указателей и префиксов команд не такая уж и большая как может показаться - как правило здорово меньше чем в 2 раза.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:10 
>> 32-битный софт остаётся 32-битным.
> Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли.

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

> кстати, разница за счет размеров указателей и префиксов команд не такая
> уж и большая как может показаться — как правило здорово меньше
> чем в 2 раза.

я уже писал про кэш процессора, который засирается быстрее. потому что не только указатели, но и инты часто в 64 превращают. и структуры больше занимают. а если не превращают, и продолжают использовать 32-битные инты — то тем более: нафига?


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 28-Ноя-13 00:21 
> получить такого, ради чего стоило бы заниматься подобной фигнёй.

У, да ты походу весьма заржавелый типец.

> только указатели, но и инты часто в 64 превращают. и структуры
> больше занимают. а если не превращают, и продолжают использовать 32-битные инты
> — то тем более: нафига?

Ну да, по такой логике всем должно хватать 8-битных процессоров. Хотя это слишком жирно, хватит и 4-битного 4004, пожалуй. Зато сэкономим на всем чем только можно.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 28-Ноя-13 01:46 
>> получить такого, ради чего стоило бы заниматься подобной фигнёй.
> У, да ты походу весьма заржавелый типец.

да: я очень не люблю делать что-либо только потому, что нынче это модно.

> Ну да, по такой логике всем должно хватать 8-битных процессоров.

нет. у тебя проблемы с логикой.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено d , 26-Ноя-13 09:17 
ну если 10% для Вас не разница ...

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 26-Ноя-13 09:34 
> ну если 10% для Вас не разница …

во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.

а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое место» — это в большинстве случаев не процессор. и от того, что процессор будет на 10% (положим) процентов быстрее ничего не делать, пока ожидает i/o, скорость нифига не увеличится. доступно, нет?


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:40 
> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.

Оттуда что
1) Нет постоянной перегрузки полутора куцых регистров.
2) Сами регистры 64-битные и в более вменяемом количестве.

> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое
> место» — это в большинстве случаев не процессор.

А вот это уже когда как.

> пока ожидает i/o

Капитан намекает что оперативка - она, зараза, быстрая. При большой оперативе можно получить весьма ширный кжш. Особенно здорово в паре с SSD под системный диск. В системе все работает со скоростью выстрела из пушки. Да, наконец то я дожил до момента когда писюк может работать не хуже чем мой первый компьютер (где операционка подпертая RAM-диском ребутилась за ~пяток секунд, запускала программы с рамдиска мгновенно и прочая).


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:14 
>> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.
> Оттуда что
> 1) Нет постоянной перегрузки полутора куцых регистров.
> 2) Сами регистры 64-битные и в более вменяемом количестве.

а почему не 146%? потолки низкие, с другого потолка другие проценты бы взяли?

>> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое
>> место» — это в большинстве случаев не процессор.
> А вот это уже когда как.

лично у меня именно так.

>> пока ожидает i/o
> Капитан намекает что оперативка — она, зараза, быстрая. При большой оперативе можно
> получить весьма ширный кжш.

всё бросил, побежал ставить 100500 гигов RAM.

> SSD

не интересует.

> В системе все работает со скоростью выстрела из пушки.

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

нет, я не против SSD как такового. но у меня его нет, и покупать его я не собираюсь.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 15:08 
> ну если 10% для Вас не разница ...

«Скорость — это не главное»™


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено d , 26-Ноя-13 16:06 
правильно не главное главное стабильность так вот разработчики сейчас а первую очередь обращают внимание на x64 так что он и постабильнее будет

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 17:18 
Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 лет не исполнилось, место на помойке.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено pavlinux , 26-Ноя-13 19:09 
Последний i386 вышел лет 20 назад! Назывался Pentium Pro.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 21:44 
>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.

вообще-то это i686


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 26-Ноя-13 22:57 
>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
> вообще-то это i686

Кстате (sic!) да, как раз P-Pro и ознаменовал конец эпохи "чистых" i386, и переход на RISC с трансляцией. Хотя попытки были и до него, то ли у Cyrix, то ли у NexGen, если память не изменяет.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено pavlinux , 27-Ноя-13 00:34 
>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
> вообще-то это i686

Если чо, то i386 - нет такой архитектуры, есть x86.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 27-Ноя-13 07:24 
Под "архитектурой i386" понимается конкретный набор расширенных команд i386, модель использования регистров, организацию памяти, форматы системных таблиц для CPU и т.д. Короче говоря - именно то, что и является архитектурой для софта. Между i386 и i286 произошли очень существенные изменения. В пределах "единой" архитектуры x86, угу.

Далее кое-что весомое случилось между Pentium (i586) и Pentium-Pro (i686), тоже выделилось в отдельную архитектуру. Далее - случилась AMD64 (x86-64), которая тоже "типа" архитектура. И всё это - снова в пределах x86.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено pavlinux , 27-Ноя-13 15:48 
Это у них называется поколения, все изменения происходят внутри, без изменения API.

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 27-Ноя-13 22:03 
> Это у них называется поколения, все изменения происходят внутри, без изменения API.

Это у вас оно называется поколения, а у разработчиков оно ныне называется architecture (i386, i686, AMD64).


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено AlexAT , 26-Ноя-13 20:33 
> Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная
> временем», а всякой новомодной фигне типа x86_64, которой еще даже 30
> лет не исполнилось, место на помойке.

С разморозкой. i386 в новых ядрах уже убили, осталась i686. И ту скоро выпилят за ненадобностью. Мейнстрим уже давно x86-64, а для особых любителей извращений останется x86-64/x32.

P.S. Скоро - это лет 10+-5.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 21:40 
>мне точно не надо — два установленых дистрибутива.

Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено Аноним , 26-Ноя-13 21:40 
или только 64битное ПО

"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:17 
>>мне точно не надо — два установленых дистрибутива.
> Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.

если вдруг до тебя не доходит, то miltilib — это и есть «два дистрибутива».


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено EuPhobos , 26-Ноя-13 08:57 
<игромания>
Теперь можно будет сохраняться в играх, в которых не предусмотрены сохранения ;)
</игромания>

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено bobr , 26-Ноя-13 17:01 
Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных девяти игроков (-: А вернувшись с пар/уроков доиграть.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 17:22 
> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных
> девяти игроков (-: А вернувшись с пар/уроков доиграть.

Это уже нужно делать синхронизацию с аппаратными криокамерами :-)


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 17:42 
> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных
> девяти игроков (-: А вернувшись с пар/уроков доиграть.

Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер. Иначе они заметят что тут что-то не так.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено AlexAT , 26-Ноя-13 21:31 
> Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер.
> Иначе они заметят что тут что-то не так.

А почему бы нет? Причем ведь прокатит.

1. Вешаем на сервер хитрый апп, раздающий специфичным клиентам команду на заморозку, синхронную, и замораживающий сам сервер. На клиенты вешаем "ответный" апп, принимающий команду и запускающий заморозку. В стоп-фазу приложения выйдут почти синхронно у всех игроков и на сервере, ага. TCP-коннекты также успешно замораживаются, а с UDP там вообще без бубликов в этом плане.

2. Потом аналогично когда все собрались, апп выдает команду на разморозку, сервер и клиенты размораживаются в стоп-фазу (без выполнения), и далее апп дает команду на старт. Коннекты тоже разморозились, аппы стартуют у всех одновременно, и все благополучно продолжают игру - ну, с небольшим лагом на несколько секунд, из-за слегка разъехавшихся таймеров. Главное, чтобы IP за это время не сменились xD

Очень даже для случаев, когда нативно сейв сетевой игры не поддерживается :)

Что до того, что "заметят" - коннекты не упадут, а с небольшого лага и разъезжания таймеров большинство игрушек восстанавливаться давно умеет.


"Выпуск CRIU 1.0, системы для заморозки и восстановления..."
Отправлено arisu , 27-Ноя-13 01:20 
дима завалишин оргазмирует в восторге.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено pavlinux , 27-Ноя-13 05:46 
Ты запусти сначала эту хрень, и уморозь хотя бы cron иль atd ... размечтались тут :D

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено bobr , 27-Ноя-13 13:10 
То, что вы тут пытаетесь описать ничем по эффекту не отличается от обычной паузы, которая предусмотрена игрушкой. Для этого не нужна заморозка процессов сервера. Мой же пост выше был просто саркастическим ответом на высказывание о сохранении в играх, в которых это не предусмотренно. Тут более даже уместен пост об аппаратных криокамерах.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено AlexAT , 27-Ноя-13 18:26 
А ресурсы системы (память, в частности) во время паузы освобождаются? Нет? То-то.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 20:03 
Или возобновить работу упавшего сервера ТФ2… оч. жду когда можно будет попробовать эту фичу

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено Аноним , 26-Ноя-13 21:10 
А это случайно не то же самое, что пытается сделать Дмитрий Завалишин? Персистентность и так далее...

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено pavlinux , 27-Ноя-13 05:40 
Они, что издеваются?!!!  

# make
  GEN      include/config.h
make[1]: Вход в каталог `/media/kernel/crtools'
  PB DDEP  protobuf/stats.proto.d
  PB DEP   protobuf/stats.proto.c.d
  PBCC     protobuf/stats.pb-c.h
make[1]: protoc-c: Команда не найдена

# svn checkout http://protobuf-c.googlecode.com/svn/trunk/ protobuf-c
# cd protobuf-c
# ./autogen.sh

checking google/protobuf/stubs/common.h usability... no
checking google/protobuf/stubs/common.h presence... no
checking for google/protobuf/stubs/common.h... no
configure: error:
  ERROR: protobuf headers are required.

  You must either install protobuf from google,
  or if you have it installed in a custom location
  you must add '-Iincludedir' to CXXFLAGS
  and '-Llibdir' to LDFLAGS.

  You can download the google's protobuf library from
  the following page:
      http://code.google.com/p/protobuf/downloads/list

# svn checkout http://protobuf.googlecode.com/svn/trunk/ protobuf
# cd protobuf
# ./autogen.sh

---
- ptrace-parasite (https://code.google.com/p/ptrace-parasite/)

# git clone https://code.google.com/p/ptrace-parasite/
# cd ptrace-parasite
# make
gcc -Wall -fpic -c parasite.c
ld -T parasite.lds -o parasite.bin parasite.o
echo 'static char parasite_blob[] = {' > parasite-blob.h
hexdump -v -e '"\t"' -e '8/1 "0x%02x, "' -e '"\n"' parasite.bin >> parasite-blob.h
echo '};' >> parasite-blob.h
gcc -Wall -o parasite main.c -lnetfilter_queue -lpthread
main.c:34:51: фатальная ошибка: libnetfilter_queue/libnetfilter_queue.h: Нет такого файла или каталога
компиляция прервана.
---
Your system IS little-endian
---

# criu check
Looks good.

Да, ладно?!  

[сообщение отредактировано модератором]


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено pavlinux , 27-Ноя-13 06:01 
- Thunderbird
# criu dump -D /var/lib/criu/ -t `pgrep thunderbird` --file-locks
(00.866931) Error (parasite-syscall.c:387): si_code=4 si_pid=24691 si_status=5
(00.877824) Error (cr-dump.c:354): Task 24138 with SysVIPC shmem map @7f780ae26000 doesn't live in IPC ns
(00.877877) Error (cr-dump.c:1559): Dump mappings (pid: 24138) failed with -1
(00.879843) Error (cr-dump.c:1811): Dumping FAILED.

- Firefox
# criu dump -D /var/lib/criu/ -t `pgrep firefox`  --file-locks
(00.145646) Error (sk-inet.c:139): Connected TCP socket, consider using tcp-established option.
(00.145732) Error (cr-dump.c:1491): Dump files (pid: 4559) failed with -1
(00.150637) Error (cr-dump.c:1811): Dumping FAILED.

- Opera
# criu dump -D /var/lib/criu/ -t `pgrep opera` --file-locks
(00.190498) Error (sk-inet.c:139): Connected TCP socket, consider using tcp-established option.
(00.190595) Error (cr-dump.c:1491): Dump files (pid: 31621) failed with -1
(00.193811) Error (cr-dump.c:1811): Dumping FAILED.

- Netbeans
# criu dump -D /var/lib/criu/ -t `pgrep java` --file-locks
(01.673821) Error (cr-dump.c:354): Task 6962 with SysVIPC shmem map @7f0fe331e000 doesn't live in IPC ns
(01.673891) Error (cr-dump.c:1559): Dump mappings (pid: 6962) failed with -1
(01.675928) Error (cr-dump.c:1811): Dumping FAILED.

# zcat /proc/config.gz | grep CONFIG_IPC_NS
CONFIG_IPC_NS=y
# ls /proc/22378/ns/ipc -la
lrwxrwxrwx 1 root root 0 нояб. 27 06:15 /proc/22378/ns/ipc -> ipc:[4026531839]

- Bind
# criu dump --images-dir  /var/lib/criu/ --tree `pgrep named` --leave-stopped  --file-locks --tcp-established --track-mem
(00.002544) Error (cr-dump.c:833): Stopped threads not supported
(00.003297) Error (cr-dump.c:833): Stopped threads not supported
(00.003798) Error (cr-dump.c:833): Stopped threads not supported
(00.004278) Error (cr-dump.c:833): Stopped threads not supported
(00.004759) Error (cr-dump.c:833): Stopped threads not supported
(00.005198) Error (cr-dump.c:833): Stopped threads not supported
(00.005251) Error (cr-dump.c:1002): Can't freeze the tree
(00.005391) Error (cr-dump.c:1811): Dumping FAILED.

С тредами не умеет  Чё оно ваще может? Хелловорды дампить?!
Глюкалово корявое... :D

http://criu.org/What_cannot_be_checkpointed


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено dr , 06-Дек-13 11:36 
Да с номером версии 1.0 - это они погорячились. Я тоже не осилил задампить/заресторить хоть один полезный процесс. Пршлось писать спец. демон, который ничего не умеет, кроме как писать в лог сообщения. Слава разрабам, что хоть на нём тулза отработала!

Посмотрим на динамику развития проекта, ведь идея-то неплохая) Зато у каого есть желание поконтрибутить - простор невероятный.

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено avagin , 10-Дек-13 11:11 
Графические приложения дампить не умеем на сайте явно написано. Первоочередная цель миграция и чекпоинтинг контейнеров. Если есть кто-то готовый заняться, you are welcome.

С java-ой вылетело, потому что shmem удален и такой случай поддерживается только при дампе ipcns. Запустите свое приложение unshare -i -- CMD

C named скорей всего проблема в том, что приложение постопано SIGTSTP, который тоже пока не поддерживается.

ps: pgrep использовать в данном случае не уместно, т к он может выдать больше одного значения.


"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."
Отправлено lucentcode , 29-Ноя-13 19:47 
Интересный проект.