Представлен (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
Новость: https://www.opennet.ru/opennews/art.shtml?num=38519
А кто может подсказать, как происходить переброс TСP соединения?
Надо полагать, вместе с сетевым стеком контейнера, включая IP-адрес.
https://www.opennet.ru/opennews/art.shtml?num=34387 Релиз ядра Linux 3.5
Поддержка интерфейса для восстановления TCP-соединений, позволяющего зафиксировать контрольную точку с которой можно возобновить остановленное соединение. Наиболее интересным практическим применением указанной функции является возможность предотвратить разрыв соединений в результате перезагрузки системы или перемещения серверного процесса на другой хост. Например, в системах виртуализации упрощается решение таких задач как миграция работающих процессов с одного сервера на другой, незаметно для приложения на другой стороне соединения;
IP тот же остается или можно поменять на другой?
> IP тот же остается или можно поменять на другой?По всей видимости, тот же. Он привязан к виртуальному стеку контейнера (netns) и передается вместе с ним.
> А кто может подсказать, как происходить переброс TСP соединения?Ну вот так:
- Траффик заворачивается на другую железяку.
- Ядру хинтят состояние TCP стека.Ничему такому особо не противоречит если состояние сетевого стека восстановить.
> Ну вот так:
> - Траффик заворачивается на другую железяку.
> - Ядру хинтят состояние TCP стека.Узнаю нашего старого доброго user294 - ни слова по делу, зато рунглиш из всех щелей :)
кого-то таки достал полурабочий cryopid? похвально. и вообще, давно хочу такую штуку, чтобы полноценно работала.
Надо ещё на systemd-logind протестировать его.
> Надо ещё на systemd-logind протестировать его.зачем? поцтеринг вам напишет свою реализацию. кривую, косую, хреново документированую и интегрированую в системды по самое дальше некуда.
Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.
> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.а-а-а. тогда да, одобряю.
> Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона.Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого проблемы сваливаешь на Поттеринга.
> Так SIGSTOP же есть. Стопаешь, значит, systemd-logind, и все появившиеся после этого
> проблемы сваливаешь на Поттеринга.Еще можно нажать Alt+SysRq+B и потом придти скандалить в LKML "ваш линyпс убил все мои данные".
Вот только Линус не Леннарт, может и наxер послать.
кривые только руки твои, сачок )
коль не осилил, так на себя пенять надо
вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас
> вангую пердеж в лужу про ненужность, user296-стайл, ариса, фасВообще-то 294-й достаточно нормально относится к идее чего-то типа systemd. По крайней мере upstart мне пришелся вполне по вкусу и мне с ним как-то сильно проще получается добавлять новые кастомные демоны в систему. Ну и systemd освою, если из него выбьют дурь и так получится что ему суждено стать новым иниицализатором в большинстве пингвинов. А пока пусть на кошках^W федористах и арчеводах тренируются и обезглючивают.
> По крайней мере upstart мне пришелся вполне по вкусуВпервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги при малейшей ошибке в синтаксисе.
> Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее конфиги
> при малейшей ошибке в синтаксисе.Ну я как бы не возражаю что оно должно бы чертыхнуться куда-нибудь в лог. Багу своему гарри поттеру вы написали уже? Или как обычно? И если уж мы про ошибки - вот уж знаете ли, в классическом ините ловить ошибки форменный головняк. Там вообще никакого логинга нет, так что что и почему обломалось - как хочешь так и узнавай. Сам логгинг допишешь, фигли.
> кривые только руки твои, сачок )
> коль не осилил, так на себя пенять надоТакие, как он, всегда видят корень своих проблем в окружающих. И просто неспособны осознать факт кривизны своих рук. Что ариса, что поттеринг, одна фигня.
> Надо ещё на systemd-logind протестировать его.Скорее наоборот, это в systemd будут тестировать фичи CRIU.
Даже на офсайте сходу не удалось понять, с какой версии ядра все необходимое в состав ядра включено?
3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
> 3.11, в которое включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....это необязательная фича, вообще-то.
p.s. насколько я понял из текста на офсайте, на практике не проверял.
> Даже на офсайте сходу не удалось понять, с какой версии ядра все
> необходимое в состав ядра включено?судя как раз по офсайту — с 3.10 должно работать. проверить, правда, не могу — у меня некоторые нужные фичи выключены. а перезагружаться лень.
тьфу, распронаедрит налево! пересобирал ядро, перезагружался — а эта бесполезная фигня только для x86_64.ненужно.
> x86 ненужнопрофиксил
> профиксилхерово и неверно.
>> профиксил
> херово и неверно.Все правильно он починил. Ни замшелое гoвно, ни его адепты в этом мире никому не нужны.
а обосновать сможешь?
> а обосновать сможешь?тысячу тысяч раз уже говорено.
все правильно. Устаревшие архитектуры ненужны.
> все правильно. Устаревшие архитектуры ненужны.я согласен, x86 и x86_64 обе — устарели и нафиг не нужны.
>только для x86_64Отлично, я еще 8 лет назад перешел исключительно на 64 бита
> Отлично, я еще 8 лет назад перешел исключительно на 64 битамне очень важно было это узнать, спасибо.
Так же, как нам - что Вам "не нужно".
Любка, ты чтоль?
> мне очень важно было это узнать, спасибо.А нам очень интересно было прочитать про ваши половые трудности с 64-битными системами.
Продолжайте держать нас в курсе.
> Отлично, я еще 8 лет назад перешел исключительно на 64 битаДа уже несколько лет как большая часть x86 железа ушла на свалки. Так что на 32 битах нынче сидят разве что виндyзятники и фимозники в терминальной стадии.
> Да уже несколько лет как большая часть x86 железа ушла на свалки.Ну так 64-битные процессоры появились чуть ли не десятилетие назад. А при современных ценах нагревать себя на оперативку - просто глупо. Даже если программам столько нафиг не упало, большой дисковый буфер сделает работу с машиной не в пример приятнее. Когда все оглавление всех дисков висит в оперативе и никогда не выжимается, а все рабочие наборы целиком прокешированы - работать с машиной становится заметно приятнее. Просто потому что практически все операции происходят как выстрел из пушки.
о, виндузятник пришёл. это у вас в винде 32-битная икспишечка не может в больше четырёх гигов памяти. 32–битный линукс вполне может.
ХР SP1 может адресовать до 16GB из 32 возможных в 36-битном адресном пространстве.
Только не спрашивайте, куда дел 36-й бит и еще 32GB.Патч весьма простой, помогает и следующим сервиспакам
ссылку на то, где m$ его раздаёт?
> о, виндyзятник пришёл.Аж 294 раза. По что ругаешься, Кэп? (форум считает данное слово бранным, что конечно правильно, но усложняет ответ).
> это у вас в винде 32-битная икспишечка не может
> в больше четырёх гигов памяти. 32–битный линукс вполне может.Все несколько проще. Раскуривать сорцычтобы самому найти ответ мне было дико обломно: мне и так есть чем заняться и экскурсия в управление кэшом на такую глубину без причины меня не соблазнила. А конфигов с 32-битным процом где более 4Гб памяти у меня элементарно нет, т.к. я не сторонник извращений типа PAE и прочая и полагаю что если в системе есть более 4 гигз памяти то и 64 бита на указатель можно выкроить как-нибудь и не развалиться при этом. Система которая не может напрямую адресовать свою память без извращений - дрянь. Спасибо, всякие схемы банкинга и прочие костыли мне уже давно сидят в печенках. Да, я люблю линейные адресные пространства, где можно просто получить то что хотелось а не заниматься фигурным костылестроением. Надо же, какой я негодяй :).
> По что ругаешься, Кэп?я не ругался, я обзывался. как будто я тебя не узнал.
> форум считает данное слово бранным
«почто»?
про всё остальное. была же задумка x32 (или как там её) — издохла, что ли? это как раз здравая идея же: профиты в виде расширеного регистрового пространства и отсутствие дебилизма с указателями.а ещё ваша 48-битовая фигня еле-еле поместилась в double nan. с ужасом жду, когда очередной модный-молодёжный скажет, что 48 бит для указателя мало, придумает очередную дикую схему адресации и указатели перестанут в double nan влазить.
> про всё остальное. была же задумка x32 (или как там её) —
> издохла, что ли? это как раз здравая идея же: профиты в
> виде расширеного регистрового пространства и отсутствие дебилизма с указателями.Нет, не "издохла". Вот только она касается только юзерспейса - ядро там всё равно используется стандартное x86_64, а у тебя на него аллергия:)
> Нет, не «издохла». Вот только она касается только юзерспейса - ядро там
> всё равно используется стандартное x86_64, а у тебя на него аллергия:)у меня на него аллергия, когда оно без толку суётся. в x32 я толк вижу — в отличие от 64-битного ядра с 32-битным остальным или полной 64-битности.
p.s. сайт у них ужасен, у меня глаза болят и щека дёргается.
> про всё остальное. была же задумка x32 (или как там её) —
> издохла, что ли? это как раз здравая идея же: профиты в
> виде расширеного регистрового пространства и отсутствие дебилизма с указателями.Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти.
> Не совсем. Там есть свои накладные расходы на невыровненные обращения к памяти.точно такие же, как и у других режимов, насколько я помню.
А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной версии которого не существует? :-)
> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной
> версии которого не существует? :-)а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? а, и ещё чтобы multilib держать, а то одной копии дистрибутива мне мало?
>> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной
>> версии которого не существует? :-)
> а зачем мне 64-битная система, если у меня нет софта, которому требуется
> больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были?
> а, и ещё чтобы multilib держать, а то одной копии дистрибутива
> мне мало?А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?
> А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?не знаю, у меня ядро 32-битное, так что проверить не могу.
> не знаю, у меня ядро 32-битное, так что проверить не могу.А у тебя и пямяти меньше 4 гигз? Или мсье нравятся феерические костыли типа PAE? И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?
> И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?«Дисковый кэш — кривая хрень, которой пользуются только законченные идиoты» ©arisu
>> не знаю, у меня ядро 32-битное, так что проверить не могу.
> А у тебя и пямяти меньше 4 гигз?а какое отношение?
> Или мсье нравятся феерические костыли типа PAE?
а мне без разницы, я это руками не делаю.
> И кстати может ли 32-битное ядро скажем дисковый
> кэш скажем в 8Гб сделать?вот этого не помню. но мне таки без разницы: у меня 4 гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не бегу докупать памяти «просто чтобы было побольше».
> а мне без разницы, я это руками не делаю.Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким костылем.
> вот этого не помню. но мне таки без разницы: у меня 4
> гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не
> бегу докупать памяти «просто чтобы было побольше».Ну а я не против запустить пару виртуалок и загрузить все оглавление дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM drive все-таки.
>> а мне без разницы, я это руками не делаю.
> Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким
> костылем.тогда тебе исключительно в real mode. потому что в protected ты вообще адресуешь некую виртуальную сущность.
> Ну а я не против запустить пару виртуалок и загрузить все оглавление
> дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM
> drive все-таки.да на здоровье — я тебе запрещаю, что ли? как я уже говорил — x32 было бы хорошим вариантом. но увы — модные-молодёжные не привыкли экономить ресурсы.
> тогда тебе исключительно в real mode. потому что в protected ты вообще
> адресуешь некую виртуальную сущность.Дело не в этом. Дело в костылях в виде сегментов или оконной загрузки страниц. На данный момент это именно костыль, поскольку основное API ОС расчитывает на линейную адресацию.
В long mode, тьфу-тьфу, "виртуальную сущность" упростили именно до линейной адресации, без сегментации. Вполне себе хватает и того, что страницы можно подключать в произвольном порядке. Это, кстати, на производительности тоже сказывается.
> Дело не в этом. Дело в костылях в виде сегментов или оконной
> загрузки страниц.вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? нет, не видишь.
виртуальная память — костыль в любом случае. одним больше, одним меньше — уже без разницы.
> вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь?
> нет, не видишь.Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86-32. Правда, я этого в рабочем режиме не сделаю никогда, потому что из ума еще не выжил :)
> Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86–32.это, без сомнения, рутинная домашняя задача. все так делают, каждый день.
> это, без сомнения, рутинная домашняя задача. все так делают, каждый день.Задача-то не домашняя, но вот работает она каждый день... И вполне себе рутинная, кстати :)
я (десктоп) писал (десктоп) о (десктоп) несколько (десктоп) других (десктоп) областях (десктоп).
>>> а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайтx64 - это не только снятие лимита в 3 гигабайта. Это еще набор из 8 дополнительных доступных софту РОН и регистров SSE, увеличенная ширина регистров по умолчанию и несколько прочих плюшек, типа возможности работать с оффсетами относительно RIP.
ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при создании кода — мне пофигу. вот что мне точно не надо — два установленых дистрибутива.
> ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при
> создании кода — мне пофигу. вот что мне точно не надо
> — два установленых дистрибутива.Достаточно добавить 64-битное ядро
> Достаточно добавить 64-битное ядродля чего? 32-битный софт остаётся 32-битным.
>> Достаточно добавить 64-битное ядро
> для чего? 32-битный софт остаётся 32-битным.Например, для CRIU. Да и "32-битного софта" можно запустить больше.
> Например, для CRIU.например, само ядро больше памяти слопает.
> Да и «32-битного софта» можно запустить больше.
с чего бы вдруг? 32-битное ядро ни разу не ограничено четырьмя гб памяти. а если в системе закончились пиды — то тут не ядро менять надо, а прокладку.
> например, само ядро больше памяти слопает.На машинах где 64 бита имеют смысл это как правило не принципиально. Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь уж существенно. И вообще, пристрелив какую-нить дрянь на питоне или чем там еще - можно сразу в 20 раз больше памяти отыграть, если уж так хочется.
Еще ядро на машинах с большой памятью больше на служебные нужды забирает. Не без причин полагая что раз памяти много то и жабой давиться себе в ущерю ни к чему. Вполне логично.
А еще в 64-битном режиме 64-разрядная математика работает быстрее. А поскольку например лимит в 4 гига при работе с файлами нас не устроит - 64-битная математика нынче в каждом закоулке. И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. А на х86 у которого регистров полторы штуки это выливается в кошмар. А в 64-битном режиме есть нормальный набор регистров и прочая и это даже уже похоже на нормальный процессор немного, а не кусок шита из ранних 80-х.
> И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку.Как будто это что-то плохое.
> Как будто это что-то плохое.Вообще-то плохое, да. На одну и ту же операцию потратится намного больше тактов проца при прочих равных. В общем использовать обрубок оставленный чисто для совместимости при том что на том же кристалле более нормальное нечто собрано, с более нормальной системой команд - дурь несусветная.
использовать 64-битные указатели для адресации пары гигов памяти — вот это и есть дурь несусветная.
> использовать 64-битные указатели для адресации пары гигов памяти — вот это и
> есть дурь несусветная.Да. Но я не вижу почему мне должно быть нельзя юзать всю доступную память из 1 процесса, опять же. Какое-то очередное "640К хватит всем". В то что 2^64 хватит на ближайшее время - я еще готов поверить даже.
> Да. Но я не вижу почему мне должно быть нельзя юзать всю
> доступную память из 1 процесса, опять же.потому что ядро тебе не разрешит. даже 64-битное.
> всем». В то что 2^64 хватит на ближайшее время — я
> еще готов поверить даже.2^48. остальные биты вашего огромного указателя тупо ничего не делают и копируются из 47-го.
> На машинах где 64 бита имеют смысл это как правило не принципиально.
> Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь
> уж существенно.зато кэш процессора — существенно. указателей в ядре много, все указатели в два раза больше.
> И вообще, пристрелив какую-нить дрянь на питоне
чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное.
> Еще ядро на машинах с большой памятью больше на служебные нужды забирает.
почти два гигабайта ему вполне достаточно.
> А еще в 64-битном режиме 64-разрядная математика работает быстрее.
через libastral, ALU боги послали?
> А поскольку например лимит в 4 гига при работе с файлами нас не устроит
> — 64-битная математика нынче в каждом закоулке.это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления — они мегатормозят.
> И если 64-битному процу это 1 операция, на 32-битном это выливается
…в ту же одну операцию на том же ALU. а данные для неё благодаря спекулятивке и параллельному исполнению уже давно в камне.
> на х86 у которого регистров полторы штуки
ну и фиг с ним. компилятор разберётся. а обращение к памяти для тасования регистров всё равно закэшировано.
> зато кэш процессора — существенно. указателей в ядре много, все указатели в
> два раза больше.Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение длины регистров - неплохой шаг.
>> А еще в 64-битном режиме 64-разрядная математика работает быстрее.
> через libastral, ALU боги послали?Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; в) бОльший размер регистров - не забываем, что i?86 ядро ничего о расширенном наборе явно доступных регистров и их увеличенной длине не знает. Если уж хочется сократить объем памяти под указатели - есть x86-64/x32, хотя пользы от него кот наплакал.
>> — 64-битная математика нынче в каждом закоулке.
> это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления
> — они мегатормозят.Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее число явно доступных регистров позволяет меньше лазить в память при вычислениях, и оперировать бОльшими блоками, что позитивно влияет на кеширование.
>> И если 64-битному процу это 1 операция, на 32-битном это выливается
> …в ту же одну операцию на том же ALUНи разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно оптимально в условиях конвееризации.
> Кэши тоже растути поэтому надо сильней забивать их мусором!
> По вычислениям остаётся только распараллеливание — и увеличение
> длины регистров — неплохой шаг.честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. а плавающим числам и вовсе плевать на целочисленые регистры, у них своя подсистема.
> Если уж хочется сократить объем памяти под указатели — есть
> x86–64/x32, хотя пользы от него кот наплакал.да нет его, увы. пересобирать руками всю систему и скакать по граблям я как-то не особо готов.
> Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8.
да пофигу им, пофигу. не заметишь ты разницы — разве что если твоя программа два часа ничем другим не занимается, кроме как усердно копирует стомегабайтную строку.
> Большее
> число явно доступных регистров позволяет меньше лазить в память при вычислениях,
> и оперировать бОльшими блоками, что позитивно влияет на кеширование.ровно в том случае, когда ты упорно оптимизируешь свою числодробилку руками. во всех остальных опять пофигу. а ещё я тебе скажу, что чтение/запись в небольшой регион памяти (как и происходит, когда регистров не хватает) очень дешёвое нынче. да и компилятор делает неплохую работу, чтобы это оптимизировать.
>>> И если 64-битному процу это 1 операция, на 32-битном это выливается
>> …в ту же одну операцию на том же ALU
> Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно
> оптимально в условиях конвееризации.и всё это по-прежнему нифига не заметно.
не надо мне доказывать, что много регистров — хорошо: я это и так знаю. однако на практике разница в скорости между x86 и x86_64 на десктопе не заметна. а gcc у меня большой проект ещё и медленней собирал, зараза (подозреваю, что у него как раз немножко кончилась RAM).
> честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений.
> а плавающим числам и вовсе плевать на целочисленые регистры, у них
> своя подсистема.Вообще-то в режиме 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.
> Вообще-то в режиме x86–64 и SSE-регистров поболе.ссе — вовсе не панацея для всех случаев. но да, возможно.
>> да пофигу им, пофигу. не заметишь ты разницы
> Даже на банальном веб-сервере разница есть. Там как раз в основном программы
> и занимаются тем, что тасуют строки…значит, говнокодеры писали. не надо в веб-серверах постоянно строки тасовать.
> А вот если кодированием видео заняться — тут уже разница вылезет.
я где-то писал, что ежедневно видео кодирую? это *не десктопная* задача. а я вёл речь про десктопы. ну, вот мой, например, где чаще всего запускается gcc. и нет, я пробовал: никакого мегавыигрыша переход на 64-битную систему мне не дал.
> Когда что-то на сервере ворочается — заметно.
мне в каждом посте после каждого слова в скобках писать «десктоп»? я *не вёл речи* про специализированные задачи изначально.
ну и да, традиционно: ламп говно. очень сильно — из-за последей «п».
всё остальное поскипал, потому что там после каждого слова надо было скобочки с «десктоп» вписывать.
>> Вообще-то в режиме x86–64 и SSE-регистров поболе.
> ссе — вовсе не панацея для всех случаев. но да, возможно.Ну какбэ вместо команд FPU GCC для float уже давно юзается SSE.
>> Когда что-то на сервере ворочается — заметно.
> мне в каждом посте после каждого слова в скобках писать «десктоп»?Да. Потому что десктопное применение Linux - это очень узкая ниша...
>>> Когда что-то на сервере ворочается — заметно.
>> мне в каждом посте после каждого слова в скобках писать «десктоп»?
> Да. Потому что десктопное применение Linux — это очень узкая ниша…ну (десктоп), извини (десктоп), я (десктоп) думал (десктоп), что (десктоп) простые (десктоп) вещи (десктоп) очевидны (десктоп).
А в целом идея неплоха, скобочки с десктопом несколько освежают текст. Стоит продолжать.Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером ты просто не заметишь разницы между x86-32 и x86-64. В случае видео (не важно - проигрывания, кодирования, с участием аппаратной части для (де)кодера или без) - уже косвенно заметишь эти самые 5-15% разницы, хотя бы через температуру CPU при проигрывании и время работы при кодировании. В офисном пакете - вряд ли заметишь. Но легко заметишь при обработке изображений - inner loop фильтров неплохо оптимизируются числом и жирностью регистров.
> Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером
> ты просто не заметишь разницы между x86–32 и x86–64.лично на своём — замечу: резко прекратит работать весь самосборный софт. вот я всё бросил и побежал пересобирать кучу пакетов, да.
вариант «да поставь ещё один дистрибутив, хитро замаскированый словом multilib» — не предлагать.
> два раза больше.У современных процессоров кэши тоже большие. А всякие 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 еще как-то влияет.
> У современных процессоров кэши тоже большие.см. #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-битные программы как-то быстрее получаются
> обычно.см. выше.
> 32-битный софт остаётся 32-битным.Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. И, кстати, разница за счет размеров указателей и префиксов команд не такая уж и большая как может показаться - как правило здорово меньше чем в 2 раза.
>> 32-битный софт остаётся 32-битным.
> Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли.всё бросил и побежал пересобирать весь софт, который я до этого под 32 собирал, угу. чтобы получить… а чтобы ничего в итоге не получить такого, ради чего стоило бы заниматься подобной фигнёй.
> кстати, разница за счет размеров указателей и префиксов команд не такая
> уж и большая как может показаться — как правило здорово меньше
> чем в 2 раза.я уже писал про кэш процессора, который засирается быстрее. потому что не только указатели, но и инты часто в 64 превращают. и структуры больше занимают. а если не превращают, и продолжают использовать 32-битные инты — то тем более: нафига?
> получить такого, ради чего стоило бы заниматься подобной фигнёй.У, да ты походу весьма заржавелый типец.
> только указатели, но и инты часто в 64 превращают. и структуры
> больше занимают. а если не превращают, и продолжают использовать 32-битные инты
> — то тем более: нафига?Ну да, по такой логике всем должно хватать 8-битных процессоров. Хотя это слишком жирно, хватит и 4-битного 4004, пожалуй. Зато сэкономим на всем чем только можно.
>> получить такого, ради чего стоило бы заниматься подобной фигнёй.
> У, да ты походу весьма заржавелый типец.да: я очень не люблю делать что-либо только потому, что нынче это модно.
> Ну да, по такой логике всем должно хватать 8-битных процессоров.
нет. у тебя проблемы с логикой.
ну если 10% для Вас не разница ...
> ну если 10% для Вас не разница …во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.
а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое место» — это в большинстве случаев не процессор. и от того, что процессор будет на 10% (положим) процентов быстрее ничего не делать, пока ожидает i/o, скорость нифига не увеличится. доступно, нет?
> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.Оттуда что
1) Нет постоянной перегрузки полутора куцых регистров.
2) Сами регистры 64-битные и в более вменяемом количестве.> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое
> место» — это в большинстве случаев не процессор.А вот это уже когда как.
> пока ожидает i/o
Капитан намекает что оперативка - она, зараза, быстрая. При большой оперативе можно получить весьма ширный кжш. Особенно здорово в паре с SSD под системный диск. В системе все работает со скоростью выстрела из пушки. Да, наконец то я дожил до момента когда писюк может работать не хуже чем мой первый компьютер (где операционка подпертая RAM-диском ребутилась за ~пяток секунд, запускала программы с рамдиска мгновенно и прочая).
>> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют.
> Оттуда что
> 1) Нет постоянной перегрузки полутора куцых регистров.
> 2) Сами регистры 64-битные и в более вменяемом количестве.а почему не 146%? потолки низкие, с другого потолка другие проценты бы взяли?
>> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое
>> место» — это в большинстве случаев не процессор.
> А вот это уже когда как.лично у меня именно так.
>> пока ожидает i/o
> Капитан намекает что оперативка — она, зараза, быстрая. При большой оперативе можно
> получить весьма ширный кжш.всё бросил, побежал ставить 100500 гигов RAM.
> SSD
не интересует.
> В системе все работает со скоростью выстрела из пушки.
если запускаешь две с половиной программы, угу. так у меня не хуже, они всё равно в кэш попадают.
нет, я не против SSD как такового. но у меня его нет, и покупать его я не собираюсь.
> ну если 10% для Вас не разница ...«Скорость — это не главное»™
правильно не главное главное стабильность так вот разработчики сейчас а первую очередь обращают внимание на x64 так что он и постабильнее будет
Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 лет не исполнилось, место на помойке.
Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.вообще-то это i686
>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
> вообще-то это i686Кстате (sic!) да, как раз P-Pro и ознаменовал конец эпохи "чистых" i386, и переход на RISC с трансляцией. Хотя попытки были и до него, то ли у Cyrix, то ли у NexGen, если память не изменяет.
>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
> вообще-то это i686Если чо, то i386 - нет такой архитектуры, есть x86.
Под "архитектурой i386" понимается конкретный набор расширенных команд i386, модель использования регистров, организацию памяти, форматы системных таблиц для CPU и т.д. Короче говоря - именно то, что и является архитектурой для софта. Между i386 и i286 произошли очень существенные изменения. В пределах "единой" архитектуры x86, угу.Далее кое-что весомое случилось между Pentium (i586) и Pentium-Pro (i686), тоже выделилось в отдельную архитектуру. Далее - случилась AMD64 (x86-64), которая тоже "типа" архитектура. И всё это - снова в пределах x86.
Это у них называется поколения, все изменения происходят внутри, без изменения API.
> Это у них называется поколения, все изменения происходят внутри, без изменения API.Это у вас оно называется поколения, а у разработчиков оно ныне называется architecture (i386, i686, AMD64).
> Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная
> временем», а всякой новомодной фигне типа x86_64, которой еще даже 30
> лет не исполнилось, место на помойке.С разморозкой. i386 в новых ядрах уже убили, осталась i686. И ту скоро выпилят за ненадобностью. Мейнстрим уже давно x86-64, а для особых любителей извращений останется x86-64/x32.
P.S. Скоро - это лет 10+-5.
>мне точно не надо — два установленых дистрибутива.Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.
или только 64битное ПО
>>мне точно не надо — два установленых дистрибутива.
> Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.если вдруг до тебя не доходит, то miltilib — это и есть «два дистрибутива».
<игромания>
Теперь можно будет сохраняться в играх, в которых не предусмотрены сохранения ;)
</игромания>
Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных девяти игроков (-: А вернувшись с пар/уроков доиграть.
> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных
> девяти игроков (-: А вернувшись с пар/уроков доиграть.Это уже нужно делать синхронизацию с аппаратными криокамерами :-)
> Ага, в ДОТА2. Сохранить дамп памяти, состояние сетевого стека и состояние остальных
> девяти игроков (-: А вернувшись с пар/уроков доиграть.Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер. Иначе они заметят что тут что-то не так.
> Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер.
> Иначе они заметят что тут что-то не так.А почему бы нет? Причем ведь прокатит.
1. Вешаем на сервер хитрый апп, раздающий специфичным клиентам команду на заморозку, синхронную, и замораживающий сам сервер. На клиенты вешаем "ответный" апп, принимающий команду и запускающий заморозку. В стоп-фазу приложения выйдут почти синхронно у всех игроков и на сервере, ага. TCP-коннекты также успешно замораживаются, а с UDP там вообще без бубликов в этом плане.
2. Потом аналогично когда все собрались, апп выдает команду на разморозку, сервер и клиенты размораживаются в стоп-фазу (без выполнения), и далее апп дает команду на старт. Коннекты тоже разморозились, аппы стартуют у всех одновременно, и все благополучно продолжают игру - ну, с небольшим лагом на несколько секунд, из-за слегка разъехавшихся таймеров. Главное, чтобы IP за это время не сменились xD
Очень даже для случаев, когда нативно сейв сетевой игры не поддерживается :)
Что до того, что "заметят" - коннекты не упадут, а с небольшого лага и разъезжания таймеров большинство игрушек восстанавливаться давно умеет.
дима завалишин оргазмирует в восторге.
Ты запусти сначала эту хрень, и уморозь хотя бы cron иль atd ... размечтались тут :D
То, что вы тут пытаетесь описать ничем по эффекту не отличается от обычной паузы, которая предусмотрена игрушкой. Для этого не нужна заморозка процессов сервера. Мой же пост выше был просто саркастическим ответом на высказывание о сохранении в играх, в которых это не предусмотренно. Тут более даже уместен пост об аппаратных криокамерах.
А ресурсы системы (память, в частности) во время паузы освобождаются? Нет? То-то.
Или возобновить работу упавшего сервера ТФ2… оч. жду когда можно будет попробовать эту фичу
А это случайно не то же самое, что пытается сделать Дмитрий Завалишин? Персистентность и так далее...
Они, что издеваются?!!!# 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.shchecking 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.Да, ладно?!
[сообщение отредактировано модератором]
- 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
Да с номером версии 1.0 - это они погорячились. Я тоже не осилил задампить/заресторить хоть один полезный процесс. Пршлось писать спец. демон, который ничего не умеет, кроме как писать в лог сообщения. Слава разрабам, что хоть на нём тулза отработала!
Посмотрим на динамику развития проекта, ведь идея-то неплохая) Зато у каого есть желание поконтрибутить - простор невероятный.
Графические приложения дампить не умеем на сайте явно написано. Первоочередная цель миграция и чекпоинтинг контейнеров. Если есть кто-то готовый заняться, you are welcome.С java-ой вылетело, потому что shmem удален и такой случай поддерживается только при дампе ipcns. Запустите свое приложение unshare -i -- CMD
C named скорей всего проблема в том, что приложение постопано SIGTSTP, который тоже пока не поддерживается.
ps: pgrep использовать в данном случае не уместно, т к он может выдать больше одного значения.
Интересный проект.