Напоминаю в третий раз: MGLRU без параметра min_ttl_ms (по умолчанию отключён) никак не противодействует thrashing. Это просто альтернативный, более умный, менеджер памяти.
Так сама ситуация нестандартная, конечно ее решение требует настройки.
Все стандартные значения параметров ядра устанавливаются, ориентируясь на серверные сценарии использования. Мне на десктопе, например, больше 30-40 МБ еще не записанных на диск данных, но уже находящихся в оперативке (dirty/writeback) только во вред, а Linux по умолчанию устанавливает это значение в 10% от количества оперативной памяти — 3.2 ГБ на 32ГБ RAM.
С моей точки зрения это совершенный абсурд, но, видимо, кому-то норм. У меня несколько раз начинался thrashing из-за этой стандартной настройки :P
Проблема: thrashing (пробуксовка), или live lock, происходит тогда, когда несколько программ борются за оперативную память при её недостатке, что выливается либо в агрессивное сбрасывание файлового кеша из оперативки, чтобы загрузить данные из swap, либо наоборот, к срочной загрузке файлов с диска в кеш, потому что они нужны программе для её работы (программный код, в самом распространённом случае).
В общем смысле thrashing возникает, когда процессы так сильно конкурируют между собой, памяти так мало, а диск такой медленный, что ни один из процессов не может выполнить осмысленную работу в отведённый ему момент времени: система только и занимается, что пытается сбросить файловый кеш (особенно код) одной программы, чтобы загрузить данные другой программы, а тут уже подходит время передать управление первой программе, нужно загрузить её программный код и её данные, и так по кругу. Особенно худо, когда одна из программ каждый раз выделяет всё больше и больше памяти и работает с ней.
Но с точки зрения пользователя thrashing случается также когда система неотзывчива по привычным для пользователя интерфейсам: для десктопа это отсутствие перерисовки изображения на экране или отсутствия отклика на переключение программ или открытия меню (например, выгрузился файловый кеш (код) xorg, wayland, библиотек qt или gtk: так-то программы работают, плеер даже может продолжать играть музыку без перерыва, только пользователю от этого не легче), для сервера это невозможность подключиться по SSH или использовать основное ПО (bash в SSH-сессии, например), потому что код работы с памятью решил, что postgresql, который очень активно использует оперативку и диск и разом записал 10 ГБ данных, которые оказались во writeback-буфере, очевидно, гораздо важнее SSH-сессии.
Решаем проблему: ограждаем X мегабайт файлового кеша от сбрасывания: это то, что делает le9. Просто не дадим какому-то количеству произвольного файлового кеша выгружаться, в каждый момент времени разному (такому, какой важен по мнению существующего алгоритма LRU по работе с памятью). Какое это количество — решать пользователю, в зависимости от того, какой он использует софт, сколько он запускает разных программ и насколько ему важнее файловый кеш перед данными — от этого зависит время переключения между программами (latency).
Такой подход предотвращает жесткий thrashing (даже несколько десятков мегабайт заблокированных данных почти наверняка не приведут к бесконечному циклу — всё будет тормозить и откликаться по нескольку секунд, но не «зависнет»), но для эффективной работы требует установки значения с пониманием сценария работы, жирности софта, количества оперативки, и т.п.
Решаем проблему: ограждаем файловый кеш от сбрасывания на X миллисекунд: это подход MGLRU TTL. Пользователь прошлые 100 мс активно работал с такими-то данными в памяти, и у нас ну очень мало оперативки? Не вымещаем их из оперативки следующие 100 мс.
Эффективно? Так себе. Зато тоже работает, не требует тонкой настройки, и часто обеспечивает достаточно низкий latency (явно лучше, чем le9 с низкими значениями), но может приводить к OOM программ, которые пытались выделить память в эти X мс и не смогли (актуально при больших значениях ttl, от 500 мс и более).
Всё, что требует ручной настройки, и на что нельзя задать default, будет отключено по умолчанию, и будет иметь единицы пользователей. Это основная претензия к le9 в lkml.
В этом и его проблема — его необходимо настраивать.
Есть у нас десктоп с 2ГБ RAM, какой объём файлового кеша блокировать? 64 МБ почти никакого эффекта не дадут, 512 МБ явно многовато.
Запускаем в основном жирные программы, которые загружают жирные библиотеки? Нужно поставить побольше, иначе всё равно будет пробуксовка, хоть и не настолько выраженная — выгрузится какой-нибудь Xorg или pixmap'ы, и пока данные будут восстанавливаться из свопа или перечитываться из диска, десктоп «зависнет» (критические для отрисовки данные/код не будет доступен). Выгрузится у условного Firefox'а библиотека, которая нужна раз в секунду, и в эту же секунду начнёт что-то другое свопится, то FF зависнет — поток будет ждать, пока не появятся необходимые данные.
А если у нас не компьютер, а роутер с 128 МБ, из которых 70 МБ занято файловым кешем? Ему что важнее: данные или код? Абсолютно всегда, в любой момент времени? le9 требует от вас решить этот вопрос.
А MGLRU работает во временном домене: он знает, что использовалось совсем недавно, и понимает, что это нужно всеми силами не скидывать в своп.
l9ec 100% с гарантией решает проблему
Только если вы знаете, что вы запускаете на своем компьютере, и подобающе настроили le9.
2-ядерный 64-битный процессор Intel® Core™2 Duo E4600 (2 ядра, 2.4 ГГц, конец 2007)
2 ГБ оперативной памяти (DDR2 667 МГц, одним модулем)
Жесткий диск 160 ГБ Samsung HD161HJ (SATA II, июнь 2007)
Без дискретной видеокарты
Результат работы тестового компьютера после всех настроек Одновременно запущены:
Firefox с 37 активными вкладками (все данные в RAM, без выгрузки, всё честно)
Discord
Skype
LibreOffice с открытым документом
Два PDF-файла (размером 14 и 47 мегабайт)
…и всё это при 2 ГБ оперативной памяти. Впечатляет?
Если le9 делает чудеса просто в силу жесткой блокировки большого количества файлов, то с MGLRU + 1000 ms TTL, который я выполнил на таком же тесте спустя несколько месяцев, было похуже в силу очень медленного HDD (2007 года, это не современные с линейным чтением под 200 МБ/с) и какого-никакого вытеснения, но приемлемо.
Проблема-то на новых ядрах в целом решена MGLRU + echo 200 > /sys/kernel/mm/lru_gen/min_ttl_ms (или 500-1000 на HDD) + zram. Даже совсем древнегреческие машины, вроде VIA Nano с 512 МБ RAM, нормально работают в такой конфигурации.
Параметр min_ttl_ms как раз предотвращает вытеснение файлового кеша на X миллисекунд, см. Thrashing prevention в документации MGLRU. Без этого параметра (по умолчанию не включён) MGLRU это просто умный алгоритм определения редкоиспользуемых данных, которые можно выгрузить в swap.
MGLRU с TTL по отзывчивости чуть хуже le9, и может привести к OOM вместо агрессивного своппинга, но его идея в динамических условиях в вакууме лучше, чем банальная блокировка вытеснения файлового кеша фиксированного размера.
В ответ же получаем json файл с настройками, достаточно объёмный, а за блокировку отвечает параметр subscription, который достаточно легко подменить (Но это я пока не раскрою).
В оригинальной колонке эта проверка обходилась просто переименованием этой строки в бинарнике. Бинарник не мог найти этот параметр в json и по умолчанию считал подписку действующей, а на серверной стороне ограничений не было — вся логика была в самой Станции.
Я в конце-концов захакал модуль в recovery, выполняющий обновление прошивки, чтобы сразу после установки новой версии он патчил бинарник, и хак переживал обновления версий.
В тестах SSD вида «копируем набор больших файлов» под Windows я ни разу не видел скоростей выше 4 ГБ/С, даже на самых современных NVMe-дисках со скоростью линейной записи в 12 ГБ/с. Microsoft для игр сделала DirectStorage, который исключает Bitlocker и минифильтры — полагаю, что стек в Windows очень тормознутый, раз приходится делать подобные технологии.
Сэкономлю всем время. Новость заключается в том, что теперь для автоматического включения шифрования не требуются особые условия:
In Windows 11 version 24H2, Microsoft is reducing the hardware requirements for automatic device encryption, opening it up to many more devices — including ones running the Home version of Windows 11. Device encryption no longer requires Hardware Security Test Interface (HSTI) or Modern Standby, and encryption will also be enabled even if untrusted direct memory access (DMA) buses / interfaces are detected.
Ещё раз перепроверил свою память: Device Encryption есть в Windows 10 Home, включён автоматически после установки, диск на современных компьютерах зашифрован до первого входа. Вроде бы, ничего с Windows 10 образца 2019 года не менялось. О чём эта новость — непонятно.
When you first sign in or set up a device with a Microsoft account, or work or school account, Device Encryption is turned on and a recovery key is attached to that account. If you're using a local account, Device Encryption isn't turned on automatically.
Unlike BitLocker Drive Encryption, which is available on Windows Pro, Enterprise, or Education editions, Device Encryption is available on a wider range of devices, including those running Windows Home.
Оно, скорее всего, «приостановлено» до входа в онлайн-аккаунт, точно не помню. Диск шифруется непосредственно во время установки ОС, но если не входить в онлайн-аккаунт, мастер-ключ (volume key) хранится в открытом виде на самом диске, не защищённый паролем или TPM-данными. Но все данные на диске зашифрованы VLK.
А как только входишь в аккаунт, шифрование включается моментально, без перешифровки данных. Это на Home-версии, на Pro оно, если память не изменяет опять же, включено полностью автоматически с самого начала (в Home-версии Windows 10 нет привычного "Bitlocker", там "Шифрование диска" с одной кнопкой и без настроек — технически всё то же самое, но другой продукт и другой интерфейс).
Нет, это бэкап ключа автоматически выполняется при наличии онлайн-учётки или AD, а шифрование, привязанное к TPM, активируется на этапе установки. После установки, до первого входа, диск уже зашифрован.
Включается. Я прямо удивился из этой статьи, думал, что это по умолчанию с Windows 10 уже сто лет везде, а оказывается, только на брендовых компьютерах.
Dell and Lenovo systems that ship with the Windows 10 operating system and are equipped with Trusted Platform Module (TPM) capability will have Microsoft BitLocker encryption enabled from the factory. It has been found that once the device is registered to a Active Directory domain - Office 365 Azure AD, Windows 10 automatically encrypts the system drive. You find this once you reboot your computer and are then prompted for the BitLocker key."
На Surface'ах шифрование включается автоматически при установке Windows 10, даже Home.
И да, на Surface Go приходится вводить ключ восстановления каждый раз при смене настроек UEFI (возврат настроек не даёт компьютеру загрузиться снова, какой-то из PCR'ов всегда уникально меняется).
Иностранцу не купить SIM в России.
https://sapica-hatenablog-com.translate.goog/entry/2025/01/20/034537?_x_tr_sl=ja&_x_tr_tl=ru&_x_tr_hl=ru&_x_tr_pto=wapp
Он в мейнлайне с 6.1, и уже используется в Android-телефонах.
Напоминаю в третий раз: MGLRU без параметра
min_ttl_ms(по умолчанию отключён) никак не противодействует thrashing. Это просто альтернативный, более умный, менеджер памяти.Все стандартные значения параметров ядра устанавливаются, ориентируясь на серверные сценарии использования. Мне на десктопе, например, больше 30-40 МБ еще не записанных на диск данных, но уже находящихся в оперативке (dirty/writeback) только во вред, а Linux по умолчанию устанавливает это значение в 10% от количества оперативной памяти — 3.2 ГБ на 32ГБ RAM.
С моей точки зрения это совершенный абсурд, но, видимо, кому-то норм. У меня несколько раз начинался thrashing из-за этой стандартной настройки :P
Проблема: thrashing (пробуксовка), или live lock, происходит тогда, когда несколько программ борются за оперативную память при её недостатке, что выливается либо в агрессивное сбрасывание файлового кеша из оперативки, чтобы загрузить данные из swap, либо наоборот, к срочной загрузке файлов с диска в кеш, потому что они нужны программе для её работы (программный код, в самом распространённом случае).
В общем смысле thrashing возникает, когда процессы так сильно конкурируют между собой, памяти так мало, а диск такой медленный, что ни один из процессов не может выполнить осмысленную работу в отведённый ему момент времени: система только и занимается, что пытается сбросить файловый кеш (особенно код) одной программы, чтобы загрузить данные другой программы, а тут уже подходит время передать управление первой программе, нужно загрузить её программный код и её данные, и так по кругу. Особенно худо, когда одна из программ каждый раз выделяет всё больше и больше памяти и работает с ней.
Но с точки зрения пользователя thrashing случается также когда система неотзывчива по привычным для пользователя интерфейсам: для десктопа это отсутствие перерисовки изображения на экране или отсутствия отклика на переключение программ или открытия меню (например, выгрузился файловый кеш (код) xorg, wayland, библиотек qt или gtk: так-то программы работают, плеер даже может продолжать играть музыку без перерыва, только пользователю от этого не легче), для сервера это невозможность подключиться по SSH или использовать основное ПО (bash в SSH-сессии, например), потому что код работы с памятью решил, что postgresql, который очень активно использует оперативку и диск и разом записал 10 ГБ данных, которые оказались во writeback-буфере, очевидно, гораздо важнее SSH-сессии.
Решаем проблему: ограждаем X мегабайт файлового кеша от сбрасывания: это то, что делает le9. Просто не дадим какому-то количеству произвольного файлового кеша выгружаться, в каждый момент времени разному (такому, какой важен по мнению существующего алгоритма LRU по работе с памятью). Какое это количество — решать пользователю, в зависимости от того, какой он использует софт, сколько он запускает разных программ и насколько ему важнее файловый кеш перед данными — от этого зависит время переключения между программами (latency).
Такой подход предотвращает жесткий thrashing (даже несколько десятков мегабайт заблокированных данных почти наверняка не приведут к бесконечному циклу — всё будет тормозить и откликаться по нескольку секунд, но не «зависнет»), но для эффективной работы требует установки значения с пониманием сценария работы, жирности софта, количества оперативки, и т.п.
Решаем проблему: ограждаем файловый кеш от сбрасывания на X миллисекунд: это подход MGLRU TTL. Пользователь прошлые 100 мс активно работал с такими-то данными в памяти, и у нас ну очень мало оперативки? Не вымещаем их из оперативки следующие 100 мс.
Эффективно? Так себе. Зато тоже работает, не требует тонкой настройки, и часто обеспечивает достаточно низкий latency (явно лучше, чем le9 с низкими значениями), но может приводить к OOM программ, которые пытались выделить память в эти X мс и не смогли (актуально при больших значениях ttl, от 500 мс и более).
Всё, что требует ручной настройки, и на что нельзя задать default, будет отключено по умолчанию, и будет иметь единицы пользователей. Это основная претензия к le9 в lkml.
В этом и его проблема — его необходимо настраивать.
Есть у нас десктоп с 2ГБ RAM, какой объём файлового кеша блокировать? 64 МБ почти никакого эффекта не дадут, 512 МБ явно многовато.
Запускаем в основном жирные программы, которые загружают жирные библиотеки? Нужно поставить побольше, иначе всё равно будет пробуксовка, хоть и не настолько выраженная — выгрузится какой-нибудь Xorg или pixmap'ы, и пока данные будут восстанавливаться из свопа или перечитываться из диска, десктоп «зависнет» (критические для отрисовки данные/код не будет доступен).
Выгрузится у условного Firefox'а библиотека, которая нужна раз в секунду, и в эту же секунду начнёт что-то другое свопится, то FF зависнет — поток будет ждать, пока не появятся необходимые данные.
А если у нас не компьютер, а роутер с 128 МБ, из которых 70 МБ занято файловым кешем? Ему что важнее: данные или код? Абсолютно всегда, в любой момент времени?
le9 требует от вас решить этот вопрос.
А MGLRU работает во временном домене: он знает, что использовалось совсем недавно, и понимает, что это нужно всеми силами не скидывать в своп.
Только если вы знаете, что вы запускаете на своем компьютере, и подобающе настроили le9.
Я в 2021 году проводил тест le9 на следующей машине:
Если le9 делает чудеса просто в силу жесткой блокировки большого количества файлов, то с MGLRU + 1000 ms TTL, который я выполнил на таком же тесте спустя несколько месяцев, было похуже в силу очень медленного HDD (2007 года, это не современные с линейным чтением под 200 МБ/с) и какого-никакого вытеснения, но приемлемо.
Ну, так, вы включали ttl в MGLRU? Без него он не устраняет thrashing, что вы называете зависанием.
Проблема-то на новых ядрах в целом решена MGLRU +
echo 200 > /sys/kernel/mm/lru_gen/min_ttl_ms(или 500-1000 на HDD) + zram. Даже совсем древнегреческие машины, вроде VIA Nano с 512 МБ RAM, нормально работают в такой конфигурации.Параметр
min_ttl_msкак раз предотвращает вытеснение файлового кеша на X миллисекунд, см. Thrashing prevention в документации MGLRU. Без этого параметра (по умолчанию не включён) MGLRU это просто умный алгоритм определения редкоиспользуемых данных, которые можно выгрузить в swap.MGLRU с TTL по отзывчивости чуть хуже le9, и может привести к OOM вместо агрессивного своппинга, но его идея в динамических условиях в вакууме лучше, чем банальная блокировка вытеснения файлового кеша фиксированного размера.
А обсуждалась проблема еще с 2009, когда похожий патч добавили в ChromeOS, потому что на бюджетном железе того времени без swap'а всё зависало: https://lore.kernel.org/lkml/20101028191523.GA14972@google.com/
Больше обсуждения здесь: https://lore.kernel.org/lkml/20211130201652.2218636d@mail.inbox.lv/, и в ревизиях MGLRU.
В оригинальной колонке эта проверка обходилась просто переименованием этой строки в бинарнике. Бинарник не мог найти этот параметр в json и по умолчанию считал подписку действующей, а на серверной стороне ограничений не было — вся логика была в самой Станции.
Я в конце-концов захакал модуль в recovery, выполняющий обновление прошивки, чтобы сразу после установки новой версии он патчил бинарник, и хак переживал обновления версий.
KDE Connect переводит телефон в режим DnD, если нажать соответствующий пункт в самой ОС на компьютере.
Под Windows тоже есть.
В тестах SSD вида «копируем набор больших файлов» под Windows я ни разу не видел скоростей выше 4 ГБ/С, даже на самых современных NVMe-дисках со скоростью линейной записи в 12 ГБ/с.
Microsoft для игр сделала DirectStorage, который исключает Bitlocker и минифильтры — полагаю, что стек в Windows очень тормознутый, раз приходится делать подобные технологии.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/bypassio
Сэкономлю всем время. Новость заключается в том, что теперь для автоматического включения шифрования не требуются особые условия:
Я, вот, тоже не вспомню :P
Я аутентифицируюсь по отпечатку пальца или лицу. Знаю PIN от Windows Hello, но от учётки пароль вряд ли вспомню.
Ещё раз перепроверил свою память: Device Encryption есть в Windows 10 Home, включён автоматически после установки, диск на современных компьютерах зашифрован до первого входа.
Вроде бы, ничего с Windows 10 образца 2019 года не менялось.
О чём эта новость — непонятно.
https://support.microsoft.com/en-us/windows/device-encryption-in-windows-cf7e2b6f-3e70-4882-9532-18633605b7df
Оно, скорее всего, «приостановлено» до входа в онлайн-аккаунт, точно не помню. Диск шифруется непосредственно во время установки ОС, но если не входить в онлайн-аккаунт, мастер-ключ (volume key) хранится в открытом виде на самом диске, не защищённый паролем или TPM-данными.
Но все данные на диске зашифрованы VLK.
А как только входишь в аккаунт, шифрование включается моментально, без перешифровки данных. Это на Home-версии, на Pro оно, если память не изменяет опять же, включено полностью автоматически с самого начала (в Home-версии Windows 10 нет привычного "Bitlocker", там "Шифрование диска" с одной кнопкой и без настроек — технически всё то же самое, но другой продукт и другой интерфейс).
Нет, это бэкап ключа автоматически выполняется при наличии онлайн-учётки или AD, а шифрование, привязанное к TPM, активируется на этапе установки. После установки, до первого входа, диск уже зашифрован.
Включается. Я прямо удивился из этой статьи, думал, что это по умолчанию с Windows 10 уже сто лет везде, а оказывается, только на брендовых компьютерах.
https://web.archive.org/web/20221209085210/https://hardsoft-support.kayako.com/article/99-windows-10-bitlocker-turns-on-without-a-notice
На Surface'ах шифрование включается автоматически при установке Windows 10, даже Home.
И да, на Surface Go приходится вводить ключ восстановления каждый раз при смене настроек UEFI (возврат настроек не даёт компьютеру загрузиться снова, какой-то из PCR'ов всегда уникально меняется).
Прошивки предоставляются только клиентам-покупателям.