Добыть профит из свободной RAM

оно и так по дефолту его добывает

https://www.linuxatemyram.com/

https://www.linuxatemyram.com/

Сегодня открывал эту ссылку, пока перечитывал треды по теме. Ответа на мой вопрос пока не нашёл.

вот прям чтобы так увеличить производительно в 2-3 раза вряд ли получится, а заморачиваться ради 2-3% не стоит, имхо

по теме:
1) можно профиль firefox разместить в RAM (см. archwiki)
2) можно увеличить vm.dirty_writeback_centisecs , но это вряд ли что даст на современных винчестерах
3) swappiness менять не надо, потому что свопа у тебя нету
4) сетевой стек тоже особо крутить нет смысла, разве что увеличить дисковый кэш для торрента

Ясно, заморачиваться нет смысла. Спасибо!

Тему считаю закрытой.

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

Ибо неправильно искал. Линукс и так сожрёт всю доступную ему память при необходимости. Нет нужды что-то тюнить.

Убедись, что включены transparent huge pages.

. Ну, tmpfs стал 4 Гб, но и это не нужно — много.

У тебя только /tmр на tmpfs?

Где-то в хомяке должен ещё болтаться пользовательский.
Да и /var/apt/cache/archives можно на тмпфс отправить.

Что нужно делать с компьютером, чтобы 4 ГБ было достаточно? Запускать только офис и одну вкладку браузера?

Не использовать GNOME 3 и KDE 5. У меня Debian 10 с LXDE менее 300 мегов после загрузки DE жрет. А когда DE под себя со старта полтора гига — тут трудно, да.

Будто это имеет какое-то значение на фоне потребления 9-ю гигов браузером.

Смотря какие сайты открывать.

потребления 9-ю гигов браузером

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

У тебя какой-то сайт протекает, не иначе.

Ютюб!

это не swapping

он самый и есть - выгрузка сегментов кода из памяти.

Обычно это называют paging.

Почитал статьи о Transparent Hugepage Support. Пишут как о положительных результатах, так и о появлении нежелательных задержек и пр. Сейчас в фоне компиляю ядро с добавленной поддержкой THP.

Как я понял, включать эту фичу с опцией madvise безопасно.

Enabling Transparent Hugepage madvise, will only provide a performance improvement benefit to the applications using madvise(MADV_HUGEPAGE) but it won’t risk to increase the memory footprint of applications without a guaranteed benefit.

Если система 64-битная, то она сама должна под кэши весь ненужный объём использовать. Может не сразу, но в итоге займёт.

32-битная займёт не весь, ибо не может.

У тебя только /tmр на tmpfs?

Не, я туда fstab-ом монтирую всевозможные кэши, логи(ибо пока всё работает — не нужно), upower, thumbnails, trash.

Можешь zram попробовать использовать, может дать некоторый выигрыш. А может и не дать.

Что нужно делать с компьютером, чтобы 4 ГБ было достаточно? Запускать только офис и одну вкладку браузера?

Ну, примерно так и пользуюсь. У меня 1Гб почти никогда не набирается. И это при включенном браузере и текстовом редакторе.

Сижу на 2гб ноуте. При OneTab (открыта не одна вкладка, а порядка десяти с регулярно запущенным Youtube) и NoScript, нормально так юзается. При чём в фоне открыт Emacs, Telegram и терминалы. Не понимаю нытья по поводу памяти. Да, генту не покомпилируешь.

У меня 64 бита. После компиляния ядра free показывает под кэши 3,9Gi, available: 4,0Gi. Хочется, чтобы вот эти последние пользу системе приносили.

Зачем мне zram? У меня совсем другая ситуация! Мне и swap не нужен, потому что свободной оперативки с избытком.

Так чего же ты собственно хочешь? Мне кажется что о такой штуке как Preload ты не слышал.

Посмотрел prelink — пакет в арче удалён, с preload похожая история. Их никто не поддерживает, опасно ставить.

https://pagure.io/fesco/issue/1183

На глазок никакой пользы от них не заметно.

https://github.com/kokoko3k/gopreload

Это выглядит живым.

Их никто не поддерживает, опасно ставить.

AUR кто-то поддерживает?!

В ауре он тоже удалён.

https://github.com/kokoko3k/gopreload

firefox |0m5.038s |0m16.160s У него firefox запускается 16 секунд??

README редактировался последний раз 4 years ago.

Видимо он действительно RIP. Я его сам использовал в 2016, думал что оно ещё живо. Альтернатив не нашёл.

Потестил два ядра: с включённым TH и без него. Результаты такие:

linux-5.3.6

sysbench --threads=4 --test=cpu run
TH      2187
no_TH   2182
sysbench --threads=100 --test=threads run
TH      16372
no_TH   16411
sysbench --threads=100 --test=mutex run
TH      9.32
no_TH   9.32
sysbench --threads=100 --test=memory run
TH      51094627
no_TH   51159543

Тесты запускал в одинаковых условиях по 4 раза с расчётом среднего арифметического.

Видно, что хоть сколько-нибудь заметной разницы нет. Чем другим потестить — не знаю. Может быть какую-нибудь заковыристую страничку в нете пооткрывать на время. Нужно что-то памятежоркое.

Видимо, оба этих pre-проекта имеют кучу неприятных сопутствующих эффектов, так что в сообществе тема сама собой закрылась.

Не обязательно устраивать на zram-разделах подкачку. Можешь просто монтировать куда-нибудь и хранить там, к примеру, кэши.

Это то же самое.

sysbench

Лол. Это тест скорости сисвызовов, годится только для проверки урона к производительности от всяких там защиот от spectre/meltdown.

Я разницу от thp видел в luxreder на проце.

https://sourceforge.net/p/preload/bugs/

Последний открытый баг 5-летней давности. Проект мёртвый.

Может быть, увидишь там несколько «неприятных сопутствующих эффектов».

пожертвуй голодающим детям африки, пускай майнят себе на бананы из европы и сша