Выделение оперативной памяти для приложения/процесса

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

Не совсем так, лимит в десятки терабайт есть.

См в /proc/meminfo

VmallocTotal:   34359738367 kB

линуксом невозможно пользоваться на компьютерах с небольшим количеством оперативки

Спорное утверждение.

https://bugzilla.kernel.org/show_bug.cgi?id=196729

А это вообще причем? Там пациент сломал настройки

vm.swappiness = 1
vm.min_free_kbytes = 32768

и почему-то чем-то недоволен.

есть планшет с 1 ГБ оперативки, и на нем линукс почти не работает

Смешная фраза, конечно. На таких машинах хорошо работает Antix.

256MB RAM is recommended minimum for antiX https://antixlinux.com/about/

vm.watermark_scale_factor=200

Минус этого ключа в том, что побочный эффект - избыточное резервирование free страниц при увеличении этого фактора, что ведет к неполной утилизации памяти. le9 patch позволяет прицельно резервировать файловые страницы, избегая ненужной побочки в виде резерва free.

Но таки да, watermark_scale_factor=200 работает как мягкая защита файловых страниц на время своппинга (и отключается при исчерпании свопа).

А без патча/cgroups/юзерспейсных демонов какой самый нормальный метод(ы)?

zram + увеличенный watermark_scale_factor

А zswap?

Это шаблон /etc/cgconfig.conf для cgconfigparser. Создать группы можно хоть bash-скриптом.
Так же нужно что-то, что будет тасовать процессы в группы. Я использую cgrulesengd, но уверен, что адепты systemd могут сделать всё с помощью него.

zswap - риск записи на медленный диск. Данные на диск пишутся в распакованном виде

Спасибо.

До NT6 имелся доступ к настоящему текстовому режиму видеокарты

Не существует никакого «текстового режима видеокарты». Эта фраза сама по себе - пик бредовости и бессмысленности.

«Настоящий текстовый режим» - это телетайп, матричный принтер и COM-порт. Все миникомпьютеры конца 20-го в - Amiga, ZX Spectrum, Intel x86 не имеют никакого «текстового режима», а предоставляют запускаемым программам набор вызовов своей «прошивки» для отрисовки в видеобуфере ASCII-символов.

Это режимы работы «прошивки» (не карты!) для вывода графики на экран.

Ещё раз повторяем

Ты не повторяй свой бред как попка-дурак, а учи правильную терминологию, пока я жив и добрый. А то так и будешь деревенскими лородурачком, который делит «сессии» на tty и pty.

а предоставляют запускаемым программам набор вызовов своей «прошивки» для отрисовки в видеобуфере ASCII-символов

Ага, «произвольной» графики в квадратно-гнездовых знакоместах, доступных по адресам 0xb8000–0xb8fff :P Ну на относительно новых материнках его BIOS эмулирует, и фигли? ОС-то по барабану. Вы ещё прикопайтесь, как всякие Цари, что x86 как таковой мёртв, потому что микрокодом давным-давно эмулируется поверх RISC.

который делит «сессии» на tty и pty

Ну, тут Вы правы; уж на что, а на job control тип терминала в целом не влияет.

Поставил linux-pf с патчем.

Разница ощутимая, система не виснет даже с подкачкой на HDD.

Запустил браузер, который сожрал 70% ОЗУ, а потом 6 tail /dev/zero. В таком экстремальном режиме, пользоваться продуктивным софтом, конечно, невозможно, но открыть терминал и убить лишнее — вполне. Цель сохранить управляемость машиной достигнута.

С одним tail /dev/zero браузер подтупливает, но терминал и текстовый редактор работают без замедления. Вывод find / идёт без задержек вообще. o_O 🔥

Все миникомпьютеры конца 20-го в - Amiga, ZX Spectrum, Intel x86 не имеют никакого «текстового режима», а предоставляют запускаемым программам набор вызовов своей «прошивки» для отрисовки в видеобуфере ASCII-символов.

Радио-86РК:

«Видеоподсистема: текстовый режим на 64 символа в строке. Число символов в строке изменить нельзя, но число видимых текстовых строк можно программно менять от 16 до 51, соответственно изменяя высоту знакоместа так, чтобы число отображаемых линий растра оставалось в пределах 250-260. «Контроллер алфавитно-цифрового терминала» КР580ВГ75 работает совместно с «контроллером прямого доступа в память» КР580ВТ57. ВТ57 каждые 640 мкс считывает из экранного ОЗУ 78 байтов текущей строки (пачками по 8 байт) и загружает их в ВГ75, для каждой пачки останавливая процессор на 18 мкс. Периодическое считывание экранного ОЗУ попутно регенерирует динамическую память. Курсор формируется аппаратно КР580ВГ75. Он может отображаться тонкой чёрточкой, сплошным знакоместом или быть выключен.»

Компьютер использовал в качестве монитора бытовой телевизор, подключаемый через видеовход или через радиотракт

он растром срал на экран, а не текстом в компорт

у тсоря же новая методичка, что вообще всё эмулируется поверх vliw

Он пиксели для растра аппаратно генерировал из шрифта и буфера с кодами символов. Не программно и никакой не прошивкой.

Шиза прогрессирует ;)

Ага, «произвольной» графики

Да, произвольной. Как правило в видеопамять можно закачать любой «шрифт», представляющий из себя цепочку обычных битмапов.

в квадратно-гнездовых знакоместах, доступных по адресам 0xb8000–0xb8fff :P

Ты хоть понял, что ты написал-то? Если бы квадратно-гнездового интерфейса доступа к управлению битмапом не было, а был бы интерфейс ввода вывода по символу через порт как для COM / LPT, вот тогда бы это был «текстовый» интерфейс.

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

Ты доказываешь мой поинт.

представляющий из себя цепочку обычных битмапов

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

От того, что Вы положите туда псевдографику или какой-нибудь Wingdings, суть не меняется: такая же квадратно-гнездовая сетка.

а был бы интерфейс ввода вывода по символу через порт как для COM / LPT

Ну конечно, в COM/LPT абстрактные символы засылаются, а не всё те же байты, которые лишь конвенционально чему-то соответствуют ;)

а спрайтами из ограниченной коллекции по фиксированным границам координат. Т.е. фактически представленной прошивкой видеокарты простейший спрайтовый «движок».

А пищушие ромашки в печатных машинках — это не аналог «спрайтового движка», что ли? ;) Их тоже заменять можно! Сами ветряную мельницу выдумали и с ней воюете, чесслово.

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

Ну конечно, в COM/LPT абстрактные символы засылаются, а не всё те же байты

Засылаются, конечно же, двоичные коды. Но по этим интерфейсам хотя бы можно делать вид, что они текстовые. Например, AT-команды модема или ESC/POS команды принтера - там вполне себе ASCII-коды латинских букв.

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

От того, что Вы положите туда псевдографику или какой-нибудь Wingdings, суть не меняется

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

спрайты могут быть любого размера

А теперь пошли попытки отрицания путём выдумывания несуществующих определений.

Размеры спрайтов определяются движком, и в ранних видеоиграх для слабых машин,типа сеги или спектрума, спрайты были фиксированного размера. Что, в этих играх спрайты не спрайты?

там вполне себе ASCII-коды латинских букв

А битмапы не в порядке ASCII располагаются и вызываются, что ли? ;)

полностью исключает какой-либо разговор о «текстовости»

Вы ещё скажите, что брайледисплеи не текст выводят. Там же сетки точек, на буквы не похожие ;) Чем это отличается от псевдографики в TRS-80/телетексте?

спрайты были фиксированного размера

Но не монохромные даже там.

А битмапы не в порядке ASCII располагаются и вызываются, что ли? ;)

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

Но не монохромные даже там.

В смысле «монохромные»? Ты чо, ты чо, сучара?!? Ты на кого батон крошишь? У нас в VGA по четыре бита цвета символа, три - цвета фона и ещё мигать можем!

И это, кстати, большая цветность, чем в у спектрума, для которого в играх ещё и палитру сокращали. Твой аргумент - опять инвалид.

Вы ещё скажите, что брайледисплеи

Сверхманёвренность выходит по траектории Мёбиуса в тор.

Не сдерживай себя - переходи к «читалкам экрана». Уж они-то точно докажут текстовую природу видеокарт!! Ведь если они могут читать текст с экрана - значит видеокарты выводят текст!!11

по умолчанию прошитые

А как красиво распинались, что оно, мол, сугубо загружаемое ;) А выходит, всё же аппаратное.

У нас в VGA по четыре бита цвета символа, три - цвета фона и ещё мигать можем!

Это-то тут при чём, запихнуть более двух цветов в знакоместо всё равно нельзя ;) Оттого и монохромность.

Вообще, аж до бума эмодзи монохромность была главной отличительной чертой текста от произвольной графики. Хоть немоноширинного, хоть векторного, хоть сглаженного (под что даже ClearType подпадает, ибо непроизволен), хоть даже в виде моднявых символьных иконок — никак нельзя было покрасить символ более чем в один цвет кряду ;) Отрендеренный текст уже покрасить можно, но это совсем другая песня.

А вот для эмодзи уже накостыляли запихивание растровых картиночек в шрифтов. Но что примечательно, эти картиночки и подавно перекрашивать нельзя ;)

переходи к «читалкам экрана»

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

значит видеокарты выводят текст!!11

Вот при чём здесь вывод, ну, когда речь шла о том, что на видеокарты поступает на вход? Так можно договориться, что на выходе нет никаких пикселей, никаких цветов, там просто электроны с разной интенсивностью вылетают, затворы поворачиваются и перекрывают свет, и чего там ещё ;) А уж после всего этого вообще пучки фотонов тупо. Таким образом компуктер — это фотонная пушка, о как! Стреляет фотонами! А вы все дебилы и не лечитесь, текстовые режимы придумали, графические, чего несут! Это всё просто разные способы излучать фотоны! Вот у дедов фотоны так излучались, так излучались, что аж дырки в люминофоре прожигали… ой, это же ещё когда они электронами были ;DDDD

Вы уж определитесь для начала, что такое текст и о чём мы спорим. А то ведь любой нумерованный кортеж графических элементов (в том числе спрайтов, ага) можно считать таблицей символов. Или уже забыли, что кодировок слегка дохрена, и даже ASCII с его ближайшими собратьями лишь относительно недавно застолбил первые 128 нумеров? ;)

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

Это называется знакоместо. Сами вы «спрайт». :P

Ты хоть понял, что ты написал-то?

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%BE%D0%B2%D1%8B%D0%B9_%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE%D1%80%D0%B5%D0%B6%D0%B8%D0%BC

Текстовый.

А как красиво распинались, что оно, мол, сугубо загружаемое

И где? Врать не хорошо. Приписывать свои фантазии собеседнику - тоже.

А выходит, всё же аппаратное.

Погугли буквосочетания EEPROM и схожие.

запихнуть более двух цветов в знакоместо всё равно нельзя ;) Оттого и монохромность.

Какое мастерство в изобретении своих терминов! Лорошкола даром не проходит!

«Монохромность» - это цветовой режим выводящего устройства.

Вы уж определитесь для начала, что такое текст

Я уже дважды это сделал в этом ITT треде меньше чем дюжиной постов выше:

1. «Настоящий текстовый режим» - это телетайп, матричный принтер и COM-порт.
2. по этим интерфейсам хотя бы можно делать вид, что они текстовые. Например, AT-команды модема или ESC/POS команды принтера - там вполне себе ASCII-коды латинских букв.

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

Так мы и про вход выяснили - им является произвольно изменяемая в любом месте матрица кодов для копирования произвольных битмапов из готовой коллекции в выходной буфер экрана. То есть, ничего общего с каким-бы то ни было «текстом». Любой последовательный вывод текста на экран средствами BIOS / OS эмулируется через этот механизм. Иными словами, никакой аппаратной поддержки «вывода текста» в видеокартах, разумеется, нет.

Новости такие.

Dirty - часть File. Классический le9 защищает в том числе грязные страницы и не помогает при 12309.

Новый вариант, защищающий только чистые файловые страницы (File - Dirty) полностью фиксит 12309 - при любом размере vm.dirty*.

См https://ibb.co/0jygqDs

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

В течение стресса гуй жив, киллер приходит быстро.

Классический le9 защищает в том числе грязные страницы

Да, это не очень логично. Логично защищать чистые.

Новый вариант, защищающий только чистые файловые страницы полностью фиксит 12309

А вот смысловой переход от принципа работы le9 к фиксу 12309 не могу сообразить. Требуется пояснение.

12309 возникает, когда процессы утыкаются в блокировку при попытке записи данных, так? Я вспомнил, что у меня всё-таки был самый настоящий 12309, но не в повседневном использовании. Я запускал линукс с флешки, которая оказалась очень медленной на рандомную запись. И система фризилась буквально по любому поводу. Уменьшение лимитов vm.dirty* до значения в 1-2 МБ улучшало ситуацию если не до нормальной, то до более-менее пригодной к использованию такой флешки для rescue работ.

Новый вариант

Это который в linux-pf? Или вы этот новый вариант только что придумали?

Только что. Свежий, не опубликован.

А вот смысловой переход от принципа работы le9 к фиксу 12309 не могу сообразить

Позже напишу.

Вздутие Dirty давит на LRU и обычно приводит к выселению чистых файловых страниц (эффект примерно тот же, что и при около-ООМ ситуации - высокий IO не только за счет записи грязных страниц, но и интенсивного считывания чистых).

Резервируя чистые файловые страницы мы также резервируем Dirty.

Защита чистых страниц защищает и Dirty - в некотором смысле неизбежная побочка. Это видно на картинке выше.

Почему ВСЁ ТОРМОЗИТ, хотя пишем на флэшку, почему это вообще влияет на IO на других дисках? Полагаю, что дело в том, что увеличение кэша грязи в сочетании с нехваткой памяти приводит все к тому же - выселению из памяти кэша разделяемых библиотек, без которых и невозможна нормальная работа системы. Использование prelockd на максималках практически решает проблему. При этом при исчерпании памяти и при зависшей системе File практически равно Dirty (чистые файловые практически полностью выселены, почти все файловые являются грязными).

Итак, применяя новый le9 в котором защищается File - Dirty, мы получаем следующее: при интенсивной записи на медленный носитель и при запуске потребителя памяти первым делом вытесняется кэш чистых страниц. Если объем этого кэша ниже vm.clean_file_min_kbytes - вместо давления на файловый кэш и попытки записи Dirty на диск вытесняется анонимка в своп. При отсутствии свопа приходит OOM killer (защищая чистые страницы мы автоматически защищаем и грязные - ибо в очереди на выселение первыми идут чистые).

В ванильном ядре есть минимальная защита файловых страниц:

	 * If the system is almost out of file pages, force-scan anon.
	 */
	if (sc->file_is_tiny) {
		scan_balance = SCAN_ANON;
		goto out;
	}

– https://github.com/torvalds/linux/blob/v5.11/mm/vmscan.c#L2287

Полагаю, что она также защищает сумму чистых и грязных. И при наличии грязных страниц этот механизм ломается и фактически начинает защищать только грязные страницы. С нулевым Dirty этот механизм защищает чистые страницы, и минимальная отзывчивость гуя сохраняется. При высоком Dirty чистые страницы лишаются защиты, и получаем thrashing на дисках, на которых лежат либы.

Таким образом, великую тайну бага 12309 можно считать раскрытой.

Если объем этого кэша ниже vm.clean_file_min_kbytes - вместо давления на файловый кэш и попытки записи Dirty на диск вытесняется анонимка в своп.

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

Кстати,

# hdparm -W0 /dev/sdc
## Запрет кэша записи для устройства
## можно это делать через /etc/hdparm.conf

Гениально!

С 2006-го по всем интернетам ходили легенды об этом баге. И вот пришел герой, который всё объяснил.

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

Абсурд вот в чем: LRU имеет 4 списка - активные и неактивные файловые и анонимные. Так вот абсурд в том, что в файловых LRU смешаны в одну кучу чистые и грязные файловые страницы. Как тебе такое? Сраницы с принципиально разными свойствами. Грязные даже ближе к анонимным - их нельзя просто выкинуть из памяти, их можно только МЕДЛЕННО ЗАПИСЫВАТЬ, обязательно на диск, нет опции быстрой записи на zram устройство, как в случае со своппингом анонимки.

Одной строкой можно вылечить 12309 - учитывать только чистые файлы при вычислении sc->file_is_tiny:

+ file -= node_page_state(pgdat, NR_FILE_DIRTY);

Итог (без le9): https://ibb.co/122dCF8 - симптомов 12309 нет.

Нужно репортить в апстрим.

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

Потестить пока не могу, работы много.

torvn77, интересует тема?

Надо убедиться, что не плацебо. Нужно больше тестов. Ожидайте.

Одной строкой можно вылечить 12309 - учитывать только чистые файлы при вычислении sc->file_is_tiny:

Нет, это так не работает.

Да и вообще, настоящие проблемы возникают только при исчерпании свопа.

И где?

Выделение оперативной памяти для приложения/процесса (комментарий):

Это режимы работы «прошивки» (не карты!)

Погугли

Неприличными словами не выражаться! ©

«Монохромность» - это цветовой режим выводящего устройства.

А отсутствие цветовой информации — это тогда что? ;)

«Настоящий текстовый режим» - это телетайп, матричный принтер и COM-порт

Утиная типизация? не взлетит. По подобию можно даже слона к мухе приравнять: серое, толстовысирачевое, по бокам чего-то висит… Абстрактное определение давайте, а не эталоны :P

изменяемая в любом месте матрица кодов

Которые расположены в порядке текстовой кодировки, ну.

Это уже который раз 12309 «чинят»? ;)

А его чинили? Банально dirty bytes ограничить предлагали(в обсуждении присутствовал Линус) что-то под десять лет назад, и нихера до сих пор вообще не сделано.

А как его можно починить? Что с грязными страницами делать?

Не генерировать их, например.

А если уже сгенерированы?

1. Ждать сброса грязных - это дефолт. ООМ Киллер не придет, пока грязные не сбросятся.
2. Новый вариант le9 патча - вызывать киллера не дожидаясь сброса грязи.
3. Какие еще варианты, кроме собственно ограничения макс размера грязных?

И где?

Выделение оперативной памяти для приложения/процесса (комментарий):

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

А отсутствие цветовой информации — это тогда что? ;)

А наличие - тогда что?

Абстрактное определение давайте, а не эталоны :P

То есть, подожди-ка! Ты затирал про «Настоящий текстовый режим» даже не зная, что такое «текст»?!? Ах ты маленький засранец!

Да(р)ю определение:

«Текст» на компьютерном жаргоне - упорядоченная последовательность кодов из ограниченного алфавита, имеющие взаимно однозначное соответствие типографским символам (буквоцифрам, знакам препинания арифметики и просто красивым закорючкам вроде «@#№$») и специальному символу «пробел».

«Текстовый интерфейс» - интерфейс, принимающий на вход упорядоченную последовательность и далее, см. определение текста выше, и, кроме того, дополнительные «управляющие коды», не входящие в алфавит кодов «текста».

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

P.S. Удачи найти видеокарту, аппаратно обрабатывающую входные данные «буковка за буковкой» из алфавита, имеющего взаимно однозначное соответствие типографским символам.

А что с ними в других ядрах делают?

не вижу приписываемых мне слов

А надо дословно ссылаться? ;)

погугли в яндексе

Это ещё что за извращение?

А наличие - тогда что?

Полихромность :P

аппаратно обрабатывающую входные данные «буковка за буковкой» из алфавита, имеющего взаимно однозначное соответствие типографским символам

А если по этим вашим COM/LPT байтики послать не в соответствии с ASCII-таблицей, а начхав на это взаимно однозначное соответствие, то что получится? ;) В чём разница тогда?