Comments 65
да. в arch wiki можно многое почерпнуть само собой. на мой взгляд вся проблема заключается в том, что линукс зачем-то использует swap для нужд хибернейта. и это доставляет много трудностей при длительной работе без перезагрузки. если кто-то умеет отправлять в гибернацию без подключения раздела как swap, то буду рад научиться этому
vm.swappiness = 0?
даже не знаю что поставить во главе ответа под грифом "во-первых" :))
скажу так. обе причины одинаково важны.
начну с первой и самой простой. это просто не сработает :)) да. можно почитать документацию. этот параметр ничего не гарантирует и тем более не отключает своп. запись в своп продолжится
и второе: не слишком ли это круто - отказаться от записи в своп (если я понял вашу идею правильно) только из-за недочёта в дизайне системы? похоже на "лечение симптомов", а не решение проблемы. да ещё и таким радикальным способом, продолжая ухудшать этот самый дизайн
да. можно почитать документацию. этот параметр ничего не гарантирует
At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.
Проще говоря, своп не будет заполняться без крайней необходимости (вероятно, покуда не потребуется kmalloc()). Эффективно, это будет эквивалентно отключению свопа в большинстве ситуаций.
не слишком ли это круто - отказаться от записи в своп
Опять же, зависит от кейса. Например, на домашнем сервере у меня настроена гибернация по истощении UPS'а, а vm.swappiness = 0 и своп пустой даже при возникающих OOM в юзерспейсе (при наличии OOM-killer'а, разумеется).
На ноутбуке поставьте = 1 и радуйтесь жизни. По-моему, это логичный трейд-офф: не хочешь продолбать работу — перед уходом в сон убедись, что у тебя не забит своп. Т.к. мы говорим о GUI, очень полезно вывести его состояние в статусбар DE.
я всё это протестировал много раз. swappiness = 0 далеко не эквивалентно отключению свопа ни в одной из ситуаций. да в общем-то из цитаты вашей это тоже можно прочитать. своп может и не используется на сервере на какой-то узкоспециализированной задаче.. но ноутбуке разработчика с 32 ГБ RAM с активным использованием различного ПО - компиляторов, сборщиков, докера, браузера, почты, нейронок и т.п., избежать попадания памяти в своп - задача неосуществимая. нет такой настройки в линуксе. и даже если поставить 128ГБ оперативки, то всё равно своп будет использоваться.
проверено личным опытом. swappiness=0 работает в течение часа может быть. но в реальной работе оно ничего не даёт - своп в процессе работы заполнится ровно на столько же как и обычно какой swappiness вы не поставите. если мы говорим про лаптоп разработчика.
а во-вторых, как я уже написал в статье, недостаточно просто того, чтобы в свопе было достаточно места для гибернации. нужен непрерывный участок. память как известно фрагментируется (и своп тоже фрагментируется). в таком случае Вам на рабочий стол нужно выводить не только загруженность свопа, но и его карту :)
и как-то это сложно, не находите, и странно. Я заканчиваю работу с лаптопом, просто закрывая крышку. С чего вдруг меня должно интересовать как занят мой своп. И с чего вдруг может появится уверенность (я ведь наверняка знаю что это не так), что ситуация не изменится, когда я отвернусь, и своп вдруг окажется занят больше чем нужно.
И в конце концов, представьте себе как в 2025-ом году вы объясняете это пользователю WIndows или Mac, что перед тем как закрыть крышку ноутбука, им нужно проверить место в свопе.. и если что, то отключить своп и потом снова подключить (это кстати тоже сработает только на пару минут, даже со swappiness=0).
поэтому мой логичный трейд-офф, это кастомный сервис, который делает всю эту работу за меня. вполне несложный. и, кстати говоря, он срабатывает не всегда с первого раза. линуксу хватает считанных долей секунд, чтобы занять место в только что подключенном свопе, даже когда в другом свопе ещё половина свободна (приоритеты можно покрутить, но это тоже не гарант). однако скрипт на таймере, и поэтому ему стабильно таки удаётся погрузить систему в глубокий сон со второго или третьего раза
своп может и не используется на сервере на какой-то узкоспециализированной задаче
Например, на домашнем сервере
Домашний сервер — это куча хлама начиная от почтовика, матрикса, приложений типа Home Assistant, Frigate и подобных в докере и заканчивая игровыми серверами и веб-приложениями. Там явно больше всего происходит, чем на «ноутбуке разработчика» — и с кратно большим аптаймом.
недостаточно просто того, чтобы в свопе было достаточно места для гибернации. нужен непрерывный участок.
Нет. Вы заблуждаетесь. Нужен непрерывный своп (т.е. один файл/раздел достаточного размера, а не сумма нескольких). За фрагментацией следит само ядро, и фрагментация свопа не помешает процессу гибернации.
Я заканчиваю работу с лаптопом, просто закрывая крышку
Я тоже. Но если я знаю, что для меня критически важно что-либо в RAM, я перед этим лишний раз кину взгляд на индикатор в панели, чтобы убедиться, что памяти занято меньше 80% — обычно этого хватает с учётом сжатия при свопе в полтора объёма RAM. Это происходит машинально.
А ещё ровно поэтому существуют режимы гибридного сна и suspend-then-hibernate, которые в любом случае не позволят вам потерять состояние, если батарея доживёт до включения (а в современных ультрабуках с S0iX это десятки часов).
как в 2025-ом году вы объясняете это пользователю WIndows или Mac, что перед тем как закрыть крышку ноутбука, им нужно проверить место в свопе
Во-первых, зачем мне им это объяснять? Ради холивара? Во-вторых, на Windows файл hiberfil.sys всегда занимает место на диске (не неся пользы помимо гибернации) и постоянно растёт (небыстро; читай: не уменьшается сам), я же не готов отдавать объём больше строго фиксированного, предопределённого мной.
Повторю свои же слова, правильно сконфигурированный линукс умеет производить гибернацию в частично занятый своп (этот факт очевиден), а следить за общим (RAM+swap) объёмом занимаемой оперативной памяти — ответственность юзера. Мы есть админы своих систем, без элементарного уровня понимания устройства системы пользоваться линуксом не стоит — это как раз удел винды и мака.
и, кстати говоря, [мой скрипт] срабатывает не всегда с первого раза.
Дело в вашем скрипте и/или конфигурации, а не в линуксе. Никогда не следует вкостыливать кастомные наколеночные скрипты туда, где ответственен функционал системного демона. Линукс на то и опенсорсен, что вы вольны править в вашей системе то, что вам заблагорассудится. Напишите патч для того же systemd — может быть, сообщество оценит и примет. А подобным скриптам место на винде. Я лично для многих вещей модули ядра не ленюсь писать, хотя, наверное, можно было бы обойтись скриптом на питоне (но не нужно).
приоритеты можно покрутить, но это тоже не гарант
Конечно. Если у вас настолько неконтролируемо забита память, что вам не хватает объёма её и собственноручно настроенного свопа — увеличивайте своп, не пишите скрипты!
дефолтные настройки и поведение ядра и systemd в ubuntu 24.04 не позво ляют всего того о чём вы пишите. я неоднократно получал систему с полным отключением из-за разряда батареи. hibernate не уходит даже если достаточно памяти в своп - можете спорить с реальностью, но это так.. собственно поэтому я и написал этот скрипт/сервис... и сейчас я вообще не думаю о том сколько чего у меня используется.. я могу установить kubeflow - и только сама установка этого зверя займёт за одну минуту больше памяти, чем месяц работы какого-нибудь сервера, которых у меня на работе целое множество и своп там не используется вообще, потому что ресурсы спланированы так, чтобы памяти просто на всё хватало.. у нас на работе весь продакшн занимающий террабайты (если не петабайты) хранятся в кеше - представьте себе... а на рабочей машине всё по-другому.
ну такой вердикт.. по-умолчанию мой линукс не работает с батареей как это делает windows/macos - очень ненадёжно. а подход, который я описал, даёт мне гарантию 100% без каких-то переживаний.. могу работать до отсечки и заниматься только моими проектами без мониторинга системы в приципе. делал я это для себя и вполне доволен. поделился опытом. если вам не нравится или не подходит, или вы можете предложить более лаконичное решение - флаг в руки - покажите - расскажите.
я не единственный юзер у которого такие проблемы с линуксом. не отрицаю что это может быть связано с железом.. но в общем мне то какое дело. железо это или несовершенство архитектуры (использовать своп для хибернейта без возможности резервирования пространства для собственно хибернейта - это очевидный косяк в архитектуре как ни крути. какие тут могут быть аргументы). Я хочу использовать компьютер для своих целей, а не для того, чтобы администрировать своп - этим я могу заняться в рабочее время, когда мне за это платят деньги. а на домашнем компьютере я хочу просто быть довольныс пользователем. и моё решение делает меня вполне довольным
я могу установить kubeflow - и только сама установка этого зверя займёт за одну минуту больше памяти, чем месяц работы какого-нибудь сервера
Wat? Вы сравниваете установку софта с работой сервера, причём непонятно, имеете ли вы представление о разнице моментальных и временны́х единиц — объём оперативной памяти не может быть «за минуту» или «за месяц», это безвременная немонотонная единица.
но в общем мне то какое дело. железо это или несовершенство архитектуры
Дело вам как раз должно быть — железо вы самостоятельно не усовершенствуете, а вот архитектуру — запросто. Повторяюсь, GNU/Linux и его компоненты опенсорсны.
я не единственный юзер у которого такие проблемы с линуксом.
Вы не единственный юзер, у которого любые проблемы с линуксом. Это нормально, как видите, и у всех разный уровень. Всё пройдёт с опытом.
дефолтные настройки и поведение ядра и systemd в ubuntu 24.04 не позво ляют всего того о чём вы пишите.
Вот это и есть ваш камень преткновения. Дефолтные настройки дефолтного дистрибутива и не обязаны вам ничего более специфического, чем «включил—поработал—выключил», позволять.
я хочу просто быть довольныс пользователем. и моё решение делает меня вполне довольным
Правильное решение уже содержится в системе (о чём я рассказываю выше), а ваше личное не следует позиционировать как правильное, не разобравшись в вопросе до конца.
дефолтные настройки любого дистрибутива. какой бы он ни был не позволяют использовать систему как обычный пользователь windows/macosx - включил, поработал, ушёл делать другие дела не думая о состоянии операционной системы. из-за неправильного дизайна системы хайбернейта.
вот как работает swapiness = 0, если вам интересно. специльно для вас сделал тест на пару дней:
как видно swapiness = 0 не гарантирует того, что swap не будет использоваться..
тюнить систему дальше, регулировать настройки очистки файлового кеша или отключать кеш файловой системы совсем - нет спасибо. мне это не нужно. я считаю, что это костыть - ломать одно из-за того, что где-то другое криво разработано. и в любом случае все эти костыли не будут давать 100% гарантии того, что система уйдёт в глубокий сон.
ваш комментарий про то что ядру достеточно только того, что в свопе будет достоточно места - так же неверен. я это всё тчательно продебажил. с логами в journal. нужен непрерывный участок. ну или ещё как-то. но просто достаточное свободное место - не гарантия ухода в хайбернейт. проверено неоднократьно.
я использую ubuntu studio. система уже настроена очень хорошо. и я не хочу менять настройки ядра, которые уже на мой взгляд идеальны.
скрипт-сервис, написанный мною - результат многолетнего опыта использования ОС Линукс на десктопе. Работает на любой systemd системе.
ваш камень предкновения - это дешёвое дисковое пространство, кое для меня ничего ровным счётом не значит.. если у меня будет памяти 96ГБ, то я выделю ровно столько же для hibernate. у буду жить спокойно не думаю ни о чем. я знаю что мой сервис никогда меня не подведёт. по крайней мере за годы работы не было, как говорится ни единого разрыва
дефолтные настройки любого дистрибутива. какой бы он ни был не позволяют использовать систему как обычный пользователь windows/macosx
Наверное, потому что это дистрибутивы Linux?
сделал тест на пару дней
Да, вижу проблему. Но я всё ещё не могу понять, какой смысл от гибернации с большим объёмом занятой памяти. Не вижу принципиальной разницы от отключенного по умолчанию свопа, потому что тогда вам банально не хватит оперативки, раз вы каким-то образом умудряетесь так её забивать.
дисковое пространство, кое для меня ничего ровным счётом не значит
из-за неправильного дизайна системы хайбернейта
Вы решаете костылями проблему, которую сами себе создали. Что лучше: иметь возможность уйти в гибернацию с 48 Гб занятой памяти, при этом фактически бесполезно отрезая данный объём от дискового пространства, или же иметь возможность выдержать с его помощью больший пик (вероятно, с вашим юзкейсом там могут выйти и все 64 Гб) вместо того, чтобы система постоянно уходила в OOM, и при этом НЕ терять возможности уйти в гибернацию с прежними 48 Гб? По-моему, ответ очевиден. Исходя из этого и дизайн.
если у меня будет памяти 96ГБ, то я выделю ровно столько же для hibernate
Если вы так категоричны, то могли бы и выделить столько, сколько вам с лихвой понадобится на своп + гибернацию + ещё чутка про запас. Тоже «устранило» бы несуществующую проблему.
Далее просто процитирую ваши же слова, без комментариев:
свободное место - не гарантия ухода в хайбернейт. проверено неоднократьно
не хочу менять настройки ядра, которые уже на мой взгляд идеальны
Ответ не очевиден. Я так пробовал. Это не работает. Своп будет занят и места там не будет достаточно. Придется выделять больше, чем нужно. А так я выделя как раз минимальный необходимый объем. Ваше "решение" (которое не работает) это костыль. А мое решение - это 100% обход несовершенства системы + вы вольны настаивать swapinness и кэширование файлов для задач приложений, а не для задач хайбернейта. Я на компьютере не хайбернейтом занимаюсь, а рабочими задачами. Так что я хочу настраивать ядро под задачи, а не под хайбернейт.
Так что очевидно, что костылистось моего решения в бесконечное количество раз меньше вашего костыля
И оперативки мне хватает. Система работает без тормозов. и не требует моего внимания от слова совсем
Ну вы ерунду определенно пишите ))).
Если я отключу своп, то в гибурнацию система никак не уйдет. И тут мой скрипт - это единственное решение.
Да. Вариант добавить оперативы - это хорошо. Но это смена железа.
И тогда встречный вопрос. Как без моего скрипта уйти в хайбернейт с отключенным свопом?
Думайте перед тем как писать. Если вы так хорошо в этом разбираетесь. То напишите тут статью. И публика её прокомментирует.
И ещё. Вам не кажется странным, что вы единственный, кто поставил дизлайк и критикует этот подход? ;)
Засылалю вас вопросами. Вы так рьяно свою точку зрения хотите пропихнуть. Тогда отвечайте на конкретные вопросы
Как вы хотите уходить в гибернацию без зарезервированного для этого пространства? если вы используете это пространство для чего-то другого (файлы, своп, что угодно), тогда у вас просто не будет пространства для гибернации. Логика ))))
Так что тут всё просто. Если вы хотите использовать глубокий сон, тогда вам нужно просто смириться с тем, что кусок памяти по размеру такой же как оператика, вы отдаете под эти нужды. Иначе у вас не будет этого самого места. Оно не может появится неоткуда. Это нарушение логики.
Откуда 48ГБ. У меня в системе 32ГБ. И для гибернации ровно столько и нужно. Своп не участвует в этом процессе. Там данные и так на диске
Вы изначально понимаете эту проблему неправильно. И пытаетесь прикрутить туда какой-то костыль перенастраивая ядро. При этом такие настройки крутите, которые вообще никак не связаны с описанной проблемой и напрямую влияют на стабильность работы системы.
RTFM
Это не работает. Своп будет занят
Так это же проблема вашего использования. Если своп будет занят, значит, вы выделили недостаточно свопа!
я выделя как раз минимальный необходимый объем
Но вам же всё равно приходится выделять отдельный файл для гибернации, помимо основного свопа. А без свопа в принципе нельзя.
И оперативки мне хватает
Если бы хватало, не забивался бы своп. Вы ведь понимаете, что он чем-то занимается? Это что-то — ваше. Возможно, без свопа у вас просто не возникает таких нагрузок, иначе бы фризило и OOM'илось.
Если я отключу своп, то в гибурнацию система никак не уйдет
Так ваш скрипт же это и делает — держит его по умолчанию отключенным.
Как вы хотите уходить в гибернацию без зарезервированного для этого пространства?
Я такого не утверждал. А утверждал следующее:
возможность уйти в гибернацию с 48 Гб … отрезая данный объём от дискового пространства, или … выдержать с его помощью больший пик
имея ввиду, что включенный своп принесёт бо́льшую пользу, чем отключенный.
Откуда 48ГБ. У меня в системе 32ГБ
Как, откуда? Вы же сами скинули скриншот, где из ваших 32 Гб перелилось ещё около 5 Гб в своп. Значит, в пиковой нагрузке у вас было занято точно больше 32 Гб, я взял следующее «круглое» для примера.
Своп не участвует в этом процессе. Там данные и так на диске
Данные и так на диске, но нужно ещё не более одного объёма RAM для гибернации. Простая арифметика: выделите объём RAM + свопа сколько нужно в пике.
Вы изначально понимаете эту проблему неправильно. И пытаетесь прикрутить туда какой-то костыль перенастраивая ядро
Я вам предложил решение параметром ядра, исходя из того, что вы не хотите резервировать больше места. Исходя из вашего нового тезиса, что место на диске не является ценностью, я теперь вам предлагаю решение, как оно задумано по дизайну: увеличить объём своп-файла/раздела.
Вам не кажется странным, что вы единственный, кто поставил дизлайк и критикует этот подход?
Не кажется. Мне, как Linux-пользователю, кажется странным то, что вы так рьяно, как и я, отстаиваете свою точку зрения на костыльном решении, не пробуя рассмотреть штатно предусмотренные решения. А единственный я здесь в комментах потому, что подавляющему большинству осмысленных линуксоидов заголовок вашей статьи не был интересен в первую очередь.
RTFM
Кто бы говорил :)
Если я увеличу размер своп файла, то Линукс его будет использовать. В случае если у меня закончится память вместе со свопом, тогда Линукс выгрузит программы. А процесс гибернации не будет работать, потому что своп будет занят.
С моим же скриптом стабильность системы не нарушится. Процесс гибернации будет работать даже если памяти и свопа не достаточно. Я разделил эти две задачи.
Моё утверждение такое. Если вы используете гибернацию, то вам нужно резервировать под эту задачу дисковое пространство. Никакого магического решения для этого нет.
Вы уже отказались от вашего тезиса про то что вы "не хотите резервировать пространство, ведь его можно использовать как-то более разумно" - это очевидный бред сумасшедшего )))) нарушение базовой логики.
И на ваш тезис про увеличение свопа - это тоже костыль ненадежный. Уже 10 раз объяснил. Но вам видимо трудно это понять.
Нет. Увеличение свопа не даст гарантии. Уже проверено. И 10 раз вам ответил почему. Почитайте комментарии выше.
Если вы так уверены в своей правоте, то напишите статью и предложите свое решение. Я на Хабре не видел хорошего решения. Как в принципе и в других источниках. Пишется только о кривости системы гибернации. Что в общем-то имеет место быть
Если я увеличу размер своп файла, то Линукс его будет использовать
У вас проблема в понимании. Не линукс использует своп, а вы. Это вам не винда, где система пользуется вами, а не вы ею. Своп должен быть задан такого объёма, который вы, своим использованием, не займёте в нормальных условиях — и под гибернацию место останется.
Также стоит отметить, что при гибернации по умолчанию RAM сжимается, а при неудачной гибернации система попытается отсечь наименее нужные данные, поэтому места может быть и меньше.
Моё утверждение такое. Если вы используете гибернацию, то вам нужно резервировать под эту задачу дисковое пространство
А в каком моменте я с этим утверждением спорил? Потрудитесь указать.
"не хотите резервировать пространство, ведь его можно использовать как-то более разумно" - это очевидный бред сумасшедшего )))) нарушение базовой логики.
В чём нарушение? Ваш скрипт держит это пространство неиспользованным до начала гибернации, а штатное решение позволяет системе скинуть туда то, что не влезает в RAM при пиковой загруженности. Абсолютно все кейсы, где работает ваше решение, продолжают работать на штатном. Просто штатное, в духе линукса, дополнительно даёт бонусные возможности под вашу собственную ответственность: выдержать больше нагрузки ценой невозможности гибернации ДО СНИЖЕНИЯ этой нагрузки. А без свопа ваша система такую нагрузку попросту не выдержала бы, приведя к фризу/крашу. Риторический вопрос: что лучше?)
Если вы так уверены в своей правоте, то напишите статью и предложите свое решение
Писать статью об очевидном моменте использования — бред. Здесь не нужно никакой статьи, у большинства людей (включая меня) всё прекрасно работает из коробки, достаточно просто установить нужный объём swap.
Я написал в статье в самом начале. Хочу как Windows и Macosx.. Что непонятного? Для меня Linux это винда. Доходчиво объяснил? Вопросы отпали?
Недостаточно установить нужный объем своп. Где данные о том, что у большинства работает всё хорошо? Если вы про большинство, которое сидит на Windows и Macosx . Тогда соглашусь
Это ваше большинство может не считает проблемой то, что система просто отключается . Ну эта статья не для таких юзеров. Простите. Идите в другой тред и там флуд устраивайте
Штатное решение займет пространство для гибернации и ваше решение не будет работать. Оно ненадёжно
Моё решение менее кослыльное чем предложенное вами.
Я не нарушаю настройки ядра (которые нужны для работы других приложений). Моё решение по сути бескомпромиссно. Вы можете настраивать систему под любую задачу. Настраивать ядро как угодно. Поставить swapinness = 100 к примеру.
И это не нарушит процесс гибернации. Потому что я произвел decoupling гибернации от системы swap. По сути.
А ваше решение не позволит поставить swapinness=100. Вы останетесь с этой настройкой по жизни без возможности что-то менять и в какой-то момент у вас гибернация не сработает. Я это пишу, потому что я этот весь путь уже прошел. А вы пишите о том, чего не знаете и чего сами не проверяли. И мы оба это знаем. Не понимаю зачем вы сами себя обманываете?))))
Я вам уже ответил ранее, что swappiness выставлять — решение без необходимости увеличения объёма swap-файла, а раз мы вольны его увеличивать, то этой манипуляции не требуется.
Основной тезис из начала вашей статьи:
Неважно, какой у вас размер swap. Гибернация может не сработать даже если на swap достаточно свободного места. Догадайтесь, почему??? ... Да — фрагментация. Похоже, система пытается выделить непрерывный участок в swap.
Мы этот тезис уже опровергли два месяца назад.
К чему же вы продолжаете спорить?
Комментарий не является опровержением
Да как не является-то?
Смотрим kernel/power/snapshot.c:
To make this happen, we compute the total number of available page frames and allocate at least
([page frames total] - PAGES_FOR_IO - [metadata pages]) / 2 - 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE)of them, which corresponds to the maximum size of a hibernation image.
If
image_sizeis set below the number following from the above formula, the preallocation of memory is continued until the total number of saveable pages in the system is below the requested image size or the minimum acceptable image size returned byminimum_image_size(), whichever is greater.
Функция даже предварительно освобождает память, покуда возможно:
/*
* Let the memory management subsystem know that we're going to need a
* large number of page frames to allocate and make it free some memory.
* NOTE: If this is not done, performance will be hurt badly in some
* test cases.
*/
shrink_all_memory(saveable - size);
Затем пробует аллоцировать всё меньше и меньше, пока не получится:
/*
* The number of saveable pages in memory was too high, so apply some
* pressure to decrease it. First, make room for the largest possible
* image and fail if that doesn't work. Next, try to decrease the size
* of the image as much as indicated by 'size' using allocations from
* highmem and non-highmem zones separately.
*/
pages_highmem = preallocate_image_highmem(highmem / 2);
pages = preallocate_image_memory(alloc, avail_normal);
могу продолжить разбор, надо?
Нет. Мне это не интересно. Это не работает в реальных тестах. Страница не является байтом. Так что всё ваши утверждения можно поделить на ноль
Страница не является байтом. Так что всё ваши утверждения можно поделить на ноль
Простите, что? Где я утверждал обратное, или вообще что-то про байты?
Исходный код, который вы приводите использует страницы памяти. Не прячьте голову под землю как страус
Безусловно, в коде фигурируют страницы. Повторюсь: в каком месте я говорил про байты?
Я утверждаю. Ваш подход ненадёжен. При более менее разумных размерах своп ваш подход будет ненадёжен. Спрогнозировать использование оперативной памяти невозможно на 100% как минимум из-за возможных ошибок в ПО. Это делает ваше решение ненадежным. А мое решение и в этом случае справится.
А ваши бредни с кусками кода ничего не стоят. Ровно ничего.
Давайте полный обзор начиная с systemctl hibernate
Весь исходный код. Разбор. В студию
Разделяй и властвуй
Давайте полный обзор начиная с systemctl hibernate
Го!
Systemd v257.5 и Linux 6.14:
$ systemctl hibernate(кликабельно, также тык, тык, тык, тык);shared/hibernate-util.c:
find_suitable_hibernation_device_full():Attempt to find a suitable device for hibernation by parsing
/proc/swaps,/sys/power/resume, and/sys/power/resume_offset.
…
FOREACH_ARRAY(swap, entries.swaps, entries.n_swaps) {
…
if (… swap->size - swap->used > entry->size - entry->used)
entry = swap;
}
if (!entry) {
…
return log_debug_errno(SYNTHETIC_ERRNO(ENOSPC), "No swap space available for hibernation.");
}
- нашли своп-файл/раздел по размеру;
sleep/sleep.c:
execute()— пишет в/sys/power/state, запуская процесс гибернации в ядре:
…
/* Configure hibernation settings if we are supposed to hibernate */
if (SLEEP_OPERATION_IS_HIBERNATION(operation)) {
…
r = find_suitable_hibernation_device(&hibernation_device);
…
}
…
if (!action)
action = sleep_operation_to_string(operation);
…
… LOG_MESSAGE("Performing sleep operation '%s'...", sleep_operation_to_string(operation)) …
r = write_state(state_fd, sleep_config->states[operation]);
if (r < 0)
… LOG_MESSAGE("Failed to put system to sleep. System resumed again: %m") …
записали
diskв/sys/power/state;
…
state = decode_state(buf, n);
if (state < PM_SUSPEND_MAX) {
if (state == PM_SUSPEND_MEM)
state = mem_sleep_current;
error = pm_suspend(state);
} else if (state == PM_SUSPEND_MAX) {
error = hibernate();
} …
запустили процесс гибернации;
kernel/power/hibernate.c:
hibernation_snapshot():Quiesce devices and create a hibernation image.
…
error = hibernate_preallocate_memory();
…
if (… !error)
error = create_image(platform_mode);
/*
* In the case that we call create_image() above, the control
* returns here (1) after the image has been created or the
* image creation has failed and (2) after a successful restore.
*/
/* We may need to release the preallocated image pages here. */
if (error || !in_suspend)
swsusp_free();
- аллоцировали память и сделали дамп (и вернёмся сюда второй раз после пробуждения);
kernel/power/hibernate.c:
hibernate():Carry out system hibernation, including saving the image.
…
error = freeze_processes();
…
error = hibernation_snapshot(hibernation_mode == HIBERNATION_PLATFORM);
…
if (in_suspend) {
…
if (nocompress) {
flags |= SF_NOCOMPRESS_MODE;
} else {
flags |= SF_CRC32_MODE;
/*
* By default, LZO compression is enabled. Use SF_COMPRESSION_ALG_LZ4
* to override this behaviour and use LZ4.
*
* Refer kernel/power/power.h for more details
*/
if (!strcmp(hib_comp_algo, COMPRESSION_ALGO_LZ4))
flags |= SF_COMPRESSION_ALG_LZ4;
else
flags |= SF_COMPRESSION_ALG_LZO;
}
pm_pr_dbg("Writing hibernation image.\n");
error = swsusp_write(flags);
swsusp_free();
if (!error) {
…
power_down();
}
}
пережали и записали образ на диск и, наконец, выключили систему.
Ну а hibernate_preallocate_memory() мы с вами уже разбирали :))
P.S. А ещё более подробно можно почитать туть.
И нет. Следить за ресурсами - это не моя задача. Это задача операционной системы. Моя задача запускать программы и использовать их. А система должна быть максимально стабильной. Что я и сделал без ваших костылей
Ваша задача — пользоваться системой в меру её возможностей. Если вы хотите занимать больше, чем у вас RAM — будьте добры зарезервировать своп. Если нет — не занимайте.
Я зарезервировал hibernate и своп отдельно
И своп я зарезервировал для своп а хибернейт для хибернейт )))))
Сложно понять да?
Ну учитывая что вы пишите:
Неудивительно что вы продолжаете писать эту ахинею )))
Я поржал. Спасибо
Давайте так. У вас есть решение со 100% гарантией гибернации без предварительного планирования использования RAM? С учётом утечек памяти. Без мониторинга состоянии системы.
Так чтобы в любых состояниях система ушла в глубокий сон даже если случайно превысилось планируемое использование памяти?
Вы можете предложить такое решение?
OOM-киллер такое решение, и ограничения cgroups (в т.ч. нативно средствами systemd).
Уже не просто swapinness? )))
Куда же делся swapinness?
Какие ещё костыли предложите?))
Ладно. С cgroups уже заход лучше. Но тоже не для меня. Ядро может обходить лимиты cgroups. Так что это не 100% гарантия.
Так что спасибо. Но мне мое решение больше нравится
И да. Спасибо что уже не swapinness. А то я думал мы так застрянет в этом бреду непролазном
Но с cgroups уже правда лучше. Нужно тестировать как оно себя в деле покажет. Как-нибудь при удобном случае
Я не спорю. Я утверждаю. Ваш подход ненадёжен. При более менее разумных размерах своп ваш подход будет ненадёжен. Спрогнозировать использование оперативной памяти невозможно на 100% как минимум из-за возможных ошибок в ПО. Это делает ваше решение ненадежным. А мое решение и в этом случае справится.
Разделяй и властвуй
В общем отвечу просто: меня ваше решение не устраивает. Спасибо! Используете сами )))
Два момента.
Linux - это не только systemd-дистрибутивы, но и non-systemd (это про systemctl).
Уже давно не даю машине уходить в сон/гибернацию. Зачем? Для экономии ресурсов? Диск (если HDD) отключается (время отключения настраивается), монитор (внешний) на ночь отключается кнопкой, подсветка клавиатуры отключается.
В целом интересно было почитать.
В путешествиях, особенно для любителей покодить в аэропортах. В сон увожу на ночь, потому что драйвера dell фуфло и кулеры через fancontrol крутятся, иногда шумно. Но со сном и так проблем, а гибернация - всегда боль, особенно на шифрованных дисках. Автору за статью спасибо, попробую на досуге.
Спасибо за ответ.
Пользуюсь исключительно стационарно, даже ноутбуками.
Попробуйте ультрабуки, сразу измените мнение :)
Вряд ли. Ежели соберусь приобретать что-то новое, предпочту desktop, хотя бы slim.
Не советую, с охлаждением всё очень плохо.
Всё очень хорошо для многих задач. Тяжёлое локально всё равно не вижу смысла тягать — в первую очередь это энергопотребление. Если вашему ноутбуку нужно охлаждаться, значит, вам нужен не ноутбук. Я их использую как «средней толщины» клиенты, все вычислительные задачи делегируя домашнему серверу.
Я конкретно про ультрабуки говорю. Массивные 17.3 ноуты таких проблем не имеют.
на второй вопрос уже ответили. а про первый соглашусь. но у меня лично systemd. делал, как говорится, для себя. но подход описан подробно - можно адаптировать. скрипт несложный
Hibernate в Linux: 0.99 проблемы меньше