LINUX.ORG.RU

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

 , , , ,


2

2

Всем привет. У меня слабый компьютер с Debian. Обычно в силу того что компьютер зависает пользуюсь максимум одной программой, браузером или какой-нибудь cs 1.6 например. Браузер или ОС занимают не всю оперативную память под работу, чтобы я мог запустить другое приложение и компьютер не завис, но мне этого не надо и я хочу максимальной производительности от используемого приложения.

Как мне выделить всю оперативную память (2ГБ) под конкретное приложение/процесс? Какие команды использовать? В интернете нашёл команду nice для повышения приоритета процесса, но пишут что не всегда помогают.

Ответ на: комментарий от wandrien

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

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

См в /proc/meminfo

VmallocTotal:   34359738367 kB
anonymous ()
Ответ на: комментарий от ValdikSS

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

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

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

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

vm.swappiness = 1
vm.min_free_kbytes = 32768

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

anonymous ()
Ответ на: комментарий от ValdikSS

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

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

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

anonymous ()
Ответ на: комментарий от ValdikSS

vm.watermark_scale_factor=200

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

aidaho ★★★★★ ()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

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

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

mertvoprog ()
Ответ на: комментарий от hakavlad

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

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

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

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

wandrien ()
Ответ на: комментарий от LamerOk

Все миникомпьютеры конца 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. Он может отображаться тонкой чёрточкой, сплошным знакоместом или быть выключен.»

wandrien ()
Ответ на: комментарий от wandrien

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

wandrien ()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

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

mertvoprog ()
Ответ на: комментарий от LamerOk

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

mertvoprog ()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

mertvoprog ()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

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

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

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

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

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

mertvoprog ()
Ответ на: комментарий от LamerOk

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

Это называется знакоместо. Сами вы «спрайт». :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

Текстовый.

wandrien ()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от wandrien

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

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

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

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

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

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

hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

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

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

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

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

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

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

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

hakavlad ★★ ()
Ответ на: комментарий от wandrien

Вздутие 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 можно считать раскрытой.

anonymous ()
Ответ на: комментарий от anonymous

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

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

Кстати,

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

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

anonymous ()
Ответ на: комментарий от wandrien

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

hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

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

wandrien ()
Ответ на: комментарий от wandrien

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

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

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

hakavlad ★★ ()
Ответ на: комментарий от LamerOk

И где?

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

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

Погугли

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

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

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

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

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

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

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

mertvoprog ()
Последнее исправление: mertvoprog (всего исправлений: 1)
Ответ на: комментарий от mertvoprog

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

И где?

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

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

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

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

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

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

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

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

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

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

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

LamerOk ★★★★★ ()
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

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

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

mertvoprog ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.