форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
Сообщение от opennews (ok) on 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.dev/opennews/art.shtml?num=38519
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от Dcow (ok) on 25-Ноя-13, 21:47
А кто может подсказать, как происходить переброс TСP соединения?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 25-Ноя-13, 21:57
	Надо полагать, вместе с сетевым стеком контейнера, включая IP-адрес.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

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

	48. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:40
	IP тот же остается или можно поменять на другой?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	53. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:24
	> IP тот же остается или можно поменять на другой? По всей видимости, тот же. Он привязан к виртуальному стеку контейнера (netns) и передается вместе с ним.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	8. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 25-Ноя-13, 22:12
	>  А кто может подсказать, как происходить переброс TСP соединения? Ну вот так: - Траффик заворачивается на другую железяку. - Ядру хинтят состояние TCP стека. Ничему такому особо не противоречит если состояние сетевого стека восстановить.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	42. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–3 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:00
	> Ну вот так: > - Траффик заворачивается на другую железяку. > - Ядру хинтят состояние TCP стека. Узнаю нашего старого доброго user294 - ни слова по делу, зато рунглиш из всех щелей :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

4. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
Сообщение от arisu (ok) on 25-Ноя-13, 22:00
кого-то таки достал полурабочий cryopid? похвально. и вообще, давно хочу такую штуку, чтобы полноценно работала.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от Аноним (??) on 25-Ноя-13, 22:01
Надо ещё на systemd-logind протестировать его.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–4 +/–
	Сообщение от arisu (ok) on 25-Ноя-13, 22:06
	> Надо ещё на systemd-logind протестировать его. зачем? поцтеринг вам напишет свою реализацию. кривую, косую, хреново документированую и интегрированую в системды по самое дальше некуда.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 25-Ноя-13, 23:23
	Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–2 +/–
	Сообщение от arisu (ok) on 25-Ноя-13, 23:39
	> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона. а-а-а. тогда да, одобряю.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	39. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 14:55
	> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона. Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого проблемы сваливаешь на Поттеринга.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	45. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:07
	> Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого > проблемы сваливаешь на Поттеринга. Еще можно нажать Alt+SysRq+B и потом придти скандалить в LKML "ваш линyпс убил все мои данные". Вот только Линус не Леннарт, может и наxер послать.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	27. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от 1 (??) on 26-Ноя-13, 08:15
	кривые только руки твои, сачок ) коль не осилил, так на себя пенять надо
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	28. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от 1 (??) on 26-Ноя-13, 08:17
	вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	54. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:25
	> вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас Вообще-то 294-й достаточно нормально относится к идее чего-то типа systemd. По крайней мере upstart мне пришелся вполне по вкусу и мне с ним как-то сильно проще получается добавлять новые кастомные демоны в систему. Ну и systemd освою, если из него выбьют дурь и так получится что ему суждено стать новым иниицализатором в большинстве пингвинов. А пока пусть на кошках^W федористах и арчеводах тренируются и обезглючивают.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	61. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:43
	> По крайней мере upstart мне пришелся вполне по вкусу Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги при малейшей ошибке в синтаксисе.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	97. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 27-Ноя-13, 20:52
	> Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги > при малейшей ошибке в синтаксисе. Ну я как бы не возражаю что оно должно бы чертыхнуться куда-нибудь в лог. Багу своему гарри поттеру вы написали уже? Или как обычно? И если уж мы про ошибки - вот уж знаете ли, в классическом ините ловить ошибки форменный головняк. Там вообще никакого логинга нет, так что что и почему обломалось - как хочешь так и узнавай. Сам логгинг допишешь, фигли.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	40. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 14:56
	> кривые только руки твои, сачок ) > коль не осилил, так на себя пенять надо Такие, как он, всегда видят корень своих проблем в окружающих. И просто неспособны осознать факт кривизны своих рук. Что ариса, что поттеринг, одна фигня.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	43. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:02
	> Надо ещё на systemd-logind протестировать его. Скорее наоборот, это в systemd будут тестировать фичи CRIU.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+1 +/–
Сообщение от Vee Nee on 25-Ноя-13, 22:10
Даже на офсайте сходу не удалось понять, с какой версии ядра все необходимое в состав ядра включено?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+1 +/–
	Сообщение от Аноним (??) on 25-Ноя-13, 22:29
	3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 25-Ноя-13, 22:32
	> 3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... это необязательная фича, вообще-то. p.s. насколько я понял из текста на офсайте, на практике не проверял.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	10. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 25-Ноя-13, 22:31
	> Даже на офсайте сходу не удалось понять, с какой версии ядра все > необходимое в состав ядра включено? судя как раз по офсайту — с 3.10 должно работать. проверить, правда, не могу — у меня некоторые нужные фичи выключены. а перезагружаться лень.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–8 +/–
Сообщение от arisu (ok) on 25-Ноя-13, 23:17
тьфу, распронаедрит налево! пересобирал ядро, перезагружался — а эта бесполезная фигня только для x86_64. ненужно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+9 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 00:20
	> x86 ненужно профиксил
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–4 +/–
	Сообщение от arisu (ok) on 26-Ноя-13, 00:36
	> профиксил херово и неверно.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	41. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 14:58
	>> профиксил > херово и неверно. Все правильно он починил. Ни замшелое гoвно, ни его адепты в этом мире никому не нужны.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	67. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 20:24
	а обосновать сможешь?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	78. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 27-Ноя-13, 00:57
	> а обосновать сможешь? тысячу тысяч раз уже говорено.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	70. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 21:31
	все правильно. Устаревшие архитектуры ненужны.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	77. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 00:57
	> все правильно. Устаревшие архитектуры ненужны. я согласен, x86 и x86_64 обе — устарели и нафиг не нужны.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	18. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+5 +/–
	Сообщение от kurokaze (ok) on 26-Ноя-13, 01:45
	>только для x86_64 Отлично, я еще 8 лет назад перешел исключительно на 64 бита
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	21. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–4 +/–
	Сообщение от arisu (ok) on 26-Ноя-13, 05:07
	> Отлично, я еще 8 лет назад перешел исключительно на 64 бита мне очень важно было это узнать, спасибо.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	38. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от ABATAPA (ok) on 26-Ноя-13, 12:21
	Так же, как нам - что Вам "не нужно".
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	96. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от гость on 27-Ноя-13, 18:41
	Любка, ты чтоль?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	47. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:10
	> мне очень важно было это узнать, спасибо. А нам очень интересно было прочитать про ваши половые трудности с 64-битными системами. Продолжайте держать нас в курсе.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	44. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:05
	> Отлично, я еще 8 лет назад перешел исключительно на 64 бита Да уже несколько лет как большая часть x86 железа ушла на свалки. Так что на 32 битах нынче сидят разве что виндyзятники и фимозники в терминальной стадии.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	55. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+2 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:29
	> Да уже несколько лет как большая часть x86 железа ушла на свалки. Ну так 64-битные процессоры появились чуть ли не десятилетие назад. А при современных ценах нагревать себя на оперативку - просто глупо. Даже если программам столько нафиг не упало, большой дисковый буфер сделает работу с машиной не в пример приятнее. Когда все оглавление всех дисков висит в оперативе и никогда не выжимается, а все рабочие наборы целиком прокешированы - работать с машиной становится заметно приятнее. Просто потому что практически все операции происходят как выстрел из пушки.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	79. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:00
	о, виндузятник пришёл. это у вас в винде 32-битная икспишечка не может в больше четырёх гигов памяти. 32–битный линукс вполне может.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	91. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от Проходимец on 27-Ноя-13, 08:50
	ХР SP1 может адресовать до 16GB из 32 возможных в 36-битном адресном пространстве. Только не спрашивайте, куда дел 36-й бит и еще 32GB. Патч весьма простой, помогает и следующим сервиспакам
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	92. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 09:15
	ссылку на то, где m$ его раздаёт?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	98. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 27-Ноя-13, 21:09
	> о, виндyзятник пришёл. Аж 294 раза. По что ругаешься, Кэп? (форум считает данное слово бранным, что конечно правильно, но усложняет ответ). > это у вас в винде 32-битная икспишечка не может > в больше четырёх гигов памяти. 32–битный линукс вполне может. Все несколько проще. Раскуривать сорцычтобы самому найти ответ мне было дико обломно: мне и так есть чем заняться и экскурсия в управление кэшом на такую глубину без причины меня не соблазнила. А конфигов с 32-битным процом где более 4Гб памяти у меня элементарно нет, т.к. я не сторонник извращений типа PAE и прочая и полагаю что если в системе есть более 4 гигз памяти то и 64 бита на указатель можно выкроить как-нибудь и не развалиться при этом. Система которая не может напрямую адресовать свою память без извращений - дрянь. Спасибо, всякие схемы банкинга и прочие костыли мне уже давно сидят в печенках. Да, я люблю линейные адресные пространства, где можно просто получить то что хотелось а не заниматься фигурным костылестроением. Надо же, какой я негодяй :).
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	105. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 01:19
	> По что ругаешься, Кэп? я не ругался, я обзывался. как будто я тебя не узнал. > форум считает данное слово бранным «почто»? про всё остальное. была же задумка x32 (или как там её) — издохла, что ли? это как раз здравая идея же: профиты в виде расширеного регистрового пространства и отсутствие дебилизма с указателями. а ещё ваша 48-битовая фигня еле-еле поместилась в double nan. с ужасом жду, когда очередной модный-молодёжный скажет, что 48 бит для указателя мало, придумает очередную дикую схему адресации и указатели перестанут в double nan влазить.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	111. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok) on 28-Ноя-13, 05:08
	> про всё остальное. была же задумка x32 (или как там её) — > издохла, что ли? это как раз здравая идея же: профиты в > виде расширеного регистрового пространства и отсутствие дебилизма с указателями. Нет, не "издохла". Вот только она касается только юзерспейса - ядро там всё равно используется стандартное x86_64, а у тебя на него аллергия:)
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	112. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 05:30
	> Нет, не «издохла». Вот только она касается только юзерспейса - ядро там > всё равно используется стандартное x86_64, а у тебя на него аллергия:) у меня на него аллергия, когда оно без толку суётся. в x32 я толк вижу — в отличие от 64-битного ядра с 32-битным остальным или полной 64-битности. p.s. сайт у них ужасен, у меня глаза болят и щека дёргается.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	113. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от AlexAT (ok) on 28-Ноя-13, 07:17
	> про всё остальное. была же задумка x32 (или как там её) — > издохла, что ли? это как раз здравая идея же: профиты в > виде расширеного регистрового пространства и отсутствие дебилизма с указателями. Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	116. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 07:52
	> Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти. точно такие же, как и у других режимов, насколько я помню.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	19. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Kibab (ok) on 26-Ноя-13, 01:52
	А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной версии которого не существует? :-)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	23. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–2 +/–
	Сообщение от arisu (ok) on 26-Ноя-13, 05:09
	> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной > версии которого не существует? :-) а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? а, и ещё чтобы multilib держать, а то одной копии дистрибутива мне мало?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	24. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok) on 26-Ноя-13, 06:02
	>> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной >> версии которого не существует? :-) > а зачем мне 64-битная система, если у меня нет софта, которому требуется > больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? > а, и ещё чтобы multilib держать, а то одной копии дистрибутива > мне мало? А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 26-Ноя-13, 06:10
	> А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс? не знаю, у меня ядро 32-битное, так что проверить не могу.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	56. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:30
	> не знаю, у меня ядро 32-битное, так что проверить не могу. А у тебя и пямяти меньше 4 гигз? Или мсье нравятся феерические костыли типа PAE? И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	62. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:45
	> И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать? «Дисковый кэш — кривая хрень, которой пользуются только законченные идиoты» ©arisu
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	80. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:02
	>> не знаю, у меня ядро 32-битное, так что проверить не могу. > А у тебя и пямяти меньше 4 гигз? а какое отношение? > Или мсье нравятся феерические костыли типа PAE? а мне без разницы, я это руками не делаю. > И кстати может ли 32-битное ядро скажем дисковый > кэш скажем в 8Гб сделать? вот этого не помню. но мне таки без разницы: у меня 4 гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не бегу докупать памяти «просто чтобы было побольше».
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	99. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 27-Ноя-13, 21:17
	> а мне без разницы, я это руками не делаю. Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким костылем. > вот этого не помню. но мне таки без разницы: у меня 4 > гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не > бегу докупать памяти «просто чтобы было побольше». Ну а я не против запустить пару виртуалок и загрузить все оглавление дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM drive все-таки.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	106. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 01:22
	>> а мне без разницы, я это руками не делаю. > Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким > костылем. тогда тебе исключительно в real mode. потому что в protected ты вообще адресуешь некую виртуальную сущность. > Ну а я не против запустить пару виртуалок и загрузить все оглавление > дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM > drive все-таки. да на здоровье — я тебе запрещаю, что ли? как я уже говорил — x32 было бы хорошим вариантом. но увы — модные-молодёжные не привыкли экономить ресурсы.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	114. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Ноя-13, 07:20
	> тогда тебе исключительно в real mode. потому что в protected ты вообще > адресуешь некую виртуальную сущность. Дело не в этом. Дело в костылях в виде сегментов или оконной загрузки страниц. На данный момент это именно костыль, поскольку основное API ОС расчитывает на линейную адресацию. В long mode, тьфу-тьфу, "виртуальную сущность" упростили именно до линейной адресации, без сегментации. Вполне себе хватает и того, что страницы можно подключать в произвольном порядке. Это, кстати, на производительности тоже сказывается.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	117. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 28-Ноя-13, 07:54
	> Дело не в этом. Дело в костылях в виде сегментов или оконной > загрузки страниц. вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? нет, не видишь. виртуальная память — костыль в любом случае. одним больше, одним меньше — уже без разницы.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	119. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Ноя-13, 20:11
	> вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? > нет, не видишь. Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86-32. Правда, я этого в рабочем режиме не сделаю никогда, потому что из ума еще не выжил :)
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	121. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 29-Ноя-13, 02:58
	> Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86–32. это, без сомнения, рутинная домашняя задача. все так делают, каждый день.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	123. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok) on 29-Ноя-13, 07:25
	> это, без сомнения, рутинная домашняя задача. все так делают, каждый день. Задача-то не домашняя, но вот работает она каждый день... И вполне себе рутинная, кстати :)
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	125. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 29-Ноя-13, 10:24
	я (десктоп) писал (десктоп) о (десктоп) несколько (десктоп) других (десктоп) областях (десктоп).
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	26. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+5 +/–
	Сообщение от AlexAT (ok) on 26-Ноя-13, 07:40
	>>> а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт x64 - это не только снятие лимита в 3 гигабайта. Это еще набор из 8 дополнительных доступных софту РОН и регистров SSE, увеличенная ширина регистров по умолчанию и несколько прочих плюшек, типа возможности работать с оффсетами относительно RIP.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	30. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 26-Ноя-13, 08:26
	ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при создании кода — мне пофигу. вот что мне точно не надо — два установленых дистрибутива.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	31. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok) on 26-Ноя-13, 08:55
	> ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при > создании кода — мне пофигу. вот что мне точно не надо > — два установленых дистрибутива. Достаточно добавить 64-битное ядро
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	33. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok) on 26-Ноя-13, 09:03
	> Достаточно добавить 64-битное ядро для чего? 32-битный софт остаётся 32-битным.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	36. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok) on 26-Ноя-13, 10:46
	>> Достаточно добавить 64-битное ядро > для чего? 32-битный софт остаётся 32-битным. Например, для CRIU. Да и "32-битного софта" можно запустить больше.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 26-Ноя-13, 11:38
	> Например, для CRIU. например, само ядро больше памяти слопает. > Да и «32-битного софта» можно запустить больше. с чего бы вдруг? 32-битное ядро ни разу не ограничено четырьмя гб памяти. а если в системе закончились пиды — то тут не ядро менять надо, а прокладку.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	57. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:36
	> например, само ядро больше памяти слопает. На машинах где 64 бита имеют смысл это как правило не принципиально. Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь уж существенно. И вообще, пристрелив какую-нить дрянь на питоне или чем там еще - можно сразу в 20 раз больше памяти отыграть, если уж так хочется. Еще ядро на машинах с большой памятью больше на служебные нужды забирает. Не без причин полагая что раз памяти много то и жабой давиться себе в ущерю ни к чему. Вполне логично. А еще в 64-битном режиме 64-разрядная математика работает быстрее. А поскольку например лимит в 4 гига при работе с файлами нас не устроит - 64-битная математика нынче в каждом закоулке. И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. А на х86 у которого регистров полторы штуки это выливается в кошмар. А в 64-битном режиме есть нормальный набор регистров и прочая и это даже уже похоже на нормальный процессор немного, а не кусок шита из ранних 80-х.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	59. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:41
	> И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. Как будто это что-то плохое.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	64. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 19:47
	> Как будто это что-то плохое. Вообще-то плохое, да. На одну и ту же операцию потратится намного больше тактов проца при прочих равных. В общем использовать обрубок оставленный чисто для совместимости при том что на том же кристалле более нормальное нечто собрано, с более нормальной системой команд - дурь несусветная.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	82. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:08
	использовать 64-битные указатели для адресации пары гигов памяти — вот это и есть дурь несусветная.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	100. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 27-Ноя-13, 21:19
	> использовать 64-битные указатели для адресации пары гигов памяти — вот это и > есть дурь несусветная. Да. Но я не вижу почему мне должно быть нельзя юзать всю доступную память из 1 процесса, опять же. Какое-то очередное "640К хватит всем". В то что 2^64 хватит на ближайшее время - я еще готов поверить даже.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	107. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 01:23
	> Да. Но я не вижу почему мне должно быть нельзя юзать всю > доступную память из 1 процесса, опять же. потому что ядро тебе не разрешит. даже 64-битное. > всем». В то что 2^64 хватит на ближайшее время — я > еще готов поверить даже. 2^48. остальные биты вашего огромного указателя тупо ничего не делают и копируются из 47-го.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	81. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:07
	> На машинах где 64 бита имеют смысл это как правило не принципиально. > Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь > уж существенно. зато кэш процессора — существенно. указателей в ядре много, все указатели в два раза больше. > И вообще, пристрелив какую-нить дрянь на питоне чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное. > Еще ядро на машинах с большой памятью больше на служебные нужды забирает. почти два гигабайта ему вполне достаточно. > А еще в 64-битном режиме 64-разрядная математика работает быстрее. через libastral, ALU боги послали? > А поскольку например лимит в 4 гига при работе с файлами нас не устроит > — 64-битная математика нынче в каждом закоулке. это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления — они мегатормозят. > И если 64-битному процу это 1 операция, на 32-битном это выливается …в ту же одну операцию на том же ALU. а данные для неё благодаря спекулятивке и параллельному исполнению уже давно в камне. > на х86 у которого регистров полторы штуки ну и фиг с ним. компилятор разберётся. а обращение к памяти для тасования регистров всё равно закэшировано.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	101. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 27-Ноя-13, 22:01
	> зато кэш процессора — существенно. указателей в ядре много, все указатели в > два раза больше. Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение длины регистров - неплохой шаг. >> А еще в 64-битном режиме 64-разрядная математика работает быстрее. > через libastral, ALU боги послали? Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; в) бОльший размер регистров - не забываем, что i?86 ядро ничего о расширенном наборе явно доступных регистров и их увеличенной длине не знает. Если уж хочется сократить объем памяти под указатели - есть x86-64/x32, хотя пользы от него кот наплакал. >> — 64-битная математика нынче в каждом закоулке. > это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления > — они мегатормозят. Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее число явно доступных регистров позволяет меньше лазить в память при вычислениях, и оперировать бОльшими блоками, что позитивно влияет на кеширование. >> И если 64-битному процу это 1 операция, на 32-битном это выливается > …в ту же одну операцию на том же ALU Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно оптимально в условиях конвееризации.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	108. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 28-Ноя-13, 01:32
	> Кэши тоже растут и поэтому надо сильней забивать их мусором! > По вычислениям остаётся только распараллеливание — и увеличение > длины регистров — неплохой шаг. честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. а плавающим числам и вовсе плевать на целочисленые регистры, у них своя подсистема. > Если уж хочется сократить объем памяти под указатели — есть > x86–64/x32, хотя пользы от него кот наплакал. да нет его, увы. пересобирать руками всю систему и скакать по граблям я как-то не особо готов. > Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. да пофигу им, пофигу. не заметишь ты разницы — разве что если твоя программа два часа ничем другим не занимается, кроме как усердно копирует стомегабайтную строку. > Большее > число явно доступных регистров позволяет меньше лазить в память при вычислениях, > и оперировать бОльшими блоками, что позитивно влияет на кеширование. ровно в том случае, когда ты упорно оптимизируешь свою числодробилку руками. во всех остальных опять пофигу. а ещё я тебе скажу, что чтение/запись в небольшой регион памяти (как и происходит, когда регистров не хватает) очень дешёвое нынче. да и компилятор делает неплохую работу, чтобы это оптимизировать. >>> И если 64-битному процу это 1 операция, на 32-битном это выливается >> …в ту же одну операцию на том же ALU > Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно > оптимально в условиях конвееризации. и всё это по-прежнему нифига не заметно. не надо мне доказывать, что много регистров — хорошо: я это и так знаю. однако на практике разница в скорости между x86 и x86_64 на десктопе не заметна. а gcc у меня большой проект ещё и медленней собирал, зараза (подозреваю, что у него как раз немножко кончилась RAM).
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	115. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 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.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	118. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 28-Ноя-13, 08:00
	> Вообще-то в режиме x86–64 и SSE-регистров поболе. ссе — вовсе не панацея для всех случаев. но да, возможно. >> да пофигу им, пофигу. не заметишь ты разницы > Даже на банальном веб-сервере разница есть. Там как раз в основном программы > и занимаются тем, что тасуют строки… значит, говнокодеры писали. не надо в веб-серверах постоянно строки тасовать. > А вот если кодированием видео заняться — тут уже разница вылезет. я где-то писал, что ежедневно видео кодирую? это *не десктопная* задача. а я вёл речь про десктопы. ну, вот мой, например, где чаще всего запускается gcc. и нет, я пробовал: никакого мегавыигрыша переход на 64-битную систему мне не дал. > Когда что-то на сервере ворочается — заметно. мне в каждом посте после каждого слова в скобках писать «десктоп»? я *не вёл речи* про специализированные задачи изначально. ну и да, традиционно: ламп говно. очень сильно — из-за последей «п». всё остальное поскипал, потому что там после каждого слова надо было скобочки с «десктоп» вписывать.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	120. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Ноя-13, 20:12
	>> Вообще-то в режиме x86–64 и SSE-регистров поболе. > ссе — вовсе не панацея для всех случаев. но да, возможно. Ну какбэ вместо команд FPU GCC для float уже давно юзается SSE. >> Когда что-то на сервере ворочается — заметно. > мне в каждом посте после каждого слова в скобках писать «десктоп»? Да. Потому что десктопное применение Linux - это очень узкая ниша...
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	122. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 29-Ноя-13, 03:00
	>>> Когда что-то на сервере ворочается — заметно. >> мне в каждом посте после каждого слова в скобках писать «десктоп»? > Да. Потому что десктопное применение Linux — это очень узкая ниша… ну (десктоп), извини (десктоп), я (десктоп) думал (десктоп), что (десктоп) простые (десктоп) вещи (десктоп) очевидны (десктоп).
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	124. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok) on 29-Ноя-13, 07:34
	А в целом идея неплоха, скобочки с десктопом несколько освежают текст. Стоит продолжать. Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером ты просто не заметишь разницы между x86-32 и x86-64. В случае видео (не важно - проигрывания, кодирования, с участием аппаратной части для (де)кодера или без) - уже косвенно заметишь эти самые 5-15% разницы, хотя бы через температуру CPU при проигрывании и время работы при кодировании. В офисном пакете - вряд ли заметишь. Но легко заметишь при обработке изображений - inner loop фильтров неплохо оптимизируются числом и жирностью регистров.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	126. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 29-Ноя-13, 10:26
	> Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером > ты просто не заметишь разницы между x86–32 и x86–64. лично на своём — замечу: резко прекратит работать весь самосборный софт. вот я всё бросил и побежал пересобирать кучу пакетов, да. вариант «да поставь ещё один дистрибутив, хитро замаскированый словом multilib» — не предлагать.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	103. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 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 еще как-то влияет.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	109. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 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-битные программы как-то быстрее получаются > обычно. см. выше.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	65. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 19:52
	> 32-битный софт остаётся 32-битным. Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. И, кстати, разница за счет размеров указателей и префиксов команд не такая уж и большая как может показаться - как правило здорово меньше чем в 2 раза.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	83. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:10
	>> 32-битный софт остаётся 32-битным. > Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. всё бросил и побежал пересобирать весь софт, который я до этого под 32 собирал, угу. чтобы получить… а чтобы ничего в итоге не получить такого, ради чего стоило бы заниматься подобной фигнёй. > кстати, разница за счет размеров указателей и префиксов команд не такая > уж и большая как может показаться — как правило здорово меньше > чем в 2 раза. я уже писал про кэш процессора, который засирается быстрее. потому что не только указатели, но и инты часто в 64 превращают. и структуры больше занимают. а если не превращают, и продолжают использовать 32-битные инты — то тем более: нафига?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	104. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 28-Ноя-13, 00:21
	> получить такого, ради чего стоило бы заниматься подобной фигнёй. У, да ты походу весьма заржавелый типец. > только указатели, но и инты часто в 64 превращают. и структуры > больше занимают. а если не превращают, и продолжают использовать 32-битные инты > — то тем более: нафига? Ну да, по такой логике всем должно хватать 8-битных процессоров. Хотя это слишком жирно, хватит и 4-битного 4004, пожалуй. Зато сэкономим на всем чем только можно.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	110. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 28-Ноя-13, 01:46
	>> получить такого, ради чего стоило бы заниматься подобной фигнёй. > У, да ты походу весьма заржавелый типец. да: я очень не люблю делать что-либо только потому, что нынче это модно. > Ну да, по такой логике всем должно хватать 8-битных процессоров. нет. у тебя проблемы с логикой.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	34. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от d (??) on 26-Ноя-13, 09:17
	ну если 10% для Вас не разница ...
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	35. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 26-Ноя-13, 09:34
	> ну если 10% для Вас не разница … во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое место» — это в большинстве случаев не процессор. и от того, что процессор будет на 10% (положим) процентов быстрее ничего не делать, пока ожидает i/o, скорость нифига не увеличится. доступно, нет?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	58. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:40
	> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. Оттуда что 1) Нет постоянной перегрузки полутора куцых регистров. 2) Сами регистры 64-битные и в более вменяемом количестве. > а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое > место» — это в большинстве случаев не процессор. А вот это уже когда как. > пока ожидает i/o Капитан намекает что оперативка - она, зараза, быстрая. При большой оперативе можно получить весьма ширный кжш. Особенно здорово в паре с SSD под системный диск. В системе все работает со скоростью выстрела из пушки. Да, наконец то я дожил до момента когда писюк может работать не хуже чем мой первый компьютер (где операционка подпертая RAM-диском ребутилась за ~пяток секунд, запускала программы с рамдиска мгновенно и прочая).
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	84. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:14
	>> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. > Оттуда что > 1) Нет постоянной перегрузки полутора куцых регистров. > 2) Сами регистры 64-битные и в более вменяемом количестве. а почему не 146%? потолки низкие, с другого потолка другие проценты бы взяли? >> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое >> место» — это в большинстве случаев не процессор. > А вот это уже когда как. лично у меня именно так. >> пока ожидает i/o > Капитан намекает что оперативка — она, зараза, быстрая. При большой оперативе можно > получить весьма ширный кжш. всё бросил, побежал ставить 100500 гигов RAM. > SSD не интересует. > В системе все работает со скоростью выстрела из пушки. если запускаешь две с половиной программы, угу. так у меня не хуже, они всё равно в кэш попадают. нет, я не против SSD как такового. но у меня его нет, и покупать его я не собираюсь.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	46. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 15:08
	> ну если 10% для Вас не разница ... «Скорость — это не главное»™
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	49. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от d (??) on 26-Ноя-13, 16:06
	правильно не главное главное стабильность так вот разработчики сейчас а первую очередь обращают внимание на x64 так что он и постабильнее будет
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	51. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:18
	Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 лет не исполнилось, место на помойке.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	63. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-13, 19:09
	Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	74. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 21:44
	>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. вообще-то это i686
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	75. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok) on 26-Ноя-13, 22:57
	>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. > вообще-то это i686 Кстате (sic!) да, как раз P-Pro и ознаменовал конец эпохи "чистых" i386, и переход на RISC с трансляцией. Хотя попытки были и до него, то ли у Cyrix, то ли у NexGen, если память не изменяет.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	76. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok) on 27-Ноя-13, 00:34
	>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. > вообще-то это i686 Если чо, то i386 - нет такой архитектуры, есть x86.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	90. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok) on 27-Ноя-13, 07:24
	Под "архитектурой i386" понимается конкретный набор расширенных команд i386, модель использования регистров, организацию памяти, форматы системных таблиц для CPU и т.д. Короче говоря - именно то, что и является архитектурой для софта. Между i386 и i286 произошли очень существенные изменения. В пределах "единой" архитектуры x86, угу. Далее кое-что весомое случилось между Pentium (i586) и Pentium-Pro (i686), тоже выделилось в отдельную архитектуру. Далее - случилась AMD64 (x86-64), которая тоже "типа" архитектура. И всё это - снова в пределах x86.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	94. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok) on 27-Ноя-13, 15:48
	Это у них называется поколения, все изменения происходят внутри, без изменения API.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	102. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok) on 27-Ноя-13, 22:03
	> Это у них называется поколения, все изменения происходят внутри, без изменения API. Это у вас оно называется поколения, а у разработчиков оно ныне называется architecture (i386, i686, AMD64).
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	68. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от AlexAT (ok) on 26-Ноя-13, 20:33
	> Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная > временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 > лет не исполнилось, место на помойке. С разморозкой. i386 в новых ядрах уже убили, осталась i686. И ту скоро выпилят за ненадобностью. Мейнстрим уже давно x86-64, а для особых любителей извращений останется x86-64/x32. P.S. Скоро - это лет 10+-5.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	72. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 21:40
	>мне точно не надо — два установленых дистрибутива. Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	73. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 21:40
	или только 64битное ПО
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	85. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:17
	>>мне точно не надо — два установленых дистрибутива. > Тогда используй нормальный дистрибутив с multilib и не ставь два сразу. если вдруг до тебя не доходит, то miltilib — это и есть «два дистрибутива».
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

32. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+3 +/–
Сообщение от EuPhobos (ok) on 26-Ноя-13, 08:57
<игромания> Теперь можно будет сохраняться в играх, в которых не предусмотрены сохранения ;) </игромания>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от bobr on 26-Ноя-13, 17:01
	Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных девяти игроков (-: А вернувшись с пар/уроков доиграть.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	52. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:22
	> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных > девяти игроков (-: А вернувшись с пар/уроков доиграть. Это уже нужно делать синхронизацию с аппаратными криокамерами :-)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	60. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от Аноним (??) on 26-Ноя-13, 17:42
	> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных > девяти игроков (-: А вернувшись с пар/уроков доиграть. Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер. Иначе они заметят что тут что-то не так.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	71. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от AlexAT (ok) on 26-Ноя-13, 21:31
	> Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер. > Иначе они заметят что тут что-то не так. А почему бы нет? Причем ведь прокатит. 1. Вешаем на сервер хитрый апп, раздающий специфичным клиентам команду на заморозку, синхронную, и замораживающий сам сервер. На клиенты вешаем "ответный" апп, принимающий команду и запускающий заморозку. В стоп-фазу приложения выйдут почти синхронно у всех игроков и на сервере, ага. TCP-коннекты также успешно замораживаются, а с UDP там вообще без бубликов в этом плане. 2. Потом аналогично когда все собрались, апп выдает команду на разморозку, сервер и клиенты размораживаются в стоп-фазу (без выполнения), и далее апп дает команду на старт. Коннекты тоже разморозились, аппы стартуют у всех одновременно, и все благополучно продолжают игру - ну, с небольшим лагом на несколько секунд, из-за слегка разъехавшихся таймеров. Главное, чтобы IP за это время не сменились xD Очень даже для случаев, когда нативно сейв сетевой игры не поддерживается :) Что до того, что "заметят" - коннекты не упадут, а с небольшого лага и разъезжания таймеров большинство игрушек восстанавливаться давно умеет.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	86. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok) on 27-Ноя-13, 01:20
	дима завалишин оргазмирует в восторге.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	88. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
	Сообщение от pavlinux (ok) on 27-Ноя-13, 05:46
	Ты запусти сначала эту хрень, и уморозь хотя бы cron иль atd ... размечтались тут :D
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	93. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
	Сообщение от bobr on 27-Ноя-13, 13:10
	То, что вы тут пытаетесь описать ничем по эффекту не отличается от обычной паузы, которая предусмотрена игрушкой. Для этого не нужна заморозка процессов сервера. Мой же пост выше был просто саркастическим ответом на высказывание о сохранении в играх, в которых это не предусмотренно. Тут более даже уместен пост об аппаратных криокамерах.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	95. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от AlexAT (ok) on 27-Ноя-13, 18:26
	А ресурсы системы (память, в частности) во время паузы освобождаются? Нет? То-то.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	66. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
	Сообщение от Аноним (??) on 26-Ноя-13, 20:03
	Или возобновить работу упавшего сервера ТФ2… оч. жду когда можно будет попробовать эту фичу
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

69. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от Аноним (??) on 26-Ноя-13, 21:10
А это случайно не то же самое, что пытается сделать Дмитрий Завалишин? Персистентность и так далее...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

87. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от pavlinux (ok) on 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. Да, ладно?!   [сообщение отредактировано модератором]
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

89. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от pavlinux (ok) on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	128. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от dr (??) on 06-Дек-13, 11:36
	Да с номером версии 1.0 - это они погорячились. Я тоже не осилил задампить/заресторить хоть один полезный процесс. Пршлось писать спец. демон, который ничего не умеет, кроме как писать в лог сообщения. Слава разрабам, что хоть на нём тулза отработала! Посмотрим на динамику развития проекта, ведь идея-то неплохая) Зато у каого есть желание поконтрибутить - простор невероятный.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	129. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	+/–
	Сообщение от avagin on 10-Дек-13, 11:11
	Графические приложения дампить не умеем на сайте явно написано. Первоочередная цель миграция и чекпоинтинг контейнеров. Если есть кто-то готовый заняться, you are welcome. С java-ой вылетело, потому что shmem удален и такой случай поддерживается только при дампе ipcns. Запустите свое приложение unshare -i -- CMD C named скорей всего проблема в том, что приложение постопано SIGTSTP, который тоже пока не поддерживается. ps: pgrep использовать в данном случае не уместно, т к он может выдать больше одного значения.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

127. "Выпуск CRIU 1.0, системы для заморозки и восстановления сост..."	–1 +/–
Сообщение от lucentcode (ok) on 29-Ноя-13, 19:47
Интересный проект.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема