-=O_O=-

а с xfs?

Serious data corruption bug when using XFS blabla

че делать то? или не мигрировать на 5.10?

Serious data corruption bug when using XFS

Где это описано?

-=:=-

https://packages.gentoo.org/packages/sys-kernel/pf-sources

Со ссылкой на

https://www.spinics.net/lists/linux-xfs/msg47004.html

но вроде дальше говорится, что исправлено

https://www.spinics.net/lists/linux-xfs/msg47006.html

Плюс

The mkfs line used to create this fs was:

mkfs.xfs -m rmapbt=1,reflink=1 -d agcount=17,sunit=$((128*8)),swidth=$((384*8)) -l logdev=/dev/sde3,size=521728b -i sparse=1,maxpct=25 /dev/main/root

I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E

Premature optimization is the root of all evil. - Donald Knuth

The standard answer you will get to this question is this: use the defaults.

Ну так что сломали-то?

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

отломали scrollback в консоли

Это?

На дебиане через 5 лет будет.

Посмотрите еще это:

• Linux 5.9 + le9i.patch, playing supertuxkart with 7 tail /dev/zero in background https://youtu.be/c5bAOJkX_uc

Посмотрел я патчи. Разве в cgroup2 ручки memory.{low,min} не делают примерно то же самое?

Думаю делают совсем другое. memory.min имхо это про анонимную, а не про файловую. Впрочем, я не эксперт. Но вообще я не знаю, как через сигруппы так легко добиться такого сильного эффекта. le9 дает сильный общесистемный эффект и не требует спецнастройки практически. Дефолтный для le9g порог 254М отлично работает на любом десктопе, а добавляет-то всего 7 очевидных строк, зщапрещающих отбрасывание Active(file).

Это похоже на естественное лекарство для сломанного ядерного киллера, когда разрешение на отбрасывание практически всех файловых кэшей приводит к сильной пробуксовке при нехватке памяти (которой удивлялся birdie-Ташкинов) и которой нет с патчем - вместо мигания лампочки диска и зависания вовремя приходит киллер, а при наличии свопа еще и резко может улучшаться отзывчивость при стрессах.

Зачем значение, возвращаемое global_node_page_state(), умножается на MAX_NR_ZONES? Ведь это глобальный счётчик для всех зон и так.

https://gitlab.com/post-factum/pf-kernel/-/commit/daf51d02979fc2ec22423362fdf21687beaee3b2

^^ есть возможность протестить?

global_node_page_state() возвращает число страниц. Умножением на MAX_NR_ZONES получаем KiB. Правдоподобно ли звучит? Нам же нужны KiB для сравнения с заданным значением, а не число страниц.

^^ есть возможность протестить?

Сборка уже идет.

А сколько оно уже там весит?

Директория после сборки - 16 гиг. Клонированные исходники одной версии - 1.1 гиг. Распакованный тарбол линукс 59 - 930М.

Оно там уже.

Зачем значение, возвращаемое global_node_page_state(), умножается на MAX_NR_ZONES?

Может это:

Active(file) is actually 4 times more than nr_active_file (due to a << (PAGE_SHIFT - 10) which is <<2 see: fs/proc/meminfo.c func. show_val_kb )

https://raw.githubusercontent.com/hakavlad/le9-patch/main/original_patches/le9e.patch

^^ есть возможность протестить?

Пока все супер, детали позже.

В stable завезут летом, очевидно.

ачем значение, возвращаемое global_node_page_state(), умножается на MAX_NR_ZONES?

+	$ grep nr_active_file /proc/vmstat
+	nr_active_file 678001
+
+and multiply that with MAX_NR_ZONES (which is 4), ie. `nr_active_file * MAX_NR_ZONES`
+so 678001*4=2712004  kB
+
+MAX_NR_ZONES is 4 as per:
+`include/generated/bounds.h:10:#define MAX_NR_ZONES 4 /* __MAX_NR_ZONES */`
+and is unlikely the change in the future.

– https://raw.githubusercontent.com/hakavlad/le9-patch/main/original_patches/le9h.patch

Не очевидно. Он выходит обычно весной.

Между делом, забавнее то, что с этим отламыванием выяснилось, что консоль у амуде всегда была без аппаратного ускорения. Ускоренная была только на nouveau. А разговоров-то было…

Пожалуйста, опиши, что изменил по сравнению с оригиналом. Исправил ли FIXME? Убрал ли умножение на MAX_NR_ZONES? Что-то еще?

Тестировал ли сам?

Похоже, что с этим https://gitlab.com/post-factum/pf-kernel/-/commit/daf51d02979fc2ec22423362fdf21687beaee3b2 все ОК.

Предлагаю изменить дефолты. Сам автор предпочитает резерв Active(file) 254M.

Патч le9i выпущен в основном лишь для тестирования резервирования Inactive(file):

Try le9i.patch if you also want Inactive(file) but it’s not necessary to mitigate the freezes.

– https://web.archive.org/web/20191018023217/https://gist.github.com/howaboutsynergy/04fd9be927835b055ac15b8b64658e85

this was just for testing

– https://web.archive.org/web/20191018023434/https://gist.github.com/howaboutsynergy/cbfa3cc5e8093c26c29f5d411c16e6b1

Результат такой: резервирование Inactive(file) в основном влияет негативно. С большими резервами Inactive(file) на моем железе часто было это с падением сессии:

дек 19 16:55:40 PC org.a11y.atspi.Registry[1317]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
дек 19 16:55:40 PC org.a11y.atspi.Registry[1317]:       after 49 requests (49 known processed) with 0 events remaining.
дек 19 16:55:41 PC polkitd(authority=local)[846]: Unregistered Authentication Agent for unix-session:22 (system bus name :1.109, object path /org/mate/PolicyKit1/AuthenticationAgent, locale ru_RU.UTF-8) (disconn
дек 19 16:55:41 PC unknown[3992]: notification-area-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC lightdm[3841]: pam_unix(lightdm:session): session closed for user user
дек 19 16:55:41 PC unknown[3996]: mate-brightness-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:42 PC sudo[4054]: pam_unix(sudo:session): session closed for user root
дек 19 16:55:41 PC unknown[4025]: mate-system-monitor: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC unknown[3998]: mate-sensors-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC unknown[4015]: clock-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC unknown[3981]: wnck-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC unknown[3994]: mate-multiload-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 19 16:55:41 PC systemd-logind[751]: Removed session 22.

Посему предлагаю резерв Inactive выставить в 0 по умолчанию.

Chrome OS использует по умолчанию резерв 50М c 2010 и до сих пор:

# Protect working set in order to avoid thrashing.
# See http://crosbug.com/7561 for details.
vm.min_filelist_kbytes = 50000

– https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/factory-spring-4131.B/chromeos-base/chromeos-base/files/sysctl.conf

ИМХО 50М могло быть неплохим резервом для 2010, но для 2020 это слишком мало.

Автор с XFCE использует резерв 254М. Тем более с современными гномами и кедами это не будет большим значением, когда на среднем ноутбуке памяти 4-8 гиг.

Прелагаю дефолты сделать такими: 254M Active, 0 Inactive. Это хорошо работает и при нормальных нагрузках дает только плюсы.

Да, ты таки прав. Проблема в том, что умножение на MAX_NR_ZONES — это довольно тупо. Да, так совпало, что оно 4. Но должно быть вот так:

#define K(x) ((x) << (PAGE_SHIFT-10))

Исправлю и кину новый патч.

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

FIXME убрал, пофиксил то, как считаются кибибайты, убрал лишний текст, переименовал опции в конфиге.

Смотри и пробуй, пожалуйста, вот новая попытка: https://gitlab.com/post-factum/pf-kernel/-/commit/4b2beea775752f77631d372ad41ce5438d3c7712

Сам не пробовал?

Нет, сам не пробовал. Только build test.

они тормоза с io то уже пофиксили?

я думал,это грабли бтрфс.
а на днях открывал архив гуглодиска, и при чтении оного система начала тупить даже на ext4.
конфиг скромный,
adata600 / 32 Gb RAM / Ryzen 3500

Тюнингуй параметры ядра. Уменьшай кеш записи. Если ссд, можешь попробовать шедуллер kyber. А в чем ты открываешь архив? В ark? В нем есть глюк. Если попробовать открыть большой файл, он выжрет всю память и зависнет. Чтобы линукс не зависал при исчерпании памяти, настрой vm.overcommit. А вместо арка используй энгрампу и проекта MATE.

Все супер и работает как должно.

Запустил 2 цикла while true; do tail /dev/zero; done, затем открывал приложения. Active(file) вырос как раз до 256М.

Лог мониторинга памяти: https://pastebin.com/raw/pHTkgCKe

Скрипт мониторинга: http://okturing.com/src/10003/body

Скрин из ящика: https://i.ibb.co/hCfqXqZ/Virtual-Box-deb9-2-20-12-2020-21-23-24.png

Чтобы линукс не зависал при исчерпании памяти

Можно установить pf-kernel с патчем le9. Демо: https://youtu.be/c5bAOJkX_uc

Аффтар жжот! Это твой патч? А когда он будет в апстриме?

И в чем принцип его работы? В общих чертах.

Обсуждаем в этой же теме, читай отсюда Linux 5.10 (комментарий) и далее.

См https://github.com/hakavlad/le9-patch

Ну эээ могу тогда смержить в основной патчсет.

Могу ли выделить твой дифф у себя репе в le9pf-5.10.patch?

Ждем 5.10.1 с le9. Дай знак когда закончишь, пожалуйста.

Ну это вообще пушка https://gitlab.com/post-factum/pf-kernel/-/commit/40434cea1c9fcd6587526ab97fe4b6b6c58b300c

Все на pf-kernel!

Да как хочешь :).

Когда stable 5.10.2 выйдет, тогда будет релиз. На днях.

А невидия не торопится :)

Не забудь обновить https://gitlab.com/post-factum/pf-kernel/-/wikis/README

То потом, во время релиза.

extern unsigned int sysctl_unevictable_inactivefile_kbytes;

unsigned long sysctl_unevictable_inactivefile_kbytes __read_mostly =

Почему в одном месте unsigned int, а в другом unsigned long? Разве не везде unsigned long должен быть?

Присоединяюсь к вопросу выше.

Блоб работает с этим ядром. Пинай убогих маняйтейнеров своего дистрибутива.

Потому что я слепой? Поправлю.

https://gitlab.com/post-factum/pf-kernel/-/commit/443657c2a3c0e4f4c95283989e2071c817407fef

Собрал с последним коммитом. Ничего неожиданного.

https://i.ibb.co/0Kb7p5T/2020-12-21-22-43-14.png

Ждем слияния и релиза.